Groups keyboard shortcuts have been updated
Dismiss
See shortcuts

Intent to Extend Experiment: FedCM multi IDP in single get() call

134 views
Skip to first unread message

Nicolás Peña

unread,
Dec 5, 2024, 2:59:45 PM12/5/24
to blink-dev
Contact emails

n...@chromium.org


Explainer

https://github.com/w3c-fedid/multi-idp/blob/main/README.md


Specification

PR will be written for https://w3c-fedid.github.io/FedCM/


Summary

Allows FedCM to show multiple identity providers in the same dialog. This provides developers with a convenient way to present all supported identity providers to users. We are planning to first tackle the simple case of having all providers in the same get() call.


Blink component

Blink>Identity>FedCM


TAG review

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


TAG review status

Pending


Origin Trial Name

FedCM Multiple Identity Providers


Chromium Trial Name

FedCmMultipleIdentityProviders


Origin Trial documentation link

https://developers.google.com/privacy-sandbox/blog/fedcm-chrome-128-updates#origin_trial_multi_idp_api


WebFeature UseCounter name

kFedCmMultipleIdentityProviders


Risks

Interoperability and Compatibility

This should not have additional interop risks on top of the existing FedCM API which is generally supported but not yet implemented by Firefox and Safari.



Gecko: No signal (https://github.com/mozilla/standards-positions/issues/730) but we have heard positive feedback that this is needed for FedCM


WebKit: Closed Without a Position (https://github.com/WebKit/standards-positions/issues/120)


Web developers: Positive (https://github.com/w3c-fedid/multi-idp/issues/2)


Ergonomics

Using this API will just require expanding the get() to use more providers, so it will benefit from the ergonomics of the initial FedCM API.


Activation

The main activation issue is having to include all IDPs in the same get() call, which is tough because IDPs generally are independent from each other. That said, solving this problem has been proved to be very challenging, and we do have developers who can use the single get() call, so we wish to start with the simpler version of multi IDP support.



Security

The security considerations are similar to those of the single IDP case. We do not require users to input usernames and passwords for spoofing concerns, and we also have input protection to prevent accidental click right after the UI is shown.



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?



Goals for experimentation

Gather UX feedback and determine whether the API shape is sufficient for use cases where multiple IdPs can collaborate in a single JS call.


Reason this experiment is being extended

Our partner remains committed to experimentation and they have been working with their relying parties to experiment, but this has taken longer than expected.


Ongoing technical constraints

None


Debuggability

The debug tools are similar to that of original FedCM: console messages and DevTools issues. Seeing FedCM network requests is not supported in DevTools but can be achieved via net-export.



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

No

As with the initial FedCM, we do not support Android WebView.



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

Yes

https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/external/wpt/fedcm/fedcm-multi-idp/


Flag name on about://flags

FedCmMultiIdp


Finch feature name

FedCmMultipleIdentityProviders


Requires code in //chrome?

True


Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1348262


Launch bug

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


Estimated milestones

Origin trial desktop first


128


Origin trial desktop last


132


Origin trial extension 1 end milestone


136


DevTrial on desktop


122

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5067784766095360?gate=4898496946372608


Links to previous Intent discussions

Intent to Experiment: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/9c4ae5a9-5f36-4421-82c6-07b676ef768cn%40chromium.org



This intent message was generated by Chrome Platform Status.


Mike Taylor

unread,
Dec 9, 2024, 8:06:47 AM12/9/24
to Nicolás Peña, blink-dev

Just to clarify: you're requesting a renewal for 3 milestones (thus, 133 - 135 inclusive), correct?

Also, can you comment on progress made for the following (from https://www.chromium.org/blink/launching-features/#origin-trials)?

Draft spec (early draft is ok, but must be spec-like and associated with the appropriate standardization venue, or WICG)
TAG review (see exceptions)
bit.ly/blink-signals requests
Outreach for feedback from the spec community
WPT tests

--
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/eeb64bec-d48b-4479-8f89-c7a4054b906fn%40chromium.org.

Nicolás Peña

unread,
Dec 9, 2024, 9:33:56 AM12/9/24
to blink-dev, Mike Taylor, blink-dev, Nicolás Peña
On Monday, December 9, 2024 at 8:06:47 AM UTC-5 Mike Taylor wrote:

Just to clarify: you're requesting a renewal for 3 milestones (thus, 133 - 135 inclusive), correct?

I was hoping to extend to 136, but I am now seeing each request is extended for 3 milestones at a time so 135 is OK.

Also, can you comment on progress made for the following (from https://www.chromium.org/blink/launching-features/#origin-trials)?

Draft spec (early draft is ok, but must be spec-like and associated with the appropriate standardization venue, or WICG)

No update. Latest draft was https://github.com/w3c-fedid/FedCM/pull/438. This is outdated though, so I'll need to create a new PR for this. Is this a blocker for the extension?

TAG review (see exceptions)

No update. The TAG review is open and they have not said anything.
Mozilla https://github.com/mozilla/standards-positions/issues/730 still open but positive comment.
Apple https://github.com/WebKit/standards-positions/issues/120 closed as duplicate of the general FedCM one, which is still open. 

Outreach for feedback from the spec community

I don't know what this means. 

WPT tests

Obsolete tests relating to onload heuristic were cleaned up and the current tests are
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

Mike Taylor

unread,
Dec 9, 2024, 7:10:26 PM12/9/24
to Nicolás Peña, blink-dev

On 12/9/24 11:33 PM, Nicolás Peña wrote:


On Monday, December 9, 2024 at 8:06:47 AM UTC-5 Mike Taylor wrote:

Just to clarify: you're requesting a renewal for 3 milestones (thus, 133 - 135 inclusive), correct?

I was hoping to extend to 136, but I am now seeing each request is extended for 3 milestones at a time so 135 is OK.
Ack.

Also, can you comment on progress made for the following (from https://www.chromium.org/blink/launching-features/#origin-trials)?

Draft spec (early draft is ok, but must be spec-like and associated with the appropriate standardization venue, or WICG)

No update. Latest draft was https://github.com/w3c-fedid/FedCM/pull/438. This is outdated though, so I'll need to create a new PR for this. Is this a blocker for the extension?
Would it be a prohibitive amount of work to create a new PR? Or is there some other reason why you wouldn't at this stage? Doing so would satisfy the progress requirements for an extension, IMHO.

TAG review (see exceptions)

No update. The TAG review is open and they have not said anything.
Mozilla https://github.com/mozilla/standards-positions/issues/730 still open but positive comment.
Thanks - it does appear supportive, but not officially so.

Apple https://github.com/WebKit/standards-positions/issues/120 closed as duplicate of the general FedCM one, which is still open. 

Outreach for feedback from the spec community

I don't know what this means.
If an spec for an experiment didn't have eyeballs on it from the wider web standards community, it would be appropriate to request that. But not relevant here.

Nicolás Peña

unread,
Dec 10, 2024, 3:00:40 PM12/10/24
to blink-dev, Mike Taylor, Nicolás Peña

Mike Taylor

unread,
Dec 11, 2024, 8:23:02 AM12/11/24
to Nicolás Peña, blink-dev

Thank you! 

LGTM to extend for 3 milestones from M133 to M135 inclusive.

Reply all
Reply to author
Forward
0 new messages