We decided to further delay the start of the OT since our partner needs more time before they can put it in front of real users, so the current plan it to do the experiment on milestones 128 - 132.
On Tuesday, April 23, 2024 at 4:01:15 PM UTC-4 Nicolás Peña Moreno wrote: > 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/3c9359bf-8827-4d62-9f0a-65c6121b2852n%40chromium.org.
