IdP Blindness: Three Party OIDC

[samuelgoto]

These are some personal, raw and unfiltered mental notes I took from a series of discussion between me, Mike Jones, @ve7jtb, @balfanz, @timcappalli and (and to a less extent with) @Sakurann at IIW this week.

I think this is related, but not entirely the same, as the notes I took here too.

Perhaps, the most constructive way to start is to provide a clear statement of the 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

I think most of us agreed that this was a valuable (albeit not necessarily new) goal.

So, if this a good (and not new) goal, why is IdP blindness still lacking in Social login?

I think there are a couple of things that were fundamentally missing: (a) the introduction of the three party verifier-holder-issuer model, specifically SD-JWT+KB and (b) the introduction of the browser as a binding to oauth.

So, the exercise that we went through at IIW was: assuming (a) and (b), what could a Issuer-Holder-Verifier OIDC (again, it wasn't clear to Mike Jones and I exactly how to frame this) look like?

Some of the discussion went towards enabling Web Wallets here, which I think is part of the answer.

The other part of the discussion went towards making the browser a holder, which I'm going to try to expand on a bit more (since third party holders is covered here).

The premise, I think, of making the browser a holder is because I think it would allow us introduce IdP blindness without requiring users being introduced to Wallets.

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 don't have a lot of context or knowledge about the history of OIDC, nor where the OIDF wants to draw the line between OIDC and OpenID4VC, so please do feel free to correct me where I might be getting wrong. I think I might be using "Social login" and OIDC interchangeably, and that might neither be right or fair.

I think it is plausible that parts of these arrows are just OpenID4VP (between the website and the browser) and OpenID4VCI (between the browser and the issuer). I think it might also be plausible to extend OIDC too. I don't think I understand what the trade-offs, but just wanted to be transparent of what the questions were. To Mike and I it seemed that two of the options was to either bring the three party model to OIDC or we take the Social-login connected-ness to OpenID4VP, unclear what was best.

It is not clear to me if we need a query language as powerful as PE or DCQL for the subset of Standard claims.

It was also not clear to me whether this is related at all with User Info VC at all or not (which partially surprised me in the last work shop that maybe it was to be abandoned?).

It is worth noting that while this addresses IdP Blindness, it creates Verifier-Verifier linkability with global identifiers, which is a problem. It is possible that this can be solved the ZKPs for mDocs, but it wasn't yet clear to us at the moment precisely how to apply them here.

This is poorly articulated and poorly explained, but wanted to kick an early discussion to get the ball rolling with unfinished thoughts while they are still fresh in my memory.

There is a question of how / whether this relates to the Digital Credentials API, but I don't think that's necessarily an important one at the moment.

[samuelgoto]

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