I sent this intent before the feature was ready, and this required a lot of UX work, so trial has not started. Our plan is to start on Chrome M126 so I will assume the approvals are shifted to 126 - 130. If there are concerns let me know, thanks!
On Tuesday, February 27, 2024 at 3:04:38 PM UTC-5 Yoav Weiss wrote: > LGTM to experiment M124-M128 inclusive > > On Tue, Feb 27, 2024 at 4:16 PM Nicolás Peña <n...@chromium.org> wrote: > >> Done >> >> On Monday, February 26, 2024 at 7:55:09 PM UTC-5 Mike Taylor wrote: >> > Could you please request reviews for the privacy/security/debuggability >>> review gates in your chromestatus entry? >>> On 2/21/24 3:21 PM, Nicolás Peña wrote: >>> >>> Contact emails >>> >>> n...@chromium.org >>> >>> Explainer >>> >>> The Federated Credential Management (FedCM) API currently only allows >>> one identity provider (IDP) to be used when performing federated login in a >>> website. We would like to experiment with allowing multiple providers to be >>> specified in a single JavaScript get() call, which allows FedCM to be used >>> in cases for which the website supports multiple IDPs for federation. See >>> also additional context in https://github.com/fedidcg/FedCM/issues/319. >>> >>> Specification >>> >>> https://fedidcg.github.io/FedCM >>> >>> Summary >>> >>> Allows FedCM to show multiple IDPs in the same dialog. This provides >>> developers with a convenient way to present all supported identity >>> providers to users. In this I2E, we are tackling the simple case of having >>> all providers in the same get() call, while building much of the UX >>> infratructure that will allow us to tackle more sophisticated production >>> structures later. >>> >>> >>> Blink component >>> >>> Blink>Identity>FedCM >>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EIdentity%3EFedCM> >>> >>> TAG review >>> >>> https://github.com/w3ctag/design-reviews/issues/803 >>> >>> TAG review status >>> >>> Pending >>> >>> 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. In order to determine whether multiple IDPs are supported in a >>> browser which supports FedCM, the developer can attempt to first call get() >>> with multiple IDPs. It will be rejected immediately if not supported and >>> the RP can retry with a single IDP. >>> >>> >>> Gecko: No signal ( >>> https://github.com/mozilla/standards-positions/issues/730) >>> >>> WebKit: No signal ( >>> https://github.com/WebKit/standards-positions/issues/120) >>> >>> 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 may be challenging in some cases because IDPs generally >>> are independent from each other. That said, 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 due to 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? >>> >>> n/a, FedCM is not supported on WebView >>> >>> >>> Goals for experimentation >>> >>> We want to ensure that the single get() call is sufficient for the use >>> cases we are targeting, where the multiple IDPs are owned by a single >>> entity, as well as gather developer feedback before fully shipping. The >>> multiple independent IDPs scenario is out of scope for experimentation, as >>> we anticipate that it will be hard to impossible to use FedCM in a single >>> get() call in such a scenario. >>> >>> A successful trial would result in our partner requesting us to ship >>> this feature to allow using FedCM with their multiple IDPs. >>> >>> 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 chrome://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 >>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>> ? >>> >>> Yes >>> >>> >>> https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/external/wpt/credential-management/fedcm-multi-idp/ >>> >>> Some of these tests are not relevant as they are related to the multi-get() >>> approach. >>> >>> >>> Flag name on chrome://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 >>> >>> DevTrial on desktop >>> >>> 122 >>> >>> OT desktop 124 - 128 >>> >>> OT Android 125 - 128 >>> >>> Link to entry on the Chrome Platform Status >>> >>> https://chromestatus.com/feature/5067784766095360 >>> >>> 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+...@chromium.org. >>> >>> >>> To view this discussion on the web visit >>> 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?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+...@chromium.org. >> To view this discussion on the web visit >> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/e11bb292-708d-4f11-a26e-62530880e763n%40chromium.org >> >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/e11bb292-708d-4f11-a26e-62530880e763n%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 on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/f58b4905-ed33-4200-bffc-83fd5b017912n%40chromium.org.
