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.
