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.

There are many non mutually-exclusive ways that we can try to tackle this problem (e.g. with third party wallets and the Digital Credentials API), and one scheme that I think that FedCM is in a unique position to offer is to turn the browser into a holder. I think that might give us a whole different set of trade-offs, specifically on privacy (e.g. having fewer parties involved) and the activation energy required (e.g. not requiring explaining wallets to users) at some costs (e.g. ossification).

I'm interested in ZKP formats most, but since MDocs and SD-JWTs are a bit easier to start from, architecturally, here is more or less what I had in mind:

sequenceDiagram
    participant website
    participant browser
    participant issuer
    website->>browser: Give me a signed "sub" and "name", given "nonce"
    browser<<->>issuer: Vanilla FedCM, creates an account chooser
    browser->>browser: User selects account, choosing to Sign-in
    browser->>browser: Generate ephemeral key pair
    browser->>issuer: Issue me an SD-JWT bound to public key
    issuer->>browser: Here
    browser->>browser: Selectively disclose "sub" and "name"
    browser->>browser: Bind "aud" and "nonce" with private key
    browser->>browser: Throw away private key
    browser->>website: Here is a SD-JWT-KB
    website->>website: Checks issuer's signature
    website->>website: Checks "aud" and "nonce"
    website->>website: Accepts "sub" and "name"

Loading

I think zero-knowledge proof formats, such as BBS+, can increase the privacy properties here, and be supported in a similar architecture as the one described above.

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