[Feature Request] Prototype higher level API for calling POP RPs

When calling an RP which supports POP, they will send back some 401 Authenticate headers indicate support for POP (and most likely for Bearer as well).

Upon calling the RP, the 401 Authenticate header will contain a nonce, with typical lifetime of 5 minutes. This nonce needs to be used to create the SHR part of the POP token. If an expired nonce is used, the RP will return a 401 Authenticate header with a new nonce. If a non-expired nonce is used, the RP may return a 200 Authenticate-Info header containing a fresh nonce.

Constraints:

Focus should be on Public Client. We can prototype using existing POP infrastructure, i.e. ignoring the fact that the RT is always Bearer. WAM will provide support for bounded ATs in the future.
Discuss with SAL team about a test service which supports POP, that can be used for prototyping
Prototype can be done outside MSAL if needed

Approaches:

Microsoft.Identity.Web have done some work around this, which can serve as a basis of operations.

an HttpClient message handler approach - MicrosoftIdentityUserAuthenticationMessageHandler.cs
an "DownsStreamWebAPI" higher level API: IDownstreamWebApi But also:
interfacing directly with the Graph SDK by providing a graph token provider
interfacing directly with the Azure SDK by providing a TokenCredential. These are semantically equivalent and all build-up on a higher level API to get a token (ITokenAcquisition/ ITokenAcquirer)

Scenarios to consider:

choosing between Bearer and POP - for example via an enum { Automatic, PreferBearer, PreferPoP }
extracting nonce from 401 / 200 headers (there should be 1 nonce per RP?)
managing nonce (is this even possible? clients do NOT know about nonce lifetime). Probably we'll have to keep a nonce around for each RP and try to update it.

For further reading:

AzureAD / microsoft-authentication-library-for-dotnet