Feature request: provide developers more visibility of auto re-authentication

[yi-gu]

Auto re-authentication is the default user mediation behavior in Credential Management API. However, auto re-authentication may be unavailable due to reasons that only the browser knows; when it’s unavailable the user may be prompted to sign in with explicit user mediation which is a flow with different properties.

• From an API caller’s perspective, when they receive an id token, they don’t have visibility over whether it was an outcome of an auto re-authn flow. That makes it hard for them to evaluate the API performance and improve UX accordingly.
• From the IdP’s perspective, they are equally unable to tell whether an auto re-authn occurred or not. Whether an explicit user mediation was involved could help them support more security related features. e.g. some users and/or RPs may prefer a higher security tier which requires explicit user mediation in authentication. If an IdP receives a token request, they could reject it if the user didn’t grant permission in the flow.

Therefore, providing visibility of the auto re-authentication flow would be beneficial to developers.

[yi-gu]

Proposal

In this proposal, the browser shares whether an explicit user permission was acquired in the transaction with both the IdP and RP whenever auto re-authentication occurred or an explicit mediation occurred. Note that the sharing only happens post user permission for IdP/RP communication.

IdP

To share the information to the IdP post user permission, we can include it in the POST request sent to the id_assertion_endpoint:

POST /fedcm_assertion_endpoint HTTP/1.1
Host: idp.example
Origin: https://rp.example/
Content-Type: application/x-www-form-urlencoded
Cookie: 0x23223
Sec-Fetch-Dest: webidentity

is_account_auto_selected=true&account_id=123&client_id=client1234&nonce=Ct60bD&disclosure_text_shown=true

RP (API caller)

The browser can share the information to the RP via IdentityCredential:

// IdentityCredential object
{
  "token": "eyJC...J9.eyJzdWTE2...MjM5MDIyfQ.SflV_adQssw....5c",
  "isAccountAutoSelected": true
}

Privacy and Security Consideration

Sharing with IdP

The is_account_auto_selected / isAccountAutoSelected bit is true if all of the following are true:

1. preventSilentAccess was not in effect (it was not used in the past or it was used but the user has signed in again after that)
2. mediation: required is not used in FedCM API
3. the user has only one active session with the IdP
4. the user has granted permission for the {RP, IdP} pair in the browser in the past and the permission is not cleared
5. other browser specific control, e.g. auto re-authn was not triggered in the last 10 mins

The information in #1 and #2 is already known to the IdP by virtue of the RP having used the SDK. If the SDK is not used, it is still acceptable to expose this information to the IdP, as the RP has already trusted the IdP for federated sign-in and the additional information is closely related to the API.

#3 is IdP populated information.

The information in #4 and #5 is browser-specific information. As the user has already granted permission for the RP/IdP to communicate, revealing this information to the IdP does not introduce any privacy risks.
On the other hand, if the is_account_auto_selected / isAccountAutoSelected bit is false, IdP would learn less because they couldn’t tell the exact reason. e.g. a user may have started a new browser client or they have cleared site data etc..

Sharing with RP (API caller)

We believe the same analysis above applies to RP as well. In addition, once an IdP has obtained the information, it can already share it with the RP via the opaque token string so the browser doesn't introduce any new risk.

Considered Alternatives

Instead of the browser sending the bit to both IdP and API callers directly, it can choose to only share it with the IdP, and then let the IdP share it with the RP. For example, IdP can integrate the information to the token string. While it’s suboptimal to overload the well-specified OIDC id token, they can also do so with some extra FedCM support:

1. IdP first include a new field in the id_assertion_endpoint response

// id_assertion_endpoint response
{
  "token": "eyJC...J9.eyJzdWTE2...MjM5MDIyfQ.SflV_adQssw....5c",
  "is_account_auto_selected": true
}

2. Browser shares the information with RP the same way as this proposal does

// IdentityCredential object
{
  "token": "eyJC...J9.eyJzdWTE2...MjM5MDIyfQ.SflV_adQssw....5c",
  "isAccountAutoSelected": true
}

While allowing IdP to add information in the response is better from extensibility’s perspective, e.g. they could add more fields to share more information with the API caller, we don’t find it very desirable at the moment. More importantly, we don’t think it’s mutually exclusive with our current proposal so we can add them later if needed.

[achimschloss]

@yi-gu seems this should be a proposal under https://github.com/fedidcg/FedCM/tree/main/proposals ?

[yi-gu]

thanks @asr-enid!

To follow up from yesterday's call: while we'd like to keep the new proposals in "Issues" such that it's easier for other folks to comment on, we'd be happy to adapt to find ways to accommodate different cases (e.g. for folks who want to keep track on new proposals).

In the interim, for FedCM changes in Chrome, there's a newsletter that one can subscribe to.