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.
