OpenID Connect for W3C Verifiable Credential Objects
- 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)