Intent to Ship: FedCM authorization features (fka Bundle 6: Continuation API, Parameters API, Fields API, Multiple configURLs, Custom account labels)

374 views
Skip to first unread message

Christian Biesinger

unread,
Nov 7, 2024, 6:47:08 PMNov 7
to blink-dev

Contact emails

cbies...@chromium.org


Explainer

Use case we want to support: https://github.com/w3c-fedid/FedCM/issues/477

Derived explainers:

https://github.com/fedidcg/FedCM/issues/555

https://github.com/fedidcg/FedCM/issues/556

https://github.com/fedidcg/FedCM/issues/559

https://github.com/fedidcg/FedCM/issues/552

https://github.com/fedidcg/FedCM/issues/553


Specification

https://github.com/w3c-fedid/FedCM/pull/662 (continuation API)

https://github.com/w3c-fedid/FedCM/pull/661 (parameter API, merged)

https://github.com/w3c-fedid/FedCM/pull/668 (fields API)

https://github.com/w3c-fedid/FedCM/pull/667 (multiple configURLs)

https://github.com/w3c-fedid/FedCM/pull/669 (account labels)


Summary

This bundles a few features that we would like to launch at the same time. We are bundling them together because they can be used by IdPs to implement authorization flows such as letting a user grant access to a user’s calendar to an RP. See also https://github.com/w3c-fedid/FedCM/issues/477. Specifically:

  • The IdP needs to be able to show a custom prompt for the permission (continuation API)

  • The RP needs an extensible way to communicate to the IdP what it wants access to (parameters API)

  • The RP needs to be able to customize/suppress the text referring to the IdP sharing “name, email address and profile picture” because in this situation they are asking for different information (fields API)

  • The IdP may want to use a different endpoint to implement the authorization flow (multiple configURLs)

  • Certain accounts may only be eligible for one of the authentication and authorization flows and so there needs to be a way to show different accounts in the two flows (account labels API)


In addition, the APIs are solving a series of related FPWD blockers identified by the FedID WG.


Continuation API:

https://github.com/fedidcg/FedCM/issues/555


This lets the IDP open a popup window to finish the sign-in flow after potentially collecting additional information.


Parameters API:

https://github.com/fedidcg/FedCM/issues/556


This lets RPs pass additional data to the ID assertion endpoint


Fields API:

https://github.com/fedidcg/FedCM/issues/559


This lets RPs bypass the data sharing prompt in favor of the IDP prompting


Multiple configURLs:

https://github.com/fedidcg/FedCM/issues/552


This lets IDPs use different config files in different contexts without weakening FedCM privacy properties, by allowing one accounts endpoint for the eTLD+1 (instead of one config file, which is more limiting than necessary)


Account labels:

https://github.com/fedidcg/FedCM/issues/553


Combined with the previous proposal, this allows filtering the account list per config file without providing additional entropy to the IDP.



Blink component

Blink>Identity>FedCM


TAG review

https://github.com/w3ctag/design-reviews/issues/945


TAG review status

Pending


Chromium Trial Name

FedCmContinueOnBundle


Link to origin trial feedback summary

What we learned during the origin trial:


  • This bundle works well for implementing an authorization flow for an identity provider

  • The parameter API needed to be refined to be easier to use for an IDP (allow nested objects; send the parameters as serialized JSON instead of individually prefixed parameters)

  • The fields API has gone through various iterations during the trial and is now easier and more flexible to use

  • We have identified a possible future extension to the continuation API (adding an IdentityProvider.reject function to mirror .resolve) but are not shipping it as part of this launch.




Origin Trial documentation link

https://developers.google.com/privacy-sandbox/blog/fedcm-chrome-126-updates#origin_trial_fedcm_continuation_api_bundle



WebFeature UseCounter name

kFedCmContinueOnResponse


Risks



Interoperability and Compatibility

No compatibility risk as this adds new parameters to dictionaries in a function argument.


No concern about interoperability because other browser engines currently do not ship FedCM.



