Just a friendly update: I recently got a prototype merged behind a flag in chrome canaries, so developers are welcome to give this a shot and tell us what works and what doesn't work!
More info here: https://groups.google.com/a/chromium.org/g/blink-dev/c/n02b34dFACc?e=48417069 and instructions here: https://github.com/w3c-fedid/FedCM/issues/677#issuecomment-2557689561 On Tuesday, November 12, 2024 at 8:51:01 AM UTC-8 Rick Byers wrote: > 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 <go...@chromium.org> wrote: > >> Contact emails >> >> go...@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+...@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/8a0c2b16-7bf4-4f3c-a260-1a97397a043en%40chromium.org.
