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.
On Monday, December 12, 2022 at 4:41:49 AM UTC-5 Yoav Weiss wrote: > On Thu, Dec 8, 2022 at 4:38 PM Nicolás Peña <[email protected]> wrote: > >> Contact emails >> >> [email protected] >> 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. > > > >> 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 [email protected]. >> 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 >> >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/1231135a-a379-4e4a-80e0-db2cd9f366abn%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 on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/bb68fb09-d508-44b1-8d5e-22ed756d014cn%40chromium.org.
