Intent to Ship: FedCM on cross-origin iframes

[Nicolás Peña]

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

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?

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

[Yoav Weiss]

On Thu, Dec 8, 2022 at 4:38 PM Nicolás Peña <n...@chromium.org> wrote:

Contact emails

n...@chromium.org

Explainer

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

Would be great to have some more explicit examples in the explainer. For example, it's not immediately obvious to me if this would support both HTTP header based delegation as well as the "allow" attribute on the iframe itself. Would it? Such support can have implications on the ergonomics story here.

  

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

[Nicolás Peña]

I was not aware that Permissions-Policy enables having support for just JS or just HTTP header support, but in our case we want to ship both, which is the default. I have added a couple of examples at the bottom of that explainer. 

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Yoav Weiss]

LGTM1

On Mon, Dec 12, 2022 at 8:14 PM Nicolás Peña <n...@chromium.org> wrote:

I was not aware that Permissions-Policy enables having support for just JS or just HTTP header support, but in our case we want to ship both, which is the default. I have added a couple of examples at the bottom of that explainer. 

Thanks for adding those examples! :)

 

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Mike Taylor]

LGTM2

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfWuVf-woOCPEOa9t%2Bx7k29YKix456JKkt6n%3Dm2mm2dxeQ%40mail.gmail.com.

[Rick Byers]

I'm recusing myself from FedCM again, since I'm working in this space. But FWIW I think this should be a pretty uncontroversial extension, consistent with other power capabilities which we enable to be delegated down to iframes (since conspiring script could generally polyfill such things with postmessage if we didn't). So I'm supportive. 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/68eb3591-b9c1-5634-2002-6396558d5a0d%40chromium.org.

[Chris Harrelson]

LGTM3

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/68eb3591-b9c1-5634-2002-6396558d5a0d%40chromium.org.