@danielfett I spoke with you at IIW about the above requirement that we have.

A suggestion I would make is to add a multiple flag to credential sets that would be used to say that the RP wants to receive all matching versions of a credential, not simply one.

{
   "credentials": [
     {
       "id": "pid",
       "format": "vc+sd-jwt",
       "meta": {
         "vct_values": ["https://credentials.example.com/identity_credential"]
       },
       "claims": [
         {"path": ["given_name"]},
         {"path": ["family_name"]},
         {"path": ["address", "street_address"]}
       ]
     },
     {
       "id": "degrees",
       "format": "vc+sd-jwt",
       "meta": {
         "vct_values": ["https://credentials.example.com/education_degree"]
       }
     },
     {
       "id": "work_experience",
       "format": "vc+sd-jwt",
       "meta": {
         "vct_values": ["https://credentials.example.com/employment_role"]
       }
     }
  ],
  "credential_sets": {
      {
       "purpose": "Identification",
       "options": [
         [ "pid" ]
       ]
       // implicitlu multiple: false
     },
     {
       "purpose": "Resume",
       "options": [
         [ "degrees", "work_experience"]
       ],
      "multiple": true
     }
  }
} 

Considerations

The benefit of the proposal above is that it changes the behaviour for all options in the credential_set making it easy to adjust the Wallet UI to be a multiselect for that particular set. Alternatives would be to permit changes on a per option list or even per option basis, but I dont see what the use case for that would be, and makes the simple UI challenging

Also another consideration is the name of this property but I'll leave that for a discussion

WDYT?

ISO have implemented a way to say that the verifier will accept multiple matching credentials being returned in the latest draft of ISO 18013-5 and would like to see OID4VP mdoc profile also supporting that use case (so we need to expand DCQL somehow to allow that). Examples given were having two driving licenses for two different people and presenting them both, or presenting multiple cinema tickets at the same time.

The use cases described by @sloops77 resonates with me. I think either all RPs must be ready to receive multiple instances (in the same way every wallet must be able to receive multiple instances in OID4VCI) or the RP declares it is ready to process multiple of them. If the RP would be not ready and the user would have multiple instances, I would assume the user would need to pick one.
On the response, I would suggest to allow the wallet to return a single of multiple credential presentation underneath one key.

On the response, I would suggest to allow the wallet to return a single of multiple credential presentation underneath one key.

This means that vp_token in the case of DCQL would be a json object, where claim name is a credential query identifier and the value could be either a string, or a json object, or a json array of strings or json objects.

Is this what you had in mind?

{
  "degrees" : [ "deg1" ,  "deg2" ],
  "work_experience" : [ "we1", "we2" ]
}

BTW, I find somehow confusing to have an option that requires both degrees AND work_experience (expressed as [ "degrees", "work_experience"]) and, at the same time, having multiple flag set.
In particular, it is not clear whether a verifier should accept a response that contains more than one degrees but no work_experience. Perhaps, two distinct credentials sets (one for degrees and another for work_experience) would have been more straightforward.

on the response, I would say that vp_token in the case of DCQL would be a json object, where claim name is a credential query identifier and the value is always a json array of strings or json objects? (i.e. no need for an option where the value is a string only)

on the request, i think we should introduce a mechanism to indicate verifier wants multiple credentials to be returned for the same credential query (not sure if multiple boolean is the best). so de facto, all wallets need to be able to process this, but the verifier need to support this feature only if it needs it?

on the response, I would say that vp_token in the case of DCQL would be a json object, where claim name is a credential query identifier and the value is always a json array of strings or json objects? (i.e. no need for an option where the value is a string only)

An alternative would be keep the vp_token a json object of string to VP, and then have have the VP contain multiple credentials all matching the Credential Query. Since VP is a lower level primitive, this would be my preference. Otherwise there would be two valid ways to respond to the same query adding processing complexity for the RPs

on the response, I would say that vp_token in the case of DCQL would be a json object, where claim name is a credential query identifier and the value is always a json array of strings or json objects? (i.e. no need for an option where the value is a string only)

That would be a welcomed simplification, IMHO.

