Thanks for the high-level framing Sam putting this in perspective. I'm excited about this as an additional possible tool in the identity toolbox.
Of course it's ultimately user preference and other market forces well outside our control that will determine which technologies and tradeoffs get used where. At some point before we get too far we should perhaps make a serious attempt to catalog the tradeoffs of the different technologies (passkeys, FedCM, Digital Credentials, SAA, etc.) and make sure we're actually covering the tradeoff space well without needless overlap. Rick On Mon, Nov 11, 2024 at 6:09 PM Sam Goto <g...@chromium.org> wrote: > 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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALdEk-wc%2BSPtWpUy9xrrsZ_Z8x9pJaZZSXeDE4YqygPQOCRVyA%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 blink-dev+unsubscr...@chromium.org. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY844x9r9e1kU-0e12cLAz3%3DXTk9G%3Dtcrd29k0026hvkNw%40mail.gmail.com.
