3E/ VC Issuance using OpenID Connect

From IIW

VC Issuance using OIDC

Tuesday 3E

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

  • [[File:./media/image1.jpeg|624x322px]]

  • Claims aggregation and credential provider are being merged in OIDF as a starting point

[[File:./media/image2.jpeg|624x349px]]

  • “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?

A: ? Related: Microsoft Authenticator in VC issuance does request user consent JFYI

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 bakery manufacturer’s product. The Terms of Use says that you can only use this at XYZ Market. But going to ABC Market, they decide the VC as well.”

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.

Retrieved from "https://iiw.idcommons.net/index.php?title=3E/_VC_Issuance_using_OpenID_Connect&oldid=23950"