For request the optional and multiple are two flags perhaps can be replaced by a single attribute called multiplicity with the following values (or similar):

• "0..*" => optional true, multiple true
• "1..*" => optional false, multiple true
• "1" => optional false, multiple false (Default)

WG discussion

• agreement that this is a useful feature
• support to make it an array

WG discussion

started with the proposal that for the request, one design can be to add a boolean multiple with default being false:

"credential_sets": {
{
"purpose": "Vaccination credential",
"options": [
[ "vaccination"]
],
"multiple": true
}
}

feedback that Give me “all” probably doesn’t work for most use cases.

Ask for a specific use-case. some examples from the zoom chat:

• Another situation is when you hold multiple passports issued by different countries (e.g., dual citizenship). There may be situations where the hold only wants to reveal one of those credentials due to political situation.
• Vaccine is closest, because you could see a health care system wanting most of them. Either way, I could see that being severely abused.
• There is a payments use-case too. Where you return two cards (of the same cred type) with differtn transaction data to split the bill across cards

Outcome seems to be that it is similar to a selective disclosure at the credential level that the wallet should not blankly return all credentials, and should let the user choose whether to return, one, three or all (10?) credentials.

Outcome seems to be that it is similar to a selective disclosure at the credential level that the wallet should not blankly return all credentials, and should let the user choose whether to return, one, three or all (10?) credentials.

I can also add a use-case that we recently implemented for EUIPO, where the verifier queries wallet for one or more credentials, each one representing an intellectual property right of the holder.
And Indeed, in this use-case,

• it is holder's decision/selection which to include.
• "Give me all" query had no business value. Rather, present all, as a UIX function that allows the holder to easily select all matching credentials is a handy convenience.

Returning to DCQL, IMHO

• This feature perhaps should be treated as mandatory. There are several use-cases that can benefit from this.
• There should be a way for the verifier to formally express the expected multiplicity for a given query.
• This is a property of the query, yet since required is defined at the credential_set level perhaps the indication multiple credentials should also be defined there (to thecredential_set).
• To add "multiple" flag to the credential_set may cause some confusion in cases like the one bellow, where there is an option which is comprised by two queries.

{
    "purpose": "Identification",
    "multiple": true,
    "options": [
      [ "pid" ],
      [ "other_pid" ],
      [ "pid_reduced_cred_1", "pid_reduced_cred_2" ]
    ]
  }

The heart of this issue seems to be that a verifier may have a legit need to request multiple credentials, but we also don't want verifiers to over-request credentials from the holder's wallet, essentially becoming credential hoovers.

One solution approach might be at the wallet UI level: a holder could pre-select which credentials may be released ahead of a given presentation -- say, before presenting credential(s) at an airport customs control point. However, AFAIK, wallet UI is out of scope for our DCP specs. Perhaps we could add some non-normative text for wallet implementers might be a middle-ground way forward?

Alternatively, we could get into which verifiers are allowed to make what kinds of requests. This would be very messy though from a trust model perspective and I cannot recommend it.

I think the "multiple" element should go into the credential part, not the credential set. It doesn't make sense in the credential set.

The logic would be that if it is true, in the response, an array is used for this credential ID.

I think the "multiple" element should go into the credential part, not the credential set. It doesn't make sense in the credential set.

The logic would be that if it is true, in the response, an array is used for this credential ID.

I agree.

This would solve another potential issue, as well. Given that credential_set is not mandatory, having multiple inside the query would allow a verifier to express this requirement, without having to use a credential_set.

ISO 18013-5 rev 2 has a text relevant to this and multiple element in the credential part in DCQL should meet this requirement

MultiplePossible
If MultiplePossible is set to True, this is an indication by the mdoc reader that it can receive multiple instances of responses to this exact DocRequest. This can support use cases where it can be useful to return multiple documents of the same type. Examples include: vehicle licences for trailer and care, multiple diplomas, multiple concert tickets.
If MultiplePossible is not set to True, only 1 document should be returned to satisfy the respective DocRequest.

I've created a PR (#398) implementing multiple in the credential query as discussed in this issue.