Contact emails g...@google.com
Explainer https://github.com/w3c-fedid/FedCM/issues/677 Specification Not yet available. Summary Early on <https://github.com/w3c-fedid/FedCM/blob/main/meetings/2020/The%20Web%20Platform%2C%20Privacy%20and%20Federation%20-%20TPAC.pdf>, we outlined a few important problems we wanted to address in federation: first and foremost The Classification Problem <https://github.com/samuelgoto/WebID?tab=readme-ov-file#the-classification-problem> (the fact that browsers couldn’t tell the difference between federation and tracking), and then The RP Tracking Problem <https://github.com/w3c-fedid/FedCM/blob/main/explorations/proposal.md#the-end-state> (the release of global identifiers, such as emails) and The IdP Tracking problem <https://github.com/w3c-fedid/FedCM/blob/main/explorations/proposal.md#the-end-state> (the bundling of presentation with issuance). It wasn’t clear where we should start, so we looked at three different variations that had different trade-offs. We called them the Mediation-oriented <https://github.com/w3c-fedid/FedCM/blob/main/explorations/proposal.md#the-mediated-oriented-api> model, the Permission-oriented <https://github.com/w3c-fedid/FedCM/blob/main/explorations/proposal.md#the-permission-oriented-api> model and the Delegation-oriented <https://github.com/w3c-fedid/FedCM/blob/main/explorations/proposal.md#the-delegation-oriented-api> model. We learned quickly that it was key to start from the first two variations, because they were the most backwards compatible. So, the Mediation-oriented <https://github.com/w3c-fedid/FedCM/blob/main/explorations/proposal.md#the-mediated-oriented-api> model and the Permission-oriented <https://github.com/w3c-fedid/FedCM/blob/main/explorations/proposal.md#the-permission-oriented-api> model materialized - after many iterations - as FedCM’s mediated account chooser and the Storage Access API (by itself, or even in conjunction with <https://github.com/explainers-by-googlers/storage-access-for-fedcm> FedCM). A series of heuristics <https://github.com/amaliev/3pcd-exemption-heuristics/blob/main/explainer.md> were also put in place, which covers a lot of ground too, again optimizing for backwards compatibility with the Web. The Mediation-oriented API <https://github.com/w3c-fedid/FedCM/blob/main/explorations/proposal.md#the-mediated-oriented-api>, notably, was a great starting point because it (a) solved The Classification Problem <https://github.com/samuelgoto/WebID?tab=readme-ov-file#the-classification-problem>, (b) allowed solving the The RP Tracking Problem <https://github.com/w3c-fedid/FedCM/blob/main/explorations/proposal.md#the-end-state> (with directed identifiers) and, importantly, (c) didn’t require any user experience or behavioral change (as opposed to the Permission-oriented <https://github.com/w3c-fedid/FedCM/blob/main/explorations/proposal.md#the-permission-oriented-api> variation), allowing it to be deployed at large scales. So, while the first two variations optimized for backwards compatibility (and, between them, a trade-off between performance, extensibility and ergonomics), they had an inherent privacy design weakness: The IdP Tracking problem <https://github.com/w3c-fedid/FedCM/blob/main/explorations/proposal.md#the-end-state> . That brings us to the Delegation-oriented <https://github.com/w3c-fedid/FedCM/blob/main/explorations/proposal.md#the-delegation-oriented-api> model, which has great privacy properties in keeping IdPs blind, but requires us to redeploy a much larger part of the ecosystem: tens of thousands of relying parties. We are not sure yet whether the delegation-oriented model is actually within reach at this point, but a few stars aligned recently. For one, the introduction of the issuer-holder-verifier <https://www.w3.org/TR/vc-data-model-2.0/#ecosystem-overview> architecture, together with the deployment of new token types like SD-JWT+KB <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-selective-disclosure-jwt>, made the unbundling of issuance from presentation a lot more accessible. Zero knowledge proofs have also advanced much since we started, giving us some hope that we could solve both the RP Tracking Problem and the IdP Tracking Problem at the same time. Asides from the new externalities introduced, the development of the Mediation-oriented variation allowed us to stand on top of a much higher foundation compared to where we started from. The last 2-3 years of production experience of FedCM across thousands of websites and millions of users required us to design a series of features and extensions (e.g. handling logged-out users <https://github.com/w3c-fedid/active-mode>, switching accounts <https://github.com/w3c-fedid/active-mode>, extensibility <https://github.com/w3c-fedid/custom-requests>, handling multiple idps at a time <https://github.com/w3c-fedid/multi-idp>, a registration mechanism <https://github.com/w3c-fedid/idp-registration>, the pull and push model <https://github.com/fedidcg/LightweightFedCM>, and a <https://github.com/w3c-fedid/FedCM/issues/553> series <https://github.com/w3c-fedid/FedCM/issues/552> of <https://github.com/w3c-fedid/FedCM/pull/498> control <https://github.com/w3c-fedid/FedCM/pull/523> knobs <https://github.com/w3c-fedid/FedCM/issues/352>) that we can build the delegation-oriented variation from. This is still early and ambiguous, so it is very possible it won’t go anywhere. Nonetheless, it is probably the closest that we have ever been, and close enough that it feels worth taking a shot. The explainer linked above <https://github.com/w3c-fedid/FedCM/issues/677> has some notes of the overall idea that we’d like to start from. Blink component Blink>Identity>FedCM <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EIdentity%3EFedCM> Motivation https://github.com/w3c-fedid/FedCM/issues/677 Initial public proposal https://github.com/w3c-fedid/FedCM/issues/677 TAG review None TAG review status Pending Risks Interoperability and Compatibility None Gecko: No signal yet. It shows up, however, as one of the desired areas of exploration in the original standards position <https://github.com/mozilla/standards-positions/issues/618#issuecomment-1221964677>. “We ultimately want to be able to offer options where IdPs are not in a position to track users through their use of identity information. The current design always involves notifying the IdP of all login attempts. This has a number of advantages from a security perspective. The IdP is able to audit logins and present users with information about their activities. Also, the IdP is in a better position to block access to identity information for bad RPs. Ultimately, we would like to be able to offer users at least the option of a more private choice here, but we recognize the practical security benefits of the current design.” WebKit: No signal. We also heard informally at TPAC over the years from Safari engineers that they were hoping we’d explore this variation further too. Web developers: No signals. We started gathering some early and informal guidance from the designers of protocols like OIDC and SAML here <https://github.com/w3c-fedid/FedCM/issues/677>, but need to do a much deeper dive into the specifics. We think a few IdPs may choose to use this (non mutually exclusive) variation on their own (it is likely easier to operate and raises the privacy bar), but that’s yet to be seen. Other signals: WebView application risks FedCM isn’t supported in WebViews. We don’t expect this specific variation to change that. Debuggability None Is this feature fully tested by web-platform-tests <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> ? No Flag name on about://flags None Finch feature name None Non-finch justification None Requires code in //chrome? True Estimated milestones No milestones specified Link to entry on the Chrome Platform Status https://chromestatus.com/feature/5151763420938240 <https://chromestatus.com/feature/5151763420938240?gate=5181356416696320> 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 visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALdEk-wc%2BSPtWpUy9xrrsZ_Z8x9pJaZZSXeDE4YqygPQOCRVyA%40mail.gmail.com.
