Origin trials for the Continuation API bundle and Storage Access API auto-grant

[FedCM developer newsletter]

Hello FedCM newsletter subscribers!

We have a few exciting updates to the Federated Credential Management API.

• We’re starting an origin trial for the Continuation API bundle from Chrome 126

  • Continuation API

  • Parameters API

  • Fields API

  • Multiple configURLs

  • Custom Account Labels

• We’re also starting an origin trial for FedCM as a trust signal for the Storage Access API from Chrome 126

Read the full article in the blog post for details, but here's a quick summary:

The Continuation API bundle

Chrome 126 is starting an origin trial of the FedCM Continuation API bundle which consists of multiple FedCM extensions:

• Continuation API: The Continuation API allows the IdP's ID assertion endpoint to optionally return a URL that FedCM will render to allow the user to continue a multi-step sign-in flow. This allows the IdP to request the user to grant the relying party (RP) permissions beyond what is possible in the existing FedCM UI, such as access to the user's server-side resources.

• Parameters API: The Parameters API allows the RP to provide additional parameters to the ID assertion endpoint. With the Parameters API, RPs can pass additional parameters to the IdP to request permissions for resources beyond basic sign-in.   The user would authorize these permissions through an IdP-controlled UX flow that is launched via the Continuation API.

• Fields API: The Fields API allows the RP to declare account attributes to request from the IdP so that the browser can render a proper disclosure UI in the FedCM dialog; it's the IdP's responsibility to include the requested fields in the returned token. Consider this requesting a "basic profile" in OpenID Connect versus "scopes" in OAuth.

• Multiple configURLs: Multiple configURLs allow IdPs to accommodate multiple config files for an IdP, by specifying accounts_endpoint and login_url in the well-known file the same as the config files.

• Custom Account Labels: Custom Account Labels allow FedCM IdPs to annotate accounts so that RPs can filter them by specifying the label in a config file. Similar filtering has been possible using the Domain Hint API and the Login Hint API by specifying them in the navigator.credentials.get() call, but the Custom Account Labels can filter users by specifying the config file, which is especially useful when multiple configURLs are used. Custom Account Labels are also different in that they are provided from the IdP server, as opposed to from the RP, like login or domain hints.

FedCM as a trust signal for the Storage Access API

Chrome 126 is starting an origin trial of FedCM as a trust signal for the Storage Access API. With this change, a prior permission grant using FedCM becomes a valid reason to automatically approve a storage access request by the Storage Access APIs.

This is useful when an embedded iframe wants to access personalized resources: for example, if idp.example is embedded in rp.example and needs to show a personalized resource. If the browser restricts access to third-party cookies, even if the user is signed in to rp.example using idp.example with FedCM, the embedded idp.example iframe won't be able to request personalized resources because requests won't include third-party cookies.

To achieve this, idp.example needs to get a storage access permission using its iframe embedded on the website, and this can only be obtained through a permission prompt.

With FedCM as a trust signal for the Storage Access API, Storage Access API permission checks not only accept the permission grant that is given by a storage access prompt, but also the permission grant given by a FedCM prompt. Note that the embedder must explicitly opt in to allow the auto-grant in the iframe by using the identity-credentials-get Permissions Policy.

If you have any feedback about the API, file an issue. We will keep the canonical FedCM developer guide up to date, along with the accumulated update logs page.