simplify VP Token encoding when only one VP is returned?

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

[Kristina Yasuda]

To summarize what is meant for the current text, it is the following:

1. How a Verifiable Presentation is represented when included in a VP Token depends on a credential format - it can be a string (jwt-vc, sd-jwt, iso mDL), or an object (linked data proof VC, JSON serialization jwt-vc with JaDES), which is defines in appendix E.
2. when there is only one verifiable presentation returned in a VP Token, it is either string or object per above. when there are multiple VPs are it is an array, which consists of multiple strings, multiple objects or multiple strings and objects, again depending on a credential format

Having said that, editors think this can be simplified as follows, and would like to ask a WG.

• point 1 above stays the same
• point 2 is modified for a VP Token to always be an array, regardless of how many VPs are returned, so multiple VP scenario is the same, one VP scenario is simplified to be an array of one string or one object.

‌

[Daniel Fett]

Proposed wording:

A VP Token can take one of the following forms:

• A JSON-encoded String representing a single VP.
• A JSON-encoded Object representing a single VP.
• A JSON-encoded Array of Strings or Objects, each representing a single VP.

If Appendix E of [@!OpenID.VCI] defines a rule for encoding the respective credential format in the credential response, these rules MUST be followed when encoding the respective presentation in the `vp_token` response parameter.Other formats can be used without further encoding when the respective format already defines a representation as a JSON object or JSON string.If no such representation exists, the credential format is not compatible with this specification.

[Daniel Fett]

Actually just now saw Kristina’s comment. +1 for simplifying towards always using an array.

[Kristina Yasuda]

SIOP call: agreed to do a PR to clarify the description according to how it is defined right now, and keep gathering feedback if it should be simplified to use array even when there is one VP:

• pros: no polymorphism
• cons: more complex when there is only one VP, which could be the major use case

[Kristina Yasuda]

the working has already been clarified in a PR #404:

`vp_token`:

REQUIRED. JSON String or JSON object that MUST contain a single Verifiable Presentation or an array of JSON Strings and JSON objects each of them containing a 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.

so remaining issue is whether to simplify or not..

‌

[Daniel Fett]

I don’t find the updated wording much clearer than the old one. In particular the first sentence confused me initially. I still propose to modify as suggested.

[Kristina Yasuda]

Issue #1796 is conditional to this one.

[David W Chadwick]

If we say that vp token is always an array this simplifies the text in the standard and it simplifies the parsing by the recipient, as it will always expect an array.

[Kristina Yasuda]

one step forward: clarify that when one VP is returned, it MUST NOT be an array.

[Michael Jones]

We agreed on the 9-Mar-23 SIOP call to add text saying that single values must not be returned as an array.

[Kristina Yasuda]

during the SIOP call agreed that the current direction is to keep the current definition and not to simplify to say vp token is an array even when only one VP is returned. Majority of the current implementations return only one VP and that should be kept simple (no array) and there is not enough implementation feedback that that is a problem.

clarification made with PR #481.

might come back and reopen in the future.