This document discusses proposals for supporting the request and presentation of verifiable credentials in OpenID Connect. It presents three options for delivering verifiable credentials/presentations: 1) embedding the entire credential/presentation in a JWT claim in the ID token, 2) using aggregated or distributed claims to include the credential/presentation, or 3) using a separate "VP token" artifact containing the credential/presentation along with an ID token. The document analyzes the pros and cons of each approach and seeks feedback on the best option to pursue as well as next steps like discussing with the Connect working group and incorporating encryption.

1. OpenID Connect for W3C
Verifiable Credential
Objects
IIW Spring 2021
Kristina Yasuda, Oliver Terbu, Torsten Lodderstedt, Adam
Lemmon, Tobias Looker

2. Objectives
- Support request and presentation of Verifiable Credentials in ID Tokens and
Userinfo responses
- Usable with all OpenID Connect Flows (SIOP, code, CIBA, …)
- Leverage OpenID Connect as simple to use protocol for wallet integrations
- Leverage W3C verifiable credentials to existing OpenID Connect
deployments

3. Ideas
- Request
- via “claims” parameter
- Simply claims or credential type or credential type + claims (selective disclosure)
- 3 delivery options under discussion
- 1) Define JWT claims to embed entire VP/VC in any format (awoie/vp-token-spec/pull/20)
- https://github.com/Sakurann/vp-token-spec
- 2) Aggregated & Distributed Claims (awoie/vp-token-spec/pull/23)
- https://github.com/awoie/vp-token-spec/tree/adc
- 3) VP Token as separate artifact + ID Token as Verifiable Presentation (current revision)
- https://github.com/awoie/vp-token-spec

4. 1) vp_jwt Claim
parameters
of ID Token

5. 1) vp_ldp
Claim
parameters of
ID Token

6. 1) vc_jwt Claim
parameters
of ID Token
Under discussion whether
VCs can be directly
embedded inside the ID
Token.

7. 1) vc_ldp
Claim
Under discussion whether
VCs can be directly
embedded inside the ID
Token.
parameters of
ID Token

8. 2) Aggregated
Claims
VP present in value

9. 2) Distributed
Claims
Endpoint from which the VP can be
retrieved

10. 2) Distributed
Claims - Obtain VP

11. 3) Separate artifact
- ‘VP Token’
ID Token contains a `vp_hash`
‘VP Token’ contains an entire VP
`claims` parameter in the request

12. Pros and Cons: processing, RP adoption
1) Independent Claims for each
proof type
2) Extended Aggregated/Distributed
Claims (ADC) Syntax
3) Separate Artifact `VP
Token`
Pros - Standard extension point works
with existing libraries.
- VC/VP claims can be processed
by the same generic JWT code that
handles any other kind of optional
claim
- Explicit distinction of proof format
and claim content
- Extensibility via existing OIDC
ADC syntax
- Clear separation between OIDC
assertion and VC/VP
- Flexible re request (standard
claims or VC/VP) and delivery
(embedded or separate VC/VP)
- Clear separation of new
artifacts VPs/VCs from
OIDC claims/contests
(processing rules)
- Could support vp_token
only use cases (via new
response type)
Cons - The ID token signature over
vp_jwt/vc_jwt could be
misconceived to turn ID token into a
VC/VP
- ID Token must carry claims in
addition to authentication data in
case of implicit flow (no userinfo
available)
- RPs must inspect each container
item to determine how to process
the claim (dictionary can be added)
- Some additions to the libraries to
support new properties of ADC
syntax
- VP/VC claims carried in
different way than other
claims
- Requires (significant)
changes to existing libraries
- standalone vp_tokens
cannot be protected using
established OIDC means

13. Next Steps
● Discuss and decide delivery method
● Ask Connect WG for adoption
● Incorporate encryption (e.g. confidentiality protection in case where OP is just
a cloud agent)

14. Discussion ;-)

15. Requests

16. Request for Verifiable Presentation (Type)

17. Request for Verifiable Presentation (Type and Claims)

18. “Just” Request Claims