IdP Blindness: User Info VCs

[samuelgoto]

These are some personal, raw and unfiltered mental notes I took from a series of discussion over the years.

One problem that we identified early on that we still don't know how to solve is the IdP Tracking Problem: wouldn't it be great if we could login to websites without necessarily telling the Social login provider that we did?

NOTE: I've been told numerous times that this is clearly not the case for R&E or enterprises, where this is a feature, not a bug, so trying to make it clear that I'm talking about Social login for consumers, rather than universities or enterprises

Since we started developing FedCM, I think a lot has changed. For one, we got a lot more experience with zero knowledge proofs. For two, the three-party model got more mature too, with credential formats like SD-JWTs and ISO MDocs being deployed in systems like government-issued IDs. Importantly, we also developed a much stronger foundation with FedCM that we can stand on (e.g. we know how to construct a privacy preserving account chooser, log-in users that are logged-out, etc), making this problem a lot more tractable now than it was a few years ago.

I'm interested in ZKP formats most, but since MDocs and SD-JWTs might be bit easier to start from. I think zero-knowledge proof formats, such as BBS+, can increase the privacy properties here, and be supported in a similar architecture.

It is not yet clear to me what kinds of trade-offs this architecture will have, but I have an intuition that it will offer a very different set of properties compared to other alternatives. For example, this is clearly backwards incompatible with the existing server-side deployment, so will activate the ecosystem much more slowly than vanilla FedCM. But, on the other hand, I think that this is likely the most private cross-site identity system that we can build, because it involves the fewest entities possible, so will find its use in enough places.

[samuelgoto]

Just a small update here: we intend to prototype this and see where it might take us.

[samuelgoto]

Just a small update here: we intend to prototype this and see where it might take us.

Another update here: I just finished merging a prototype behind a flag in chrome canaries (here are the CLs if you want to reverse engineer) and kicked off a devtrial.

Here are some instructions on how you can give this a try in Chrome:

1. Download and open chrome canaries https://www.google.com/chrome/canary/
2. Enable necessary development flags
   • Type chrome://flags in the url bar and enable the following flags
   • #enable-experimental-web-platform-features (needed to verify ed25519 signatures, already shipping)
   • #fedcm-button-mode (needed for modal ui, already shipping)
   • #fedcm-authz (needed for continuation, already shipping)
   • #fedcm-without-well-known-enforcement
   • #fedcm-idp-registration (in devtrials)
   • #fedcm-multi-idp (in origin trials)
   • #fedcm-delegation (in devtrials)
3. Use the test verifier
   • Open https://code.sgo.to/2024/10/25/sd-jwt+kb.html
   • Choose my own test SD-JWT issuer (https://issuer.sgo.to/fedcm.json)
   • Click "Sign-up" and follow the prompts
4. The verifier should get an SD-JWT+KB presented by the browser, without the issuer learning who the verifier is.
5. You should be able to write your own issuer and verifier and make things interoperate. You can start from my simple:
   • SD-JWT+KB verifier here view-source:https://code.sgo.to/2024/10/25/sd-jwt+kb.html) and
   • SD-JWT static issuer here https://github.com/samuelgoto/static-issuer.
6. This fits surprisingly well with lighweight mode, multi-idp, idp-registration and the continuation APIs.
7. There is no step 7

You should get something like the following without telling the issuer who the verifier is:

Screen.Recording.2024-12-20.at.13.57.23.mov

[samuelgoto]

I moved this explainer to this dedicated repo.

[wseltzer]

Discussed at Jan 21, 2025 meeting minutes. Agreed to move delegation-oriented to Stage 1, with a new delegation-oriented repository.

[samuelgoto]

thanks @wseltzer !!! I'm going to close this issue here and move the contents to the README.md file! Thanks!