LGTM3 On Tue, Dec 13, 2022 at 6: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/CAOMQ%2Bw_bmVnzFmSRBXHJDQyp-PARBfp1qyUAfMkMowp8PfVyYA%40mail.gmail.com.
