How to support LD-Proofs in Verifiable Presentations

Issue #1206 resolved
Oliver Terbu created an issue

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)

  1. 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.

  2. 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

  3. 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

  4. Oliver Terbu reporter


    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.


    • define new response_type for vp_token
    • IANA registration of vp_hash


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


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

  5. 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.

  6. 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.

  7. 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.

  8. Log in to comment