How to support LD-Proofs in Verifiable Presentations
vp: supports JWT only, in order to get this adopted by a broader SSI community, we would need to think about how to add support for other proof types, ie LD-Proofs.
Comments (12)
-
-
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.
-
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
-
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
-
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 additionalvp_hash
(hash of thevp_token
) in theid_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?)
-
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.
-
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.
-
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
-
- changed status to open
-
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.
-
- changed status to resolved
This is being addressed in OpenID Connect for Verifiable Presentations.
-
reporter Sounds good to me @Kristina
- Log in to comment
I would merge this one with
#1205.