Credential response structure based on `multiple`

[QZHelen]

I would like to bring up an interoperability discussion regarding a recent change to support returning multiple presentations for a single dcql credential query when requested using multiple.

The latest spec mandates that a credential response is always returned as an array, even when only a single presentation is requested. Here's an example:

{
  "my_credential": ["eyJhbGci...QMA"]
}

While this approach accommodates the multiple: true case, we are concerned about the developer ergonomics when multiple is false (which is the default and most common scenario).

We think it'd be a cleaner split if the response structure can depend on the value of the multiple parameter.

• When multiple is true, returning an array makes sense:

  {
    "my_credential": ["eyJhbGci...QMA"]
  }
  

• When multiple is false, the response should be the credential itself, not wrapped in an array:

  {
    "my_credential": "eyJhbGci...QMA"
  }
  

Since the caller sets the multiple parameter, they will know how to parse the response accordingly.

Justification:

• Default Use Case: The multiple parameter is false by default and will likely cover the majority of use cases. Forcing an array in all instances complicates the most common scenario.
• Developer Experience: An unconditional array response can be surprising and confusing for developers who are not aware of the optional multiple parameter. It forces them to handle an array, raising questions about how to treat empty arrays or arrays with multiple elements when multiple was false.
• Code Clarity: This approach can lead to code like result = vp_token["my_credential"][0], which can be brittle.

I understand we are approaching a vote on OpenID4VP v1.0, and I recognize the timing of this feedback is not ideal (sorry, really wished I saw this sooner!). However, still wanted to raise this issue to see what options are available. How feasible is it to have a quick discussion to determine if a resolution is feasible at this stage? At the very least, I'd like to have this concern documented. Addressing this would allow me not having to explain the redundant array in our developer documentation for concrete use cases in the foreseeable future. Reducing small complexities like this can add up and really benefit the developer experience. Thanks!

[bc-pi]

FWIW, I find @QZHelen's reasoning here to be quite sound and compelling. There has been, IMHO, an undeserved vilification of type-fluid JSON that can lead to a different kind of negative impact on developer ergonomics.

[GarethCOliver]

I think I disagree here. It's true for toy examples, but in a production system I'd much rather be able to structure it so that responses can be handled as follows:

Step 1) Parse VP Token into a set of Credentials
Step 2) Validate Credentials cryptographically
Step 3) Check if Credentials returned satisfy business logic

Step 1 and 2 shouldn't depend on the request, and multiple is part of step 3. Requiring understanding this in step 1 isn't great from an encapsulation perspective.

It's not a big deal (writing a getElementOrArray(): List<...> helper is not hard), but it is IMO worse than always returning the same thing.

All of your concerns appear to be solved by using a .single() helper function, which does not warrant a change in the spec.