Thanks LGTM to extend to 133 inclusive, given the progress on the
proposal in the WG, and iteration on the API design/UI .
If you were to request another extension down the road, I would expect
to see further progress on the spec PR, and updated tests to match.
thanks,
Mike
On 9/30/24 9:01 AM, Yi Gu wrote:
Contact emails
y...@chromium.org, tanzach...@chromium.org
<mailto:cbiesin...@chromium.org>, cbiesin...@chromium.org,
<mailto:cbiesin...@chromium.org>
Explainer
https://github.com/w3c-fedid/active-mode
Specification
None
Summary
We plan to experiment with two new extensions for the
Federated Credential Management (FedCM) API:
*
Button Mode API
o
The button mode lets websites trigger FedCM directly
when a user clicks a button (like a "Sign-in with IdP"
button). This means FedCM will always display a
visible user interface for login, in contrast to the
widget mode where no UI is shown if a user’s login
status is logged out.
o
When the FedCM API is used in "button mode" and a user
isn't logged in, they'll be taken to the IdP login
screen (in a pop-up window). Since this happens in
response to a clear user action, the UI might even be
more prominent (e.g., centered and modal) compared to
the more subtle UI of widget mode.
*
Use Other Account API
o
With this API, an Identity Provider can request the
browser to show a button that allows users to choose
other accounts.
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/935
<https://github.com/w3ctag/design-reviews/issues/935>
TAG review status
Pending
Chromium Trial Name
FedCmButtonMode
Origin Trial documentation link
https://github.com/w3c-fedid/FedCM/blob/main/explorations/HOWTO-chrome.md#button-mode-api
WebFeature UseCounter name
kFedCmButtonMode
Risks
Interoperability and Compatibility
These are extensions to the FedCM API. Apple and Mozilla have
both expressed a positive opinion on the initial FedCM API
[1]. They have not yet shipped but Mozilla is prototyping [2].
If a user agent chooses not to implement these extensions, the
sign-in flow should not be affected in that user agent because
developers can fallback to the existing federated sign-in
mechanisms.
[1]
https://groups.google.com/a/chromium.org/g/blink-dev/c/URpYPPH-YQ4/m/bzghj9N3AQAJ
<https://groups.google.com/a/chromium.org/g/blink-dev/c/URpYPPH-YQ4/m/bzghj9N3AQAJ>
[2]
https://groups.google.com/a/mozilla.org/g/dev-platform/c/ncmUwK1uO98/m/COhPA4ZrAAAJ
<https://groups.google.com/a/mozilla.org/g/dev-platform/c/ncmUwK1uO98/m/COhPA4ZrAAAJ>
Gecko: No signal
WebKit: No signal
Web developers: Positive
(https://github.com/fedidcg/FedCM/issues/442
<https://github.com/fedidcg/FedCM/issues/442>) These features
are being developed to address existing feedback for the FedCM
API.
Other signals:
Activation
Similar to the FedCM API, we deliberately leave the bulk of
the work to the IdP to ensure that minimal RP change is needed.
This feature, specifically, is one that can be currently
controlled by IdP (via JS SDK for “button mode”, via
server-side config for “use other account”), so we expect
activation to have a similar profile as FedCM: immediately
enabled to websites (without redeployment) by IdPs making use
of it (by redeploying their JS SDKs).
Security
The button mode shares most of the security properties from
the widget mode. e.g. honoring CSP, CORS, using security
headers, not asking users to type in the browser UI etc.
It’s worth noting that the pop-up window has the same web
platform properties as what one would get with
window.open(url,””,”popup,noopener,noreferrer”) that loads the
login_url. It is important to note that there's no
communication allowed between the website and this pop-up
(e.g. no postMessage, no window.opener). We have shipped
LoginStatus API and Error API in FedCM that use this type of
pop-up window.
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?
None
Goals for experimentation
Gather data on whether a browser mediated sign in flow on a
critical user journey is well received by users and
developers. We'd like to see how the proposed UI/API play out
and iterate on them to ship the API in its best shape.
Reason this experiment is being extended
We have been addressing feedback on the API as well as the UI since
the OT starts. Therefore we'd like to extend the OT to test the new
changes and support partners to run further experiments.
Progress update per I2EE requirement
<https://www.chromium.org/blink/launching-features/#origin-trials>:
* Draft spec: The Button Mode API (recently renamed to "FedCM Mode
API") has advanced
<https://github.com/w3c-fedid/active-mode/issues/2#issuecomment-2379788096>
to
stage 2
<https://github.com/w3c-fedid/Administration/blob/main/proposals-CG-WG.md#stage2>
in
Federated Identity Working Group which means that this work has
received WG consensus to adopt the proposal as the basis for the
work as a Working Draft. We are working on a spec PR at this moment.
* TAG review: Done in the initial I2E thread
* bit.ly/blink-signals <http://bit.ly/blink-signals> requests: Done
in the initial I2E thread
* Outreach for feedback from the spec community: Done in the initial
I2E thread
* WPT tests: Done in the initial I2E thread
Ongoing technical constraints
None
Debuggability
No special support needed
Will this feature be supported on all six Blink platforms
(Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?
No
FedCM in general is not supported in 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-button-and-other-account?label=experimental&label=master&aligned
<https://wpt.fyi/results/fedcm/fedcm-button-and-other-account?label=experimental&label=master&aligned> (They
currently fail on wpt.fyi because the feature is off by default)
Flag name on chrome://flags
FedCmButtonMode, FedCmUseOtherAccount
Finch feature name
kFedCmButtonMode
kFedCmUseOtherAccount
Requires code in //chrome?
True
Tracking bug
https://crbug.com/40284792 <https://crbug.com/40284792>
Launch bug
https://launch.corp.google.com/launch/4293366
<https://launch.corp.google.com/launch/4293366>
Estimated milestones
Origin trial desktop first 125
Origin trial Android first 128
Origin trial extension 1 end milestone 130
Origin trial extension 2 end milestone 133
Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/4689551782313984
<https://chromestatus.com/feature/4689551782313984>
Links to previous Intent discussions
Intent to prototype:
https://groups.google.com/a/chromium.org/g/blink-dev/c/hZg8ice8f0A/m/ubJPHUsDAwAJ
Intent to experiment:
https://groups.google.com/a/chromium.org/g/blink-dev/c/bQqXXv2S9q0
--
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/CACh2XCMPQ9s2hUR2UYuTTkRDra0qfjxBXA0bOme2baQGbPE6NA%40mail.gmail.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACh2XCMPQ9s2hUR2UYuTTkRDra0qfjxBXA0bOme2baQGbPE6NA%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 on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/7d74745b-a597-45b3-be50-401310c2083f%40chromium.org.