Gecko: No signal. For incremental improvements to FedCM, Firefox has asked us not to file standards position, and they will instead provide feedback in the GitHub PR. They have interacted on the spec PRs (e.g. on https://github.com/w3c-fedid/FedCM/pull/662) and on the explainers (e.g. https://github.com/w3c-fedid/FedCM/issues/477) but have not expressed an explicit positive signal.


WebKit: No signal (https://github.com/WebKit/standards-positions/issues/336)


Web developers: Positive (https://github.com/fedidcg/FedCM/issues/488#issuecomment-1749682526) Also: https://github.com/fedidcg/FedCM/issues/496#issuecomment-1781364610 https://github.com/fedidcg/FedCM/issues/533#issuecomment-1878581998


Other signals:


Ergonomics

This improves ergonomics for passing custom parameters to the IDP because it now provides a structured way to do so instead of (ab)using the "nonce" parameter.


Otherwise no impact on ergonomics either way.



Activation

No particular risks.



Security

We made sure that the popup from the continuation API is same-origin with the IDP, and that it cannot communicate with the RP except through the narrow IdentityProvider.resolve API. In particular, window.opener is null.


The additional parameters from the parameter and fields API are only sent to the server after user interaction, and from a privacy perspective are equivalent to the existing "nonce" field. However, from a developer ergonomics perspective the additions are much easier to use.


Account labels were carefully designed not to add entropy and in particular not to send additional data to the server.



WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

n/a



Debuggability

We show console messages to assist debugging where appropriate.


Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?

No

FedCM in general is not supported in webview



Is this feature fully tested by web-platform-tests?

Yes

https://wpt.fyi/results/fedcm/fedcm-authz?label=experimental&label=master&aligned


We are investing why they are failing on wpt.fyi even though they pass in our internal infrastructure (e.g. https://ci.chromium.org/ui/test/chromium/ninja%3A%2F%2F%3Ablink_wpt_tests%2Fvirtual%2Ffedcm-authz%2Fexternal%2Fwpt%2Ffedcm%2Ffedcm-authz%2Ffedcm-continue-on-with-account.https.html)




Flag name on chrome://flags

fedcm-authz


Finch feature name

FedCmAuthz


Requires code in //chrome?

True


Tracking bug

https://crbug.com/40262526


Launch bug

https://launch.corp.google.com/launch/4348692


Measurement

https://chromestatus.com/metrics/feature/timeline/popularity/4955 In addition, we have several UMA metrics.


Estimated milestones

Shipping on desktop

132

Origin trial desktop first

127

Origin trial desktop last

131

Origin trial extension 1 end milestone

133

Shipping on Android

132

Origin trial Android first

128

Origin trial Android last

133



Anticipated spec changes

Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).

None


Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/6495400321351680?gate=4886628616372224


Links to previous Intent discussions

Intent to Prototype: https://groups.google.com/a/chromium.org/g/blink-dev/c/qqrG6yn1u1Q?pli=1

Intent to Experiment: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPTJ0XEedt%2Bu2pS_2NHHfxtEV9JJ7wbuKNEnieeWr6w8FtwKLw%40mail.gmail.com

Intent to Extend Experiment 1: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/66ec74bf.2b0a0220.195547.03af.GAE%40google.com



This intent message was generated by Chrome Platform Status.


Chris Harrelson

unread,
Nov 13, 2024, 11:29:25 AMNov 13
to Christian Biesinger, blink-dev
Most of these are still open, is something blocking finishing and landing these spec PRs?
 
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPTJ0XHfrr2FvW4qP%2BsS3Jn7DoE5oyTZETyuJTgT9wSN46ao4Q%40mail.gmail.com.

Christian Biesinger

unread,
Nov 13, 2024, 12:23:21 PMNov 13
to Chris Harrelson, blink-dev
On Wed, Nov 13, 2024 at 11:29 AM Chris Harrelson <chri...@chromium.org> wrote:


On Thu, Nov 7, 2024 at 3:46 PM Christian Biesinger <cbies...@chromium.org> wrote:

Most of these are still open, is something blocking finishing and landing these spec PRs?
 

We are waiting for reviews from outside of the team and WG approval to land them. No real blocker otherwise. A lot of WG calls have been cancelled recently which makes landing these take longer than we had hoped for.

Christian

Vladimir Levin

unread,
Nov 22, 2024, 3:13:01 PMNov 22
to Christian Biesinger, Chris Harrelson, blink-dev
Hey,

Looking over the first three APIs (Continuation API, Parameters API, Fields API), I understand how it solves the problem of asking for additional data from IdPs. Essentially (and please correct me if I'm wrong), RPs specify a list of fields (i.e. scopes), then the browser chooses whether to mediate or delegate based on whether it knows how to handle these scopes. [Side question: are these fields/scopes standardized somewhere: how is collision with what IdPs can provide vs the browser thinks it can mediate avoided?].

What is unclear to me is how the next two features (Multiple configURLs, Custom account labels) contribute to the experience. It seems that it allows the IdPs to provide different sets of accounts for different labels. Does that mean when the browser mediates account selection, it considers these labels and filters some accounts? Is this used when RPs need a particular field and only some accounts provide that? Is there a comprehensive "real world" example of this somewhere in the docs?

Separately, these features went through OT: is there a doc summarizing the participants' feedback?

Thanks!
Vlad

Christian Biesinger

unread,
Nov 22, 2024, 7:00:29 PMNov 22
to Vladimir Levin, Chris Harrelson, blink-dev
Hi Vlad,

We only want RPs to specify fields that are in this spec or a future version of it, although I recognize that because of the semantics of this parameter we can not enforce that. (custom scopes should be sent in `params`)

multiple configURLs is needed because our partner needed to use a different ID assertion endpoint for users requesting additional scopes.

I am unsure if I can share the exact use case of our partner regarding labels. But there are certain account types of this partner that they only support on the "authorization" endpoint and not on the regular "authentication" endpoint, and so they want that to be reflected in the account list (instead of failing later on).

I have summarized the OT feedback in the initial email under "Link to origin trial feedback summary".

Thanks,
Christian

Vladimir Levin

unread,
Nov 25, 2024, 12:48:05 PM (13 days ago) Nov 25
to Christian Biesinger, Chris Harrelson, blink-dev
Hey Christian,

Thank you for your reply. Additional questions below.

On Fri, Nov 22, 2024 at 7:00 PM Christian Biesinger <cbies...@chromium.org> wrote:
Hi Vlad,

We only want RPs to specify fields that are in this spec or a future version of it, although I recognize that because of the semantics of this parameter we can not enforce that. (custom scopes should be sent in `params`)

multiple configURLs is needed because our partner needed to use a different ID assertion endpoint for users requesting additional scopes.

I am unsure if I can share the exact use case of our partner regarding labels. But there are certain account types of this partner that they only support on the "authorization" endpoint and not on the regular "authentication" endpoint, and so they want that to be reflected in the account list (instead of failing later on).

That's understandable, I was just hoping for an example of how this flow would work. My understanding is something like the following. Suppose I have two accounts Foo and Bar that are provided by one IdP and the RP will need some additional scope that is only available for Foo. Then the filter API allows the browser to filter out Bar and only display Foo as an available option. What I'm missing is how this is orchestrated. Is it that RP that requests this filtering or IdP and how does the browser orchestrate this. From my reading IdPs return a list of all possible labels for each account and RPs request specific labels, and then the browser does the filtering. Is that correct? I'm guessing there is no optionality here in that if the list, for example, ends up being filtered to nothing, then RPs don't have a chance to say "this scope was nice to have but not required". What is the UX here if there is no match?

Thanks,
Vlad

Christian Biesinger

unread,
Nov 25, 2024, 1:54:09 PM (13 days ago) Nov 25
to Vladimir Levin, Chris Harrelson, blink-dev
On Mon, Nov 25, 2024 at 12:47 PM Vladimir Levin <vmp...@chromium.org> wrote:
Hey Christian,

Thank you for your reply. Additional questions below.

On Fri, Nov 22, 2024 at 7:00 PM Christian Biesinger <cbies...@chromium.org> wrote:
Hi Vlad,

We only want RPs to specify fields that are in this spec or a future version of it, although I recognize that because of the semantics of this parameter we can not enforce that. (custom scopes should be sent in `params`)

multiple configURLs is needed because our partner needed to use a different ID assertion endpoint for users requesting additional scopes.

I am unsure if I can share the exact use case of our partner regarding labels. But there are certain account types of this partner that they only support on the "authorization" endpoint and not on the regular "authentication" endpoint, and so they want that to be reflected in the account list (instead of failing later on).

That's understandable, I was just hoping for an example of how this flow would work. My understanding is something like the following. Suppose I have two accounts Foo and Bar that are provided by one IdP and the RP will need some additional scope that is only available for Foo. Then the filter API allows the browser to filter out Bar and only display Foo as an available option. What I'm missing is how this is orchestrated. Is it that RP that requests this filtering or IdP and how does the browser orchestrate this. From my reading IdPs return a list of all possible labels for each account and RPs request specific labels, and then the browser does the filtering. Is that correct? I'm guessing there is no optionality here in that if the list, for example, ends up being filtered to nothing, then RPs don't have a chance to say "this scope was nice to have but not required". What is the UX here if there is no match?

Let's say some account types do not support scopes at all and some do. Then the IDP will provide two different config files, one with `accounts: {include: "supports_scopes"}`, one with `accounts: {include: "does_not_support_scopes"}`. The account endpoint will send the correct label for each account. If an IDP has a smallish list of possible scopes, they can also provide a per-scope config file. We could let an RP specify labels directly in the future but have not done so here. (such a feature would have overlap with account/domain hints)

It is correct that there is no way to say "an account label would be nice but is not required", or indeed "a field would be nice but is not required". This could be added in the future.

UI-wise, "no matching accounts" is treated the same as if an account hint or domain hint does not match. The UI has gone through a few iterations, I believe what we settled on was show a dialog with a "log in to IDP" button for passive mode and a list of greyed out accounts for active mode, but I may misremember these details.

Christian 

Vladimir Levin

unread,
Nov 27, 2024, 9:40:56 AM (11 days ago) Nov 27
to Christian Biesinger, Chris Harrelson, blink-dev
Thank you for the explanation!

LGTM1

Rick Byers

unread,
Nov 27, 2024, 10:23:28 AM (11 days ago) Nov 27
to Vladimir Levin, Christian Biesinger, Chris Harrelson, blink-dev
LGTM2

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADsXd2Nuwsiq37AK4MCT_TYRi7p1Yxq-Pz%2BGe_jt%3DfX6L%3DayjA%40mail.gmail.com.

Mike Taylor

unread,
Nov 27, 2024, 1:30:49 PM (11 days ago) Nov 27
to Rick Byers, Vladimir Levin, Christian Biesinger, Chris Harrelson, blink-dev

LGTM3

Reply all
Reply to author
Forward
0 new messages