Ok, just one more small update, but as we moved forward with the prototype, we managed to narrow down the scope of the use case to verifying email addresses and with that we think we can decouple the mechanism from FedCM (and couple it, instead, with the HTML input element and autocomplete). Much of the privacy properties and delegation-ness remain, but through a different API frontend.
We are exploring this direction here: https://groups.google.com/a/chromium.org/g/blink-dev/c/pWfWupaOtJw I'll ping this thread again in case we learn that we should couple it back to FedCM in that thread, but until then, assume that a lot of the prototyping that was happening here has actually moved to that other thread. Sam On Wed, Mar 19, 2025 at 10:59 AM Sam Goto <g...@google.com> wrote: > 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/CALdEk-w5XCPXZJnnqgt%3DRamQ%2BUdLQ49xYZ4rDmWm38gL3TUqWw%40mail.gmail.com.
