LGTM2 On Wed, Oct 12, 2022 at 9:02 AM Daniel Bratell <[email protected]> wrote:
> LGTM1 > > (I appreciate that there are some unique risks here, but I'm confident the > team will be able to navigate those) > > /Daniel > On 2022-10-11 23:13, 'Ilya Grigorik' via blink-dev wrote: > > At Shopify, we've followed progress closely, and I'm really excited to see > the i2s! > > Agree with the analysis tradeoffs and proposed rollout. This is a > capability we're keenly interested in and would be willing to stay hands-on > with as it evolves. > > On Wed, Oct 5, 2022 at 1:54 PM Sam Goto <[email protected]> wrote: > >> >> >> On Wed, Oct 5, 2022 at 1:25 AM Yoav Weiss <[email protected]> wrote: >> >>> >>> >>> On Tue, Oct 4, 2022 at 4:13 AM Rick Byers <[email protected]> wrote: >>> >>>> I've been involved somewhat with this work and so I'm recusing myself >>>> from my API owner role for this intent. >>>> >>>> Nevertheless I wanted to chime in and say that I agree with the risk >>>> tradeoff the team is proposing we make here. Yes there's still a lot to >>>> figure out in the federated identity space, and it's likely that we'll find >>>> places where we need to make some breaking changes to better meet customer >>>> needs and get to interoperability. But I believe shipping what we have now >>>> as a V0 is the most effective way to figure out the path forward in a >>>> timeframe that's compatible with Chrome's plans for 3P cookie deprecation. >>>> We've been evolving designs in public for >2 years and now we have at least >>>> one partner who is ready to scale up beyond OT limits, and we'd both learn >>>> a lot from doing so. It would be a mistake to think that we just have a few >>>> open issues to resolve before we could call the design "mature", and I >>>> don't want to risk losing momentum with customers by suggesting we should >>>> just stick to "experiments" for another 6-12 months. Instead the process of >>>> becoming mature in the context of a dynamic identity provider ecosystem and >>>> evolving privacy landscape will be best served by a "launch and iterate" >>>> approach. Doing this responsibly requires a commitment on our part to >>>> engage with the standards community in good faith to avoid past failure >>>> modes where V0 (chromium-only) and V1 (standard) APIs have co-existed in >>>> chromium for an extended period of time while Google services in particular >>>> have retained a dependency on the V0 behavior. >>>> >>>> The partnership and ecosystem dynamics here remind me a lot of what we >>>> encountered with PaymentRequest. We still don't have payment APIs "figured >>>> out", but we've been able to learn and iterate >>>> <https://docs.google.com/document/d/1RC-pBBvsazYfCNNUSkPqAVpSpNJ96U8trhNkfV0v9fk/edit#> >>>> by working with a handful of partners through the web payments working >>>> group to evolve fully launched APIs, including making significant breaking >>>> changes along the way (despite my own initial skepticism of the >>>> practicality of that). >>>> >>>> Rick >>>> >>>> >>>> On Mon, Oct 3, 2022 at 6:31 PM Sam Goto <[email protected]> wrote: >>>> >>>>> Contact emails >>>>> >>>>> [email protected] >>>>> >>>>> Explainer >>>>> >>>>> https://github.com/fedidcg/FedCM/blob/main/explainer.md >>>>> >>>>> Specification >>>>> >>>>> https://fedidcg.github.io/FedCM >>>>> >>>>> Summary >>>>> >>>>> The Federated Credential Management API (originally WebID >>>>> <https://github.com/fedidcg/FedCM/issues/41#issuecomment-712304910>) >>>>> allows users to use their federated identity to login to websites in a >>>>> manner compatible with improvements to browser privacy. This intent covers >>>>> a Web Platform API to prompt the user to choose accounts from one Identity >>>>> Provider to sign-up or sign-in to a website. We expect to send future >>>>> intents to make enhancements over these capabilities (e.g. multiple >>>>> IdPs <https://github.com/fedidcg/FedCM/issues/319>) and keep raising >>>>> the privacy properties of the API (e.g. the timing attack >>>>> <https://github.com/fedidcg/FedCM/issues/230#issuecomment-1089040953> >>>>> problem). >>>>> >>>>> >>>>> Blink component >>>>> >>>>> Blink>Identity>FedCM >>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EIdentity%3EFedCM> >>>>> >>>>> TAG review >>>>> >>>>> Early Tag Review https://github.com/w3ctag/design-reviews/issues/622 >>>>> >>>>> Spec Tag Review https://github.com/w3ctag/design-reviews/issues/718 >>>>> >>>>> TAG review status >>>>> >>>>> Positive >>>>> <https://github.com/w3ctag/design-reviews/issues/718#issuecomment-1187725216> >>>>> >>>>> Risks >>>>> Interoperability and Compatibility >>>>> >>>>> Zero compatibility risk (new API) >>>>> >>>>> Gecko: Positive >>>>> <https://github.com/mozilla/standards-positions/issues/618#issuecomment-1221964677> >>>>> >>>>> WebKit: Positive >>>>> <https://lists.webkit.org/pipermail/webkit-dev/2022-March/032162.html> >>>>> >>>>> On interoperability and forward compatibility: FedCM is large and >>>>> complex and, as browser vendors start to implement it (example >>>>> <https://bugzilla.mozilla.org/show_bug.cgi?id=1782066>), we are >>>>> seeing positive and constructive engagement. For example, we are actively >>>>> working with Mozilla to find an interoperable way to address the >>>>> timing attack problem >>>>> <https://github.com/fedidcg/FedCM/issues/230#issuecomment-1089040953>, >>>>> support multiple IdPs <https://github.com/fedidcg/FedCM/issues/319> >>>>> and protect endpoints <https://github.com/fedidcg/FedCM/issues/320>. >>>>> Because of that, there is a risk of incompatible changes going forward >>>>> (list of currently known potential risks here >>>>> <https://github.com/fedidcg/FedCM/labels/compatibility%20risk>), >>>>> mostly affecting IdPs (see section below on activation). We think it is >>>>> unavoidable that parts of our current design are suboptimal and are going >>>>> to need to be revisited, but the biggest risk we are trying to avoid is to >>>>> fail to bring IdPs along with us, increase their production footprint that >>>>> we can learn from, and increase our confidence on technical feasibility >>>>> and >>>>> product-market fit. >>>>> >>>>> Based on our origin trials, we expect a small number of IdPs (say, >>>>> less than ~30) to be incentivized to use the API in production until >>>>> chrome phases-out third party cookies in 2024 >>>>> <https://privacysandbox.com/intl/en_us/open-web/#the-privacy-sandbox-timeline>. >>>>> These IdPs that we are partnering with need time, confidence, and >>>>> stability >>>>> to increase their deployment. For example, in origin trials, we ran into >>>>> CSP >>>>> issues <https://bugs.chromium.org/p/chromium/issues/detail?id=1320724> >>>>> and cross-origin iframe issues >>>>> <https://bugs.chromium.org/p/chromium/issues/detail?id=1322320> that >>>>> we could have never anticipated without IdPs experimentation, even if we >>>>> had interoperable implementations in all major browsers. We think that the >>>>> risk we take by not having a baseline that IdPs can work from if the API >>>>> isn’t shipped outweighs the forward compatibility risks: not shipping >>>>> would >>>>> mean that we won’t learn about these bugs until it is too close to the >>>>> deprecation of third party cookie (e.g. IdPs will continue to evolve their >>>>> products using iframes and third party cookies without an alternative to >>>>> build on). We also think that we can address some concerns on forward >>>>> compatibility by setting the right expectations during developer >>>>> documentation / outreach to IdPs as we make it battle-tested before we >>>>> deprecate third party cookies in 2024 >>>>> <https://privacysandbox.com/intl/en_us/open-web/#the-privacy-sandbox-timeline> >>>>> . >>>>> >>>>> Web developers: We’ve been working with Identity Providers and >>>>> Relying Parties over the last ~3 years, going over a good amount of design >>>>> alternatives and prototypes (TPAC 2020 >>>>> <https://github.com/fedidcg/FedCM/blob/main/meetings/2020/The%20Web%20Platform%2C%20Privacy%20and%20Federation%20-%20TPAC.pdf>, >>>>> 2021 >>>>> <https://github.com/fedidcg/FedCM/blob/main/meetings/2021/FedCM%20%40%20TPAC%202021%20(1).pdf> >>>>> and 2022 >>>>> <https://github.com/fedidcg/FedCM/blob/main/meetings/2022/FedCM%20%40%20TPAC.pdf>, >>>>> BlinkOn 14 >>>>> <https://github.com/fedidcg/FedCM/blob/main/meetings/2021/WebID%20-%20BlinkOn%2014.pdf>, >>>>> 15 >>>>> <https://github.com/fedidcg/FedCM/blob/main/meetings/2021/BlinkOn%2015%20--%20FedCM.pdf>, >>>>> 16 >>>>> <https://github.com/fedidcg/FedCM/blob/main/meetings/2022/FedCM%20BlinkOn%2016.pdf>, >>>>> OIDF 2020 >>>>> <https://github.com/fedidcg/FedCM/blob/main/meetings/2020/Browsers%20and%20Federation%20-%20OpenID.pdf>, >>>>> IIW 2020 >>>>> <https://github.com/fedidcg/FedCM/blob/main/meetings/2020/The%20Web%20Platform%2C%20Privacy%20and%20Federation%20-%20IIW.pdf>), >>>>> trying to strike the right balance between privacy/security properties and >>>>> deployment structures (e.g. backwards compatibility). The current >>>>> formulation is the result of identity providers, relying parties, browser >>>>> vendors and industry experts that have co-designed with us through our >>>>> devtrials and gathered production experience with their users through our >>>>> origin trials (around ~33 small and big registered IdPs). For example, in >>>>> the last two quarters, the Google Sign-in team has run experiments with >>>>> ~20 >>>>> Relying Parties leading to more than ~300K real users logging-in in >>>>> production, achieving comparable sign-in/up conversion rates without >>>>> depending on third party cookies. While this is a small sample size of the >>>>> ecosystem and the deployment (notably missing representation of >>>>> enterprises >>>>> and EDU), we are encouraged by the approach and confident this is a solid >>>>> and necessary first step. >>>>> >>>>> Other signals: This API is being developed within the FedID CG >>>>> <https://github.com/fedidcg> composed of identity providers, relying >>>>> parties, browser vendors and industry experts. The CG has produced an >>>>> enumeration of known issues >>>>> <https://github.com/fedidcg/use-case-library/wiki/Primitives-by-Use-Case> >>>>> in the absence of third party cookies, a list of mitigation >>>>> alternatives >>>>> <https://github.com/fedidcg/use-case-library/wiki/Third-party-cookie-mitigations> >>>>> and is actively working on how to decide >>>>> <https://github.com/fedidcg/use-case-library/wiki/User-Flow-Decision-Trees> >>>>> which Web Platform API to use for each circumstance. We don’t expect (or >>>>> are designing for) FedCM to be used exclusively to solve all of the known >>>>> issues, but rather in coordination with other browser proposals (e.g. >>>>> CHIPS). We acknowledge that there is a series of anticipated breakages >>>>> that >>>>> are not handled (effectively) by any proposal (FedCM included) at the >>>>> moment, and we are excited to continue working with the FedID CG, the >>>>> Privacy CG <https://www.w3.org/groups/cg/privacycg> and the Privacy >>>>> Sandbox <https://privacysandbox.com/> to extend FedCM in whichever >>>>> way is constructive and/or work on new proposals. >>>>> >>>>> Activation >>>>> >>>>> Our design assumes that it is exponentially harder, in this order, to >>>>> make changes to (a) user behavior than, (b) websites, (c) identity >>>>> providers and then, lastly, (d) browsers. >>>>> >>>> >>> I agree with this ordering. >>> It'd be good to be transparent with adopting identity providers about >>> the potential compat risk, so that they'd know what they are signing up for. >>> >>> On top of that, there's some risk of the *compat issues leaking* from >>> identity providers to websites, if those websites self-host the IDP SDKs >>> (for performance or other reasons). >>> Would it be possible to ask identity providers to take measures against >>> self-hosting? e.g. I think `document.currentScript.src` can help them >>> enforce the script coming from an updatable source. >>> >> >> >> I really like the `document.currentScript.src` suggestion, and I think >> that’s a great way to help us control future breakages! >> >> As you suggested, there is a lot that we can do by working with the >> Developer Relations (devrel) and Business Development (BD) teams to set up >> the right expectations as this goes out. Here are a few examples that we >> think could work: >> >> >> - >> >> Set up a communication channel (e.g. a mailing list similar to the >> one we have for Core Web Vitals here >> <https://groups.google.com/a/chromium.org/g/speed-metrics-announce> >> and here >> <https://mobile.twitter.com/NicPenaM/status/1427712030455259142>) >> that IdPs can subscribe to coordinate with us (in addition to direct 1:1 >> partnerships) >> - >> >> Be transparent about the moving parts (e.g. the timing attack problem >> <https://github.com/fedidcg/FedCM/issues/230#issuecomment-1089040953>, >> the multi-IdPs <https://github.com/fedidcg/FedCM/issues/319> API, >> etc), and a rough timeline to resolve them (e.g. we could use the Privacy >> Sandbox Timeline >> >> <https://privacysandbox.com/intl/en_us/open-web/#the-privacy-sandbox-timeline> >> and have meaningful stability checkpoints at General Availability in >> 2023 >> >> <https://privacysandbox.com/intl/en_us/open-web/#the-privacy-sandbox-timeline> >> and Phase-out in 2024 >> >> <https://privacysandbox.com/intl/en_us/open-web/#the-privacy-sandbox-timeline> >> ). >> - >> >> Make a recommendation to IdPs to control their SDKs (e.g. either >> through document.currentScript.src or SLAs), at least until some moving >> parts settle, so that we can iterate quickly as an industry. It is >> ultimately a business decision that IdPs make, so we can only go as far as >> making a recommendation. >> >> >> Just a few more data points: >> >> >> - >> >> We expect it is going to take us more than a quarter but less than a >> year to resolve the known moving parts with confidence. Also, importantly, >> they may or may not require backwards incompatible API changes. >> - >> >> To give you a sense of numbers, in origin trials, ~33 IdPs registered >> over the last ~7 months. There are few IdPs (that have the incentives to >> use the API at the moment, while 3P cookies are still around) and they are >> large and sophisticated developers >> - >> >> In our experience so far, very few websites choose to self-host (in >> origin trials, we found only 1), and the ones that do, are extremely large >> and sophisticated developers that can afford to self-host (i.e. we would >> know how to reach out to them individually) >> - >> >> Outside of real-world production IdP deployment, it is possible, >> though, that we are going to find developers playing with the API, writing >> blogs or demos, and that’s more likely to break (because we wouldn’t be >> able to reach out to them individually), but that’s a more acceptable >> breakage. >> >> >> >>> >>> >>>>> So, the design pulls as much as possible the burden of change to >>>>> browsers vendors and identity providers, and goes to a great extent to >>>>> require little to no changes to websites and user's norms, while at the >>>>> same time, raising the privacy properties of the system. >>>>> >>>>> While that’s not always possible, we believe we found an activation >>>>> structure that could work at scale for a substantial part of the >>>>> deployment >>>>> (especially for consumers) through JS SDKs that are provided by Identity >>>>> Providers and get dynamically embedded into relying parties. >>>>> >>>>> For example, through their JS SDKs, the Google Sign-in team was able >>>>> to replace their dependence on third party cookies with FedCM without >>>>> requiring changes to relying parties. >>>>> >>>>> We acknowledge that this activation model is insufficient for a lot of >>>>> the deployment (especially for enterprises), so finding alternative >>>>> activation structures is an active area of investigation. >>>>> >>>>> 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? >>>>> >>>>> This API does not deprecate or change behavior of existing APIs. >>>>> >>>>> >>>>> Debuggability >>>>> >>>>> Basic devtools integration supported. We plan to extend this support >>>>> as the product matures and we learn from developers what challenges they >>>>> run into. >>>>> >>>>> 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, fedcm-* tests in this directory >>>>> <https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/external/wpt/credential-management/> >>>>> . >>>>> >>>>> Known issue: some of our WPT tests are failing >>>>> <https://wpt.fyi/results/credential-management?label=experimental&label=master&aligned&view=subtest> >>>>> on wpt.fyi. While the tests exist and pass in Chromium’s infrastructure, >>>>> they rely on a Chrome-specific flag that would not work in other browsers. >>>>> Making them work on upstream WPT requires PAC support; however, WPT’s PAC >>>>> support does not currently support HTTPS tests, which FedCM requires >>>>> because it is only exposed to secure contexts. We are working on adding >>>>> that support, which is in progress here >>>>> <https://github.com/web-platform-tests/wpt/pull/35276>. >>>>> >>>>> Origin Trial Instructions >>>>> >>>>> https://developer.chrome.com/blog/fedcm-origin-trial/ >>>>> >>>>> Flag name >>>>> >>>>> fedcm >>>>> >>>>> Requires code in //chrome? >>>>> >>>>> True >>>>> >>>>> Tracking bug >>>>> >>>>> https://bugs.chromium.org/p/chromium/issues/detail?id=1353814 >>>>> >>>>> Launch bug >>>>> >>>>> https://bugs.chromium.org/p/chromium/issues/detail?id=1321238 >>>>> >>>>> Measurement >>>>> >>>>> kFederatedCredentialManagement >>>>> >>>>> Estimated milestones >>>>> >>>>> OriginTrial desktop last >>>>> >>>>> 107 >>>>> >>>>> OriginTrial desktop first >>>>> >>>>> 103 >>>>> >>>>> OriginTrial Android last >>>>> >>>>> 107 >>>>> >>>>> OriginTrial Android first >>>>> >>>>> 101 >>>>> >>>>> DevTrial on Android >>>>> >>>>> 98 >>>>> >>>>> >>>>> Anticipated spec changes >>>>> >>>>> We’re also currently resolving some questions >>>>> <https://github.com/fedidcg/FedCM/issues/320> related to Fetch >>>>> integration. >>>>> >>>>> Link to entry on the Chrome Platform Status >>>>> >>>>> https://chromestatus.com/feature/6438627087220736 >>>>> >>>>> Links to previous Intent discussions >>>>> >>>>> - >>>>> >>>>> Intent to Prototype >>>>> >>>>> <https://groups.google.com/a/chromium.org/g/blink-dev/c/2B4TJ7j2U4M/m/1X5T3OszCAAJ> >>>>> >>>>> - >>>>> >>>>> Ready for Trial >>>>> <https://groups.google.com/a/chromium.org/g/blink-dev/c/jlV_1m7uUAg> >>>>> - >>>>> >>>>> Intent to Experiment >>>>> <https://groups.google.com/a/chromium.org/g/blink-dev/c/kws-gltC5us> >>>>> - >>>>> >>>>> Intent to Extend Experiment >>>>> <https://groups.google.com/a/chromium.org/g/blink-dev/c/Juc7ix6UI24> >>>>> >>>>> >>>>> 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/CALdEk-yf1BMQ4ZtMYH9cCQsecroEE3ZPOKgY8LU%3DNX3zAfbwYA%40mail.gmail.com >>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALdEk-yf1BMQ4ZtMYH9cCQsecroEE3ZPOKgY8LU%3DNX3zAfbwYA%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/CAFUtAY92OzzAAJkqpe11G9rW_7SNVo_qTYsu5OLd2mKZ%3DS3EOg%40mail.gmail.com >>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY92OzzAAJkqpe11G9rW_7SNVo_qTYsu5OLd2mKZ%3DS3EOg%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/CALdEk-wJNZAN_dBpfe60b9_iOseVPXypo%3DAvWwpD60W3coiXyg%40mail.gmail.com >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALdEk-wJNZAN_dBpfe60b9_iOseVPXypo%3DAvWwpD60W3coiXyg%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/CABd3A800vm_-kX0inH4170iK1gs%3DT0w4da2P4kRe%2BYioTy5iTw%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABd3A800vm_-kX0inH4170iK1gs%3DT0w4da2P4kRe%2BYioTy5iTw%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/e4142e39-98ff-dc8d-43ee-56efc24ce3b1%40gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/e4142e39-98ff-dc8d-43ee-56efc24ce3b1%40gmail.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/CAOMQ%2Bw8A%2B2g4e%3D4Q5Y%3DWOUwuEGAQ8JHg48zyuyU6Ah38sm-eOA%40mail.gmail.com.
