21A/ID Token as VP (OpenID Connect 4 Verifiable Presentations)

ID Token as VP (OpenID Connect 4 Verifiable Presentations)

Thursday 21A

Convener: Kristina Yasuda, Torsten Lodderstedt

Notes-taker(s): David Waite

Tags for the session - technology discussed/ideas considered:

OpenID Connect, Verifiable Credentials, Verifiable Presentations

Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps: 

Today OIDC4VP allows presentations to be either conveyed inside an id_token or beside the id_token in a vp_token response parameter.

Question has come up whether the id_token can be a VP, e.g. contain credentials as long as they share a common proof.

Vittorio: If you conflate the id_token and presentation, you may create ramifications for existing infrastructure which expects an id_token as a trigger for authentication pieces, when you actually only want presentations and not sessions

Torsten: We will not have this as being the only option, you will still be able to have the id_token separate from the presentation

[[File:./output/media/image1.png|592x341px]]

DW: Nonce and Audience is interesting because it isn’t actually part of the VC data model, because these map to the protocol elements of presentation, and VC does not define protocols

[[File:./output/media/image2.png|624x357px]]

DW: Changing the behavior of issuer has ramifications of how id_token validation fits into a traditional SIOP stack - a.k.a. a larger delta in policy changes between OP and SIOP communications

From SIOP call:

Chadwick, not using id_token to identify the user directly, using the VC sub as identifier for user.

Mike Jones, commented that this is not OpenID Connect behavior, (subject, issuer) pair is meant to be the identifier for the End-User for the relying party

DW: Issuer _could_ be the subject, idea of resolvable identifiers is that the OP is more of a statement of common metadata across multiple SIOP implementations/installs, but changing iss breaks the OIDC protocol

Vittorio: Changes implementations, would have millions of issuers

Torsten: how would you differentiate issuers if you do not use a hard coded value

DW: OP would not have a JWKS URI if the OP metadata represents a SIOP policy

Torsten: Is this a robust enough signal

DW: Likely should have additional metadata so a mere JWKS missing or not resolving

George: Prefer explicit signals since implicit signals can come back to bite you

DW: We can have it per OP or per id_token, id_token would increase the payload

Mike: SIOP in the general case don’t have any way to host web infrastructure, not sure how to make the entity resolvable.

DW: Is it on the table to possibly new serialization other than VP-JWT that has our rules without changing claims?

Torsten: question is whether id_tokens can be consumed as presentations as-is

Impact on existing implementations pushes away from wanting to make changes to the issuer claim.

DW: One potential benefit is in having a VP that is part of a higher level abstract protocol across transports, but I don’t believe this gets us all the way there even with issuer changes

DW: Should probably reach out to the VC WG with this possibility to get broader input, also see if a potential rechartering might change the equation of whether this can be supported.