Created https://github.com/w3c-fedid/FedCM/pull/686
On Monday, December 9, 2024 at 7:10:26 PM UTC-5 Mike Taylor wrote: > On 12/9/24 11:33 PM, Nicolás Peña wrote: > > > On Monday, December 9, 2024 at 8:06:47 AM UTC-5 Mike Taylor wrote: > > Just to clarify: you're requesting a renewal for 3 milestones (thus, 133 - > 135 inclusive), correct? > > I was hoping to extend to 136, but I am now seeing each request is > extended for 3 milestones at a time so 135 is OK. > > Ack. > > Also, can you comment on progress made for the following (from > https://www.chromium.org/blink/launching-features/#origin-trials)? > > Draft spec (early draft is ok, but must be spec-like and associated with > the appropriate standardization venue, or WICG) > > No update. Latest draft was https://github.com/w3c-fedid/FedCM/pull/438. > This is outdated though, so I'll need to create a new PR for this. Is this > a blocker for the extension? > > Would it be a prohibitive amount of work to create a new PR? Or is there > some other reason why you wouldn't at this stage? Doing so would satisfy > the progress requirements for an extension, IMHO. > > TAG review (see exceptions) > > No update. The TAG review is open and they have not said anything. > > bit.ly/blink-signals requests > > Mozilla https://github.com/mozilla/standards-positions/issues/730 still > open but positive comment. > > Thanks - it does appear supportive, but not officially so. > > Apple https://github.com/WebKit/standards-positions/issues/120 closed as > duplicate of the general FedCM one, which is still open. > > Outreach for feedback from the spec community > > I don't know what this means. > > If an spec for an experiment didn't have eyeballs on it from the wider web > standards community, it would be appropriate to request that. But not > relevant here. > > WPT tests > > Obsolete tests relating to onload heuristic were cleaned up and the > current tests are > > https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/external/wpt/fedcm/fedcm-multi-idp/ > > > On 12/6/24 4:59 AM, Nicolás Peña wrote: > > Contact emails > > n...@chromium.org > > Explainer > > https://github.com/w3c-fedid/multi-idp/blob/main/README.md > > Specification > > PR will be written for https://w3c-fedid.github.io/FedCM/ > > Summary > > Allows FedCM to show multiple identity providers 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. > > 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 > > 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#origin_trial_multi_idp_api > > 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 Firefox and > Safari. > > > Gecko: No signal (https://github.com/mozilla/ > standards-positions/issues/730) but we have heard positive feedback > <https://github.com/mozilla/standards-positions/issues/730#issuecomment-1961733855> > > that this is needed for FedCM > > WebKit: Closed Without a Position (https://github.com/WebKit/ > standards-positions/issues/120) > > Web developers: Positive (https://github.com/w3c-fedid/multi-idp/issues/2) > > 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. > > > 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? > > > Goals for experimentation > > Gather UX feedback and determine whether the API shape is sufficient for > use cases where multiple IdPs can collaborate in a single JS call. > > Reason this experiment is being extended > > Our partner remains committed to experimentation and they have been > working with their relying parties to experiment, but this has taken longer > than expected. > > 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 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/fedcm/fedcm-multi-idp/ > > Flag name on about://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 > > Origin trial desktop first > > 128 > > Origin trial desktop last > > 132 > > Origin trial extension 1 end milestone > > 136 > > DevTrial on desktop > > 122 > Link to entry on the Chrome Platform Status > > https://chromestatus.com/feature/5067784766095360?gate=4898496946372608 > > 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 > > > 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/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?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/891390a3-72ff-4e1c-89ad-14e6fd7878f0n%40chromium.org.
