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/CAL5BFfVZN%2BCwdJ8e71_U0XMhpm5XpeC%3DR7fHotQtC_QMLWToog%40mail.gmail.com.
