Intent to Ship: FedCM—Support showing third-party iframe origins in the UI

[Chromestatus]

Contact emails

cbies...@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

Web Feature ID

fedcm

Search tags

fedcm, 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?

Yeshttps://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.

[Yoav Weiss (@Shopify)]

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)?

--
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+...@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.

[Yi Gu]

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

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOmohSKgL17FAqqRC%3DgukkmbyKA708KQzw956HvP1WGs73vUHw%40mail.gmail.com.

[Alex Russell]

LGTM1

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@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.

--
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+unsubscribe@chromium.org.