LGTM2

/Daniel

On 2025-03-31 17:28, Rick Byers wrote:
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>.

--
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/99036f85-4ad4-4007-9fcc-4ed01f265556%40gmail.com.

Reply via email to