Contact emails g...@chromium.org
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. 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 blink-dev+unsubscr...@chromium.org. 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.
