How to support LD-Proofs in Verifiable Presentations

Comments (12)

1. 

   Kristina Yasuda

   I would merge this one with #1205.

   • 2021-02-09T05:03:22+00:00
2. 

   Kristina Yasuda

   On 02-09-2021 call, Mike noted that IANA registered vc vp claims in W3C Verifiable Credentials specification should cover all kinds of VCs.

   Kristina noted that if that is the case, we should keep the usage of those claims.

   Input from Verifiable Credentials specification expert is needed.

   • 2021-02-09T05:05:17+00:00
3. 

   Kristina Yasuda

   also worth noting that RP is communicating in the registration parameters included in the request which credential formats (JWT, JSON-LD, etc.) it supports. If SIOP is sending back VC/VP without throwing an error, it must mean that SIOP supports credential format indicated by RP

   • 2021-02-09T05:07:03+00:00
4. 

   Kristina Yasuda

   The issue was discussed on 2-25-2021 Atlantic call

   • To include claims signed using different signature formats, encoding should be standardized - Base64 URL encoding and JOSE structure are the options
   • Syntax of Aggregated / Distributed claims should be used to include claims signed using different signature formats that are encoded
   • Should be easy for the RPs to accept regardless of the signature format - anyone can write the library

   ‌

   • 2021-02-25T16:28:04+00:00
5. 

   Oliver Terbu reporter

   Proposal:

   Define a new response parameter (query string/token endpoint) vp_token that represents the W3C Verifiable Presentation:

   • JSON LD
   • Decoded JWT VC

   If the vp_token is returned through the front channel / query string, then we would need to introduce an additional vp_hash (hash of the vp_token) in the id_token.

   Requirement:

   • define new response_type for vp_token
   • IANA registration of vp_hash

   Pros:

   • consistent handling of W3C VPs for all encodings of VCs
   • extensibility
   • easy to reuse in other OIDC flows

   Cons:

   • extension of existing OP to support a new response_type is a little more complicated than adding a new claim to the id_token (e.g., would a POC be support with Auth0?)

   ‌

   • 2021-03-02T18:10:33+00:00
6. 

   Torsten Lodderstedt

   The proposal sounds reasonable to me as it allows clear separation of Id token and vp token processing (JSON LD, schemas, …).

   Signaling the AS via response type that it shall issue a vp token limits the vp token to a certain flow (e.g. front channel). I would rather suggest to use a scope value „vp_token“ or a new container in the claims parameter to request vp token issuance. This way the new token can be used in conjunction with any flow, including code, device, CIBA. It is also inline with the way the „openid“ scope requests id token issuance.

   • 2021-03-02T18:32:18+00:00
7. 

   Oliver Terbu reporter

   Agree that the response_type might be unnecessary and it would restrict the usage of this mechanism in other flows. I’m fine with introducing a new scope instead, e.g., vp or vp_token, that results in a vp_token.

   • 2021-03-02T19:03:57+00:00
8. 

   Alen Horvat

   What about embedding a VP into an ID Token (I understand there’s an overhead as both ID Token and VP are signed) similar to verified claims in https://openid.net/specs/openid-connect-4-identity-assurance-1_0-ID2.html

   • 2021-03-16T21:26:55+00:00
9. 

   Nat Sakimura

   • changed status to open

   • 2021-05-24T23:28:02+00:00
10. 

    Kristina Yasuda

    If Oliver agrees, I think we can close this, as this has been addressed in the request syntax in the recently adopted OpenID Connect for Verifiable Presentations draft.

    • 2021-05-24T23:46:44+00:00
11. 

    Michael Jones

    • changed status to resolved

    This is being addressed in OpenID Connect for Verifiable Presentations.

    • 2021-05-25T18:16:35+00:00
12. 

    Oliver Terbu reporter

    Sounds good to me @Kristina

    • 2021-05-25T21:34:47+00:00
13. Log in to comment