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 > > Explainer > > https://github.com/w3c-fedid/multi-idp/blob/main/README.md > > Specification > > 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 > > 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 > > 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) but they > supported the extension in > https://github.com/mozilla/standards-positions/issues/730#issuecomment-1961733855 > and > https://github.com/w3ctag/design-reviews/issues/803#issuecomment-2697735993 > . > > > WebKit: Closed Without a Position ( > 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. > > Web developers: Positive (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 > . > > > 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 > > Flag name on about://flags > > FedCmMultiIdp > > Finch feature name > > FedCmMultipleIdentityProviders > > Requires code in //chrome? > > True > > Tracking bug > > issues.chromium.org/issues/392142260 > > Launch bug > > 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 > > 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 > > Intent to Extend Experiment 1: > 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: > - > > Through our OT: while our partners have not shipped, we had a lot > of excitement from the dev trials. > - > > 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.
