Mediation oriented API too limited - Bearer credentials

[will-bartlett]

I was reviewing the mediation-oriented API from WebID as a successor to the permission-oriented API. I work for Microsoft in the Identity space. I observed that the mediation-oriented API is limited to Bearer authentication - "the browser will then issue a credentialed GET request." Bearer tokens (like cookies) are increasingly seen as a legacy technology in the Identity space and some Identity services already support successor technologies like DPoP. WebID should avoid constraining auth to such a legacy technology. However, it is a reasonable default.

One option might be service workers. If WebID permitted IDPs to return a "service_worker" entry as part of of their well-known metadata, and then have the WebID code effectively trigger ServiceWorkerContainer.register() for the URI. Then, the service worker could customize the subsequent account list and token fetch request and responses. In this manner, WebID could default to Bearer credentials, but still support customization, as to avoid over-constraining the Identity space and becoming a blocker to future security features. That might allow IDPs who have moved beyond Bearer authentication to e.g. sign over the request, to protect the user from MITM attacks.

[will-bartlett]

Wanted to ping on this.

The limitation to cookies (which are inherently Bearer credentials and passive state) is significant. Bearer tokens have an inherent problem that they can be stolen - token theft being at the core of so many security incidents. The Identity space is rapidly iterating on different designs to solve these problems (like DPoP, see above), but this design effectively rules out all of those solutions. I think the framework of the current draft (a small number of simple messages) is good, but I think it would be better to define those messages in such a way that their transport can be customized. For example, they could be customized in their current definition as HTTP requests with a service worker. Alternatively, they could be defined as JavaScript APIs rather than HTTP APIs, and the implementor could be responsible for the last mile of taking JSON JS objects, turning them into JSON HTTP requests, and taking JSON HTTP responses and turning them into JSON JS objects. A customized transport like that would permit more complex transports (like signed challenge-response requests) that could offer greater security properties.

[pkotwicz]

Question 1: In the DPoP specification, is the public key based on the device (All RPs on a given device use the same public key) or based on the RP (A given RP uses the same public key across all devices)?

Relevant spec snippet:

• jwk: representing the public key chosen by the client, in JWK format, as defined in Section 4.1.3 of [RFC7515] (REQUIRED). MUST NOT contain the private key.

Question 2: In the future, will DPoP be required to fetch information about the list of accounts that the user is currently signed into the browser? Currently the FedCM API, in order to show the FedCM account picker, makes a request credentialed with the IDP first party cookie in order to get information to display in the FedCM account picker. https://fedidcg.github.io/FedCM/#idp-api-accounts-endpoint (FedCM vends an id token and perhaps grants additional permissions when the user grants consent to the FedCM account picker) The reason for question 1 is that it is a hard privacy requirement that during the request for account information in order to render the FedCM prompt, the user agent cannot reveal to the identity provider the relying party's identity.

For the sake of completeness, I do not expect there to be an issue in supporting DPoP for the token request https://fedidcg.github.io/FedCM/#idp-api-id-token-endpoint

[will-bartlett]

@pkotwicz

Re DPoP keys - DPoP leaves this unspecified, which means it depends on the implementation. I'd emphasize that DPoP is an example of Identity PoP technology, but not the only example. In particular, one of the problems that DPoP doesn't solve (that Microsoft's proprietary implementation does solve) is the problem of multiple entities - DPoP doesn't attempt to provide a solution for using keys to protect both the IDP cookie and the RP AT - it assumes that all protected tokens belong to the same entity (the RP). In Microsoft's (non-DPoP) PoP implementation, we use a device-wide root key and derived ephemeral keys for each relying party auth session. The use of fresh derived ephemeral keys provides the desired privacy aspects - no cross RP or cross user tracking.

In this issue, I'm asking for customizability, not for the browser to implement DPoP - let the IDP do all the details of PoP and keep it out of scope for the spec - this is still an evolving area in Identity. Omitting RP as a parameter for the account info request - sounds fine to me.

If the browser did want to implement PoP for the IDP cookies as a baseline - this might be ok too. The browser would want to use a per IDP key - conceptually, a PoP key is associated with a grant. In this case, the grant is the IDP cookies, which are IDP-domain scoped, so the PoP key for the grant would have the same scope and storage. Note that such an implementation wouldn't be DPoP, it would be "FedCM PoP", which might be "DPoP-like" - but strictly speaking, DPoP protects ATs and RTs - and that's not FedCM's territory. Edit: I actually don't think FedCM could introduce PoP for IDP cookies, because FedCM doesn't set these cookies, just reads them. The PoP key needs to be set at the same time as the cookies.

I would discourage FedCM from trying to implement PoP for RPs in the baseline. The semantics for PoP handoff (switching from cookies with an IDP key to access/id tokens with an RP key) are non-trivial and have no standard yet. As this is still an evolving space, better to let the IDPs do this as customization in Javascript than try to define such an evolving space strictly.

[will-bartlett]

Just to give a few examples of where customization (e.g. via a server worker) might be useful:

1. An IDP might implement multi-domain failover via a customization point for resiliency (existing common use case of service workers)
2. An IDP might implement a cache where slightly old tokens can be returned if the IDP is unavailable for resiliency (existing common use case of service workers)
3. An IDP might add additional verification, such as signing a timestamp (as DPoP does) to time-limit a request, or even signing the entire request (as Microsoft's proprietary implementation does) to time-limit and make immutable a request.
4. An IDP might implement geographic affinity, identifying the user's geo, and hitting a sovereign service for that geo
5. An IDP might have a non-FedCM service, but be able to convert the interface to FedCM via a customization point
6. An IDP might use a local identity service (distributed identity via blockchain?) rather than a cloud identity service

My focus in this issue in customization points. While the additional verification example is perhaps the most important (as it solves a security weakness), it's only one example on the list. My greater focus here is "don't over-constrain Identity."

[bvandersloot-mozilla]

@pkotwicz

For the sake of completeness, I do not expect there to be an issue in supporting DPoP for the token request https://fedidcg.github.io/FedCM/#idp-api-id-token-endpoint

I think that one key piece missing here is customization of the message in that endpoint from the perspective of the RP. The RP needs to be able to construct a token request object and append it to a credential request. We don't have a way to do that. Otherwise I agree: the id token can be the DPoP access token and the Credential object can be used by the RP to generate DPoP proofs.

An important question has to follow that up though: what are the privacy implications of allowing the RP to send arbitrary content to the IDP while building a credential. I would need to think on this more, but by this point in the transaction the browser has already sent the user's cookie to the IDP. However this is an increased risk: the RP gets a channel to the IDP.

[pkotwicz]

What is possible from a privacy perspective is different for the:

• id token endpoint: This endpoint is queried after the user grants consent for the RP to share data with the IDP. There is no privacy reason to constrain the data sent in the request to the id token endpoint. Altering the FedCM API to enable more customization of the id token request sounds reasonable.

• accounts list endpoint: This endpoint is queried prior to the user granting consent for the RP to share data with the IDP thus the browser needs to ensure that the IDP does not learn the identity of the RP. I foresee a few solutions for the account list endpoint: Solution 1: Use the push model mentioned by Sam here Solution 2: Require bearer tokens for accounts list endpoint request (FedCM account list endpoint specification would not make room for DPoP) Solution 3: Use DPoP for accounts list endpoint request. Run IDP script which creates account list request in a constrained environment (maybe a worklet?). Worklet browsing context would have access to IDP first-party storage. Worklet browsing context would not have access to RP client id

For solution 3, what data would the worklet need as input in order to create the account list HTTP request?

[pkotwicz]

@will-bartlett Ping!