[Openid-specs-ab] Issue #1768: VP Token encoding section is hard to understand (openid/connect)

Daniel Fett issues-reply at bitbucket.org
Fri Jan 6 14:30:18 UTC 2023


New issue 1768: VP Token encoding section is hard to understand
https://bitbucket.org/openid/connect/issues/1768/vp-token-encoding-section-is-hard-to

Daniel Fett:

The definition of `vp_token` currently reads:

> String parameter that MUST either contain a single Verifiable Presentation or an array of Verifiable Presentations. Each Verifiable Presentation MUST be represented as a JSON string \(that is a Base64url encoded value\) or a JSON object depending on a format as defined in Annex E of \[@!OpenID.VCI\]. If Appendix E of \[@!OpenID.VCI\] defines a rule for encoding the respective credential format in the credential response, this rules MUST also be followed when encoding credentials of this format in the \`vp\_token\` response parameter. Otherwise, this specification does not require any additional encoding when a credential format is already represented as a JSON object or a JSON string.

I’m completely confused as to what this paragraph means. For example, if I want to use “array of Verifiable Presentations”, how would that be encoded? What about just one VP, would the `vp_token` indeed be a JSON-ified string, i.e., starting with quotation marks? 

I suggest to address this together with Issue #1765 and to introduce, in a separate section, both the semantics of a VP Token and the encoding, since this is a central concept of the specification.



More information about the Openid-specs-ab mailing list