3E/ VC Issuance using OpenID Connect
VC Issuance using OIDC
Convener: Kristina Yasuda, Oliver Terbu, Tobias Looker, Torsten Lodderstedt
Notes-taker(s): Andrew Hughes (1st half), David Schmudde (2nd half)
Tags for the session - technology discussed/ideas considered:
VC, OpenID Connect, Credential Provider, Claims Aggregation
Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:
The session was recorded
Torsten gives overview
At OIDF work is going on for a protocol suite for SSI
Also Credential Issuance topic - that’s why this session
To find out how implementers are using OIDC for Issuance
Seeking to get to a 1st draft of OIDC for Issuance, starting with inputs like this session
Kristina gives more background
Claims aggregation and credential provider are being merged in OIDF as a starting point
“Credential” in this session should be viewed in the Verifiable Credential sense, not the OIDC sense
Requirements for the spec
Issuance needs binding of a credential to a Holder/person
Also new mechanism for requesting specific types of credential
(need a “Proof of Possession” aspect for the assertion - how to introduce a cryptographically bound credential to OIDC)
Credential Provider uses Signed Request Object for POP today
(the Holder needs to prove control over key material)
SRO should work - but the way OIDC uses SRO today, SRO signs with the CLIENT key, not the person’s key
NEW: add additional parts to the protocol flow to show control of holder key
What are others doing?
FIDO - Issuser sends a challenge to the wallet. Wallet responds utilizing the private key.
JSON messages (WebAuthn)
Can also provide key metadata (attestation, location, etc)
Who is the Client in an SSI configuration? Isn't the Client the User?
Don’t assume that the User is the Client - in certain cases there are legal requirements for issuance - and the Issuer might have to have assurance of the person, not only the software assurance
NOTE: In Issuance, the Client and device are the RP - and the Issuer is a normal OP. (Not the same capabilities as in the SIOP presentation flows)
In the issuance flow, the client_id could be the sub of ID token
Discussion about ‘call home’ and linkability concerns
The identity of the wallet/client should be distinct from the identity of the person
Lifecycle of each is different
POP of the keys of the VC should occur after the OIDC request (which authenticates the user and gets consent)- wallet should use a back channel to request a VC issuance
Prefer that the demonstrated POP is an aud constrained nonce that is client bound (versus a server-generated nonce)
Decoupling between authentication and authorization.
There is a need for metadata. Something that is registered with IANA. It’s specific to the issuer.
The latest OpenID Connect draft uses scopes for the OpenID credential. It shifts to the backchannel model.
OpenID request - user request is based on the protocol so user consent is the best way to do this.
Different from the normal kind of release
This exists because people see value in different kinds of claims. Before they erred on the side of less complexity. But now they believe that the solution is possible.
Q: FIDO authenticators or sign in with Apple, etc... , any of these authenticators generally don’t have a plugin to ask for consent. The consent piece is usually missing from a FIDO 2 authenticator. Is it combined in this flow being described.
A: User agent doing authentication and client doing consent.
Q: At a protocol level, how do the two agents (authentication/consent) interact with each other?
Q: One vs. many VC types? What is presented to the user for consent. A VC can do whatever it wants. Example: “You got 10% off a
A: It should be part of the flow. But the example doesn’t. There is a price match policy, but if the VC is presented to the coupon redemption center, it will not work. So the store is out of that 10%. The redemption is never made.
In the implicit flow there is no token endpoint.