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
<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 <http://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
<https://github.com/w3c-fedid/multi-idp/blob/main/README.md>
Specification
PR will be written for https://w3c-fedid.github.io/FedCM/
<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
<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
<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
<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
<https://github.com/WebKit/standards-positions/issues/120>)
Web developers: Positive
(https://github.com/w3c-fedid/multi-idp/issues/2
<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/
<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
<https://bugs.chromium.org/p/chromium/issues/detail?id=1348262>
Launch bug
https://launch.corp.google.com/launch/4229762
<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
<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
<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
<mailto: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/9d3104f9-ef64-48eb-a7fb-843c71083777%40chromium.org.
