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.
On Tue, Dec 13, 2022 at 9:31 AM Mike Taylor <[email protected]> wrote: > LGTM2 > > On 12/12/22 11:03 PM, Yoav Weiss wrote: > > LGTM1 > > On Mon, Dec 12, 2022 at 8:14 PM Nicolás Peña <[email protected]> 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! :) > > >> >> 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/CAL5BFfWuVf-woOCPEOa9t%2Bx7k29YKix456JKkt6n%3Dm2mm2dxeQ%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfWuVf-woOCPEOa9t%2Bx7k29YKix456JKkt6n%3Dm2mm2dxeQ%40mail.gmail.com?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/68eb3591-b9c1-5634-2002-6396558d5a0d%40chromium.org > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/68eb3591-b9c1-5634-2002-6396558d5a0d%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/CAFUtAY8LL74GdAAakGRmHxpQ9j5W8w1L5Ter7%3DeJmfE4rdz%2Bqw%40mail.gmail.com.
