Just a small update here as we took a couple of steps further in the prototype and learned that this proposal has a tighter connection to two features that weren't covered in the initial I2P:
- Augmenting autofill with a conditional get to provide verified identity attributes: https://github.com/w3c-fedid/FedCM/issues/694 - Auto-grant a Passkey conditional create so that it is easier to sign-in post sign-up: https://github.com/w3c-fedid/FedCM/issues/671 I'd be happy to send a separate I2P for each of these things if we feel like we should be evaluating them independently. Sam On Friday, December 20, 2024 at 3:46:02 PM UTC-8 Sam Goto wrote: > 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/ead277d9-308e-4cea-8b75-7977f8c3505en%40chromium.org.
