LGTM1
FWIW I've always considered it a bug that FedCM only supported a
single IDP at a time. I know there are complex UX design issues to
address and a couple small tweaks in the API. The promise of FedCM
always was that it could be a single UI surface that intersected the
list of IDPs a site supports with the accounts the user has to help
the user select the best choice for them. Thank you for delivering on
this promise!
Rick
On Mon, Mar 31, 2025 at 10:57 AM Nicolás Peña <n...@chromium.org> wrote:
Contact emails
n...@chromium.org <mailto:n...@chromium.org>
Explainer
https://github.com/w3c-fedid/multi-idp/blob/main/README.md
Specification
https://github.com/w3c-fedid/FedCM/pull/686
<https://github.com/w3c-fedid/FedCM/pull/686>
Summary
Allows FedCM to show multiple identity providers (IDPs) 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 (e.g. allowing more than one entry in the
existing array) and passive mode.
We are also removing support for ‘add another account’ in FedCM
passive mode. This feature allows showing a ‘use another account’
button alongside other IdP accounts in the chooser. The feature
is currently unused, and UX conversations have led us to believe
that supporting this leads to a more complicated flow without
much benefit. This feature will still work in FedCM active mode.
Blink component
Blink>Identity>FedCM
<https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3EIdentity%3EFedCM%22>
TAG review
https://github.com/w3ctag/design-reviews/issues/803
<https://github.com/w3ctag/design-reviews/issues/803>
TAG review status
Issues addressed
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
<https://developers.google.com/privacy-sandbox/blog/fedcm-chrome-128-updates>
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 Gecko and WebKit.
Gecko: No signal
(https://github.com/mozilla/standards-positions/issues/730
<https://github.com/mozilla/standards-positions/issues/730>) but
they supported the extension in
https://github.com/mozilla/standards-positions/issues/730#issuecomment-1961733855
<https://github.com/mozilla/standards-positions/issues/730#issuecomment-1961733855>and
https://github.com/w3ctag/design-reviews/issues/803#issuecomment-2697735993
<https://github.com/w3ctag/design-reviews/issues/803#issuecomment-2697735993>.
WebKit: Closed Without a Position
(https://github.com/WebKit/standards-positions/issues/120
<https://github.com/WebKit/standards-positions/issues/120>) as
they want to give a holistic review in
https://github.com/WebKit/standards-positions/issues/309
<https://github.com/WebKit/standards-positions/issues/309>.
Web developers: Positive
(https://github.com/fedidcg/FedCM/issues/319
<https://github.com/fedidcg/FedCM/issues/319>)
Other signals:
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. Also, of course one IdP should not learn information from
another IdP. The token received is passed directly to the RP.
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. FedCM does not currently work in WebView
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, per
https://github.com/w3c-fedid/FedCM/blob/e3e894c212e2b9c976fb9e2df268982bbdf947dd/explorations/debug-network-requests-chrome.md
<https://github.com/w3c-fedid/FedCM/blob/e3e894c212e2b9c976fb9e2df268982bbdf947dd/explorations/debug-network-requests-chrome.md>.
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
<https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?
Yes
https://wpt.fyi/results/fedcm/fedcm-multi-idp?label=experimental&label=master&aligned
<https://wpt.fyi/results/fedcm/fedcm-multi-idp?label=experimental&label=master&aligned>
Flag name on about://flags
FedCmMultiIdp
Finch feature name
FedCmMultipleIdentityProviders
Requires code in //chrome?
True
Tracking bug
issues.chromium.org/issues/392142260
<http://issues.chromium.org/issues/392142260>
Launch bug
https://launch.corp.google.com/launch/4318007
<https://launch.corp.google.com/launch/4318007>
Availability expectation
Feature is available only in Chromium browsers at first. Possibly
available in Firefox later on since they have expressed interest
in shipping FedCM.
Adoption expectation
Feature is used by specific partner(s) to provide functionality
within 12 months of launch in Chrome. May later on be considered
a best practice for federation in certain scenarios.
Adoption plan
We have been running an Origin Trial with our partners which is
going well so far. We intend to also achieve greater adoption by
notifying developers interested in FedCM about the availability
of multiple IDPs at the same time.
Non-OSS dependencies
Does the feature depend on any code or APIs outside the Chromium
open source repository and its open-source dependencies to function?
No
Estimated milestones
Shipping on desktop
136
Origin trial desktop first
128
Origin trial desktop last
135
Origin trial extension 1 end milestone
135
DevTrial on desktop
122
Shipping on Android
136
Anticipated spec changes
N/A
Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5067784766095360?gate=5297387694718976
<https://chromestatus.com/feature/5067784766095360?gate=5297387694718976>
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
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/9c4ae5a9-5f36-4421-82c6-07b676ef768cn%40chromium.org>
Intent to Extend Experiment 1:
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/eeb64bec-d48b-4479-8f89-c7a4054b906fn%40chromium.org
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/eeb64bec-d48b-4479-8f89-c7a4054b906fn%40chromium.org>
I will note that we are still waiting on our Origin Trial (OT)
partners to finish setting up their infrastructure to begin the
OT testing real users, but they are very excited about the API
and we have decided to ship this despite not having a lot of
deployment feedback for the following reasons:
*
This API is almost a bugfix, in the sense that it enables
FedCM to truly shine by allowing the website to request
multiple IDPs at the same time. We knew we were going to ship
this extension at some point in the future ever since our
origin FedCM I2S.
*
Firefox is increasingly more interested in implementing
FedCM, and in their view a minimal viable version requires
multi-IDP support. Thus, this launch actually makes FedCM
more cross browser compatible.
*
We believe that there are great use cases for FedCM when
multiple IDPs are involved. Activation is just hard because,
unlike single-IDP FedCM, there is just nothing like it
currently. But developers gravitate towards APIs that they
can already use today, so we believe shipping will help us
advertise this FedCM extension for the use cases where it can
be useful. The evidence of demand, while not super direct, is
still strong in a couple of ways:
o
Through our OT: while our partners have not shipped, we
had a lot of excitement from the dev trials.
o
Through future extensions of FedCM which have gathered
lots of interest, such as IDP registration
<https://github.com/w3c-fedid/idp-registration>. The
multi IDP extension is a requirement for this feature,
and it is a building block or enhances other extensions
such as lightweight fedcm
<https://github.com/fedidcg/LightweightFedCM>.
This intent message was generated by Chrome Platform Status
<https://chromestatus.com/>.
--
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+unsubscr...@chromium.org.
To view this discussion visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/2b869445-e362-47f9-acb9-61ab63d302e7n%40chromium.org
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/2b869445-e362-47f9-acb9-61ab63d302e7n%40chromium.org?utm_medium=email&utm_source=footer>.
--
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+unsubscr...@chromium.org.
To view this discussion visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY-6W%3D7jMvaimb%3D92BRjZqU_qpXvtqSZig%2BX_QDftrSGVw%40mail.gmail.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY-6W%3D7jMvaimb%3D92BRjZqU_qpXvtqSZig%2BX_QDftrSGVw%40mail.gmail.com?utm_medium=email&utm_source=footer>.
