LGTM2 (it took me a minute to realize this exposes the top frame origin
to the IDP, and offers a way for a site to control if the user sees 2 or
3 hostnames in the sign in UI).
On 9/22/25 2:44 p.m., Alex Russell wrote:
LGTM1
On Thursday, September 18, 2025 at 6:08:13 AM UTC-7 Yi Gu wrote:
Hi Yoav,
Yes, this is controlled by developers.
Currently, when fetching the client metadata endpoint, the browser
sends the API caller's origin and client ID to the IdP. With this
proposal, if the API is called from within a cross-site iframe
(and allowed by the embedder via a permissions policy), the
browser will also send the top frame's origin to that endpoint.
Upon receiving both origins, the IdP can choose to return a
boolean in the response, indicating whether they want to call out
the actual token destination in the browser UI.
Yi
On Thu, Sep 18, 2025 at 1:24 AM Yoav Weiss (@Shopify)
<[email protected]> wrote:
Can you clarify what the web-exposed parts of this feature
would be? Do developers have control over which iframe would
be presented in the UI (either the RP developers or the IDP ones)?
On Tue, Sep 16, 2025 at 6:23 PM Chromestatus
<[email protected]
<mailto:[email protected]>> wrote:
*Contact emails*
[email protected]
*Explainer*
https://github.com/w3c-fedid/FedCM/issues/449#issuecomment-1515631336
<https://github.com/w3c-fedid/FedCM/issues/449#issuecomment-1515631336>
*Specification*
https://github.com/w3c-fedid/FedCM/pull/774
<https://github.com/w3c-fedid/FedCM/pull/774>
*Summary*
Currently, FedCM always shows the toplevel site in its UI.
This works well when the iframe is conceptually
first-party (e.g. foo.com <https://foo.com> may have an
iframe foostatic.com <https://foostatic.com>, which is not
meaningful to the user). But if the iframe is actually
third-party, it would be better to make it possible to
show the iframe origin in the UI so that the user better
understands who they are sharing their credentials with.
For example, a photo editor may be embedded in a book
publishing web app and may want to let users access files
they have previously stored with the photo editor. This
proposal allows doing so.
*Blink component*
Blink>Identity>FedCM
<https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3EIdentity%3EFedCM%22>
*Web Feature ID*
fedcm <https://webstatus.dev/features/fedcm>
*Search tags*
fedcm <http:///features#tags:fedcm>, iframe
<http:///features#tags:iframe>
*TAG review*
https://github.com/w3ctag/design-reviews/issues/1136
<https://github.com/w3ctag/design-reviews/issues/1136>
*TAG review status*
Pending
*Risks*
*Interoperability and Compatibility*
No compat risk as this is a purely additive feature. For
interop, if other browsers adopt FedCM but do not
implement this feature, their UI will just show the
toplevel site instead of the iframe site. That is, the UI
is not as good, but the user is still able to log in.
/Gecko/: No signal For incremental improvements to FedCM,
Firefox has asked us not to file standards position, and
they will instead provide feedback in the GitHub PR..
Firefox engineer "not willing to block this",
https://github.com/w3c-fedid/FedCM/issues/725#issuecomment-3189376203
<https://github.com/w3c-fedid/FedCM/issues/725#issuecomment-3189376203>
/WebKit/: No signal Safari is not implementing FedCM in
general. They have closed other position requests for
specific FedCM additions as duplicates of the general
FedCM position request, e.g.
https://github.com/WebKit/standards-positions/issues/120#issuecomment-1914040695
<https://github.com/WebKit/standards-positions/issues/120#issuecomment-1914040695>
/Web developers/: Positive This was requested by web
developer partners. Our partners have tried out the Chrome
implementation behind a flag and found it to match their
expectations.
/Other signals/:
*Ergonomics*
n/a
*Activation*
No risk -- IDPs can simply look for the new request field
and respond with the new response field without risk of
breaking older releases or other browsers.
*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 not supported in
WebView
*Debuggability*
Same as other FedCM features. The network view in devtools
would be especially helpful for debugging this feature.
*Will this feature be supported on all six Blink platforms
(Windows, Mac, Linux, ChromeOS, Android, and Android
WebView)?*
NoFedCM in general is not supported on webview. Supported
on all other blink platforms.
*Is this feature fully tested by web-platform-tests
<https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?*
Yeshttps://wpt.fyi/results/fedcm/third-party-iframe?label=experimental&label=master
<https://wpt.fyi/results/fedcm/third-party-iframe?label=experimental&label=master>
*Flag name on about://flags*
FedCmIframeOrigin
*Finch feature name*
FedCmIframeOrigin
*Rollout plan*
Will ship enabled for all users
*Requires code in //chrome?*
True
*Tracking bug*
https://crbug.com/390581529
*Launch bug*
https://launch.corp.google.com/launch/4408324
<https://launch.corp.google.com/launch/4408324>
*Non-OSS dependencies*
Does the feature depend on any code or APIs outside the
Chromium open source repository and its open-source
dependencies to function? none
*Estimated milestones*
Shipping on desktop 142
Shipping on Android 142
*Anticipated spec changes*
Open questions about a feature may be a source of future
web compat or interop issues. Please list open issues
(e.g. links to known github issues in the project for the
feature specification) whose resolution may introduce web
compat/interop risk (e.g., changing to naming or structure
of the API in a non-backward-compatible way). none
*Link to entry on the Chrome Platform Status*
https://chromestatus.com/feature/5176474637959168?gate=6194078890983424
<https://chromestatus.com/feature/5176474637959168?gate=6194078890983424>
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
[email protected]
<mailto:[email protected]>.
To view this discussion visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/68c98f0b.050a0220.180098.04b2.GAE%40google.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/68c98f0b.050a0220.180098.04b2.GAE%40google.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 [email protected]
<mailto:[email protected]>.
To view this discussion visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOmohSKgL17FAqqRC%3DgukkmbyKA708KQzw956HvP1WGs73vUHw%40mail.gmail.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOmohSKgL17FAqqRC%3DgukkmbyKA708KQzw956HvP1WGs73vUHw%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 [email protected].
To view this discussion visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/50cae861-41c1-4707-94ea-fb39010a452fn%40chromium.org
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/50cae861-41c1-4707-94ea-fb39010a452fn%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 [email protected].
To view this discussion visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/e595a143-11a5-4134-a1a3-651167eb7afa%40chromium.org.
