Contact emails

n...@chromium.org
Explainer

https://github.com/fedidcg/FedCM/blob/main/explorations/iframe_support.md 
Specification

https://fedidcg.github.io/FedCM/#permissions-policy-integration
Summary

Adds support for calling the FedCM API inside cross-origin iframes via a 
permissions policy which sites are opted out of by default. It enables 
websites to sandbox the scripts from identity providers which trigger the 
FedCM API in an iframe. We also considered whether this feature could 
support "authenticated embeds" use cases where the iframe itself needs a 
sign-in from the user. While the UI currently does not support this 
scenario, we invite requirements and feedback from interested parties. In 
both cases, the parent frame must provide the cross-origin iframe with the 
permissions policy 'identity-credentials-get'. This also allows top-level 
contexts to opt out of using FedCM through the Permissions Policy header.
Blink component

Blink>Identity>FedCM 
<https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EIdentity%3EFedCM>
TAG review

This is a small addition to FedCM API that uses an existing mechanism to 
give cross-origin iframe control (permissions policy), so we do not 
consider this change to be substantive enough to warrant a separate review. 
Previous reviews: https://github.com/w3ctag/design-reviews/issues/622 
https://github.com/w3ctag/design-reviews/issues/718 
TAG review status

Not applicable
Risks

Interoperability and Compatibility

This is a small addition to the FedCM API, and as such mostly inherits the 
interop and compatibility risks from that API. See 
https://groups.google.com/a/chromium.org/g/blink-dev/c/URpYPPH-YQ4/m/E9pgS7GEBAAJ
 
for the discussion.

Gecko: Positive for the API in general (
https://github.com/mozilla/standards-positions/issues/618), positive for 
cross-origin iframe support specifically (
https://github.com/mozilla/standards-positions/issues/701)

WebKit: Positive for the API in general (
https://lists.webkit.org/pipermail/webkit-dev/2022-March/032162.html), 
requested signal on cross-origin iframe support specifically (
https://github.com/WebKit/standards-positions/issues/83) 

Web developers: Positive (we know several sites that use cross-origin 
iframes for authentication of users via federation)

Other signals: -
Ergonomics

The main ergonomics risk is that the website must explicitly add the 
permissions policy for the iframe where the identity provider invokes 
FedCM, which breaks the FedCM benefit of deploying with no RP change.

Another issue is having a page where both the main frame and some iframes 
decide to invoke the FedCM API. Because we produce a very user visible 
dialog, we've decided that multiple calls within the same page are not 
allowed, i.e. https://bugs.chromium.org/p/chromium/issues/detail?id=1374422. 
In practice, this means that if there were multiple frames interested in 
using FedCM within the same page, then the RP needs to ensure that those 
frames collaborate so that they do not try to invoke themselves at the same 
time, as otherwise only one of them will be successful in showing the FedCM 
dialog.
Activation

Similar to the baseline FedCM API that this I2S is extending from, the bulk 
of the work is on the identity provider to ensure that they call the FedCM 
API appropriately. The added work for the RP in the iframe case is the 
requirement of a permissions policy, but this is needed because the FedCM 
API is very powerful and it's not reasonable to automatically grant 
arbitrary cross-origin iframes with the power to invoke it.
Security

User annoyance from the dialog is dealt with by the requirement of 
permissions policy. The top-level frame needs to explicitly allow any 
cross-origin iframe to invoke the FedCM API. The other security 
consideration here is the accountability for the dialog: what domain do we 
show as the requestor for the FedCM dialog: the top-level or the 
cross-origin iframe? The current status is that we always show the 
top-level domain. We considered showing the cross-origin iframe domain in 
addition to the top-level, but we are not currently planning to ship it due 
to lack of concrete demand for it. Note that this is consistent with other 
powerful APIs such as camera and GPS access.
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 as this feature is not available on WebView.
Debuggability

Besides regular FedCM support, we show a clear error message stating when 
the API has failed due to missing permissions policy.
Will this feature be supported on all six Blink platforms (Windows, Mac, 
Linux, Chrome OS, Android, and Android WebView)?

No

The current implementation is available on all platforms (Windows, Mac, 
Linux, ChromeOS and Android) except 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/credential-management/fedcm-iframe.https.html?label=master&label=experimental&aligned
 
(we’re still working on making tests behave as intended on WPT.fyi)
Flag name

This can be enabled by going to chrome://flags, and setting the FedCM 
feature to “FedCM (Enabled - with iframe support)”
Requires code in //chrome?

True
Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1322320
Launch bug

https://launch.corp.google.com/launch/4209514
Sample links

https://fedcm-main-frame.glitch.me
Estimated milestones

Ship 110
Anticipated spec changes

The main spec change <https://github.com/fedidcg/FedCM/issues/320> that we 
anticipated on the initial FedCM I2S has a good path towards being resolved.
Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5162418615877632

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 on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/1231135a-a379-4e4a-80e0-db2cd9f366abn%40chromium.org.

Reply via email to