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) < > yoavwe...@chromium.org> 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 < >> ad...@cr-status.appspotmail.com> wrote: >> >>> *Contact emails* >>> cbiesin...@chromium.org >>> >>> *Explainer* >>> https://github.com/w3c-fedid/FedCM/issues/449#issuecomment-1515631336 >>> >>> *Specification* >>> 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 may have >>> an iframe 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 >>> >>> *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 >>> >>> *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 >>> >>> *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>?* >>> Yes >>> 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 >>> >>> *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 >>> >>> 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/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 blink-dev+unsubscr...@chromium.org. >> > 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 blink-dev+unsubscr...@chromium.org. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/50cae861-41c1-4707-94ea-fb39010a452fn%40chromium.org.
