support returning multiple presentations for a single dcql credential query when requested using multiple
#398
Conversation
… query when requested using `multiple` Signed-off-by: Stefan Charsley <charsleysa@gmail.com>
| @@ -978,7 +981,7 @@ When a VP Token is returned, the respective response includes the following para | |||
|
|
|||
| `vp_token`: | |||
| : REQUIRED. The structure of this parameter depends on the query language used to request the presentations in the Authorization Request: | |||
| * If DCQL was used, this is a JSON-encoded object; the keys are the `id` values used for the Credential Queries in the DCQL query, and the values are the Verifiable Presentations that match the respective Credential Query. The Verifiable Presentations are represented as strings or objects depending on the format as defined in (#format_specific_parameters). The same rules as above apply for encoding the Verifiable Presentations. | |||
| * If DCQL was used, this is a JSON-encoded object which contains entries having: the key as the `id` value used for a Credential Query in the DCQL query; and the value as an array of one or more Verifiable Presentations that match the respective Credential Query. When `multiple` is not `true`, the array MUST contain only one Verifiable Presentation. There MUST NOT be any entry in the JSON-encoded object for optional Credential Queries when there are no matching Credentials for the respective Credential Query. The Verifiable Presentations are represented as strings or objects depending on the format as defined in (#format_specific_parameters). The same rules as above apply for encoding the Verifiable Presentations. | |||
There was a problem hiding this comment.
what are you trying to say with There MUST NOT be any entry in the JSON-encoded object for optional Credential Queries when there are no matching Credentials for the respective Credential Query.? if "do not return what was not requested", wasn't this somewhere in the processing rules?
There was a problem hiding this comment.
The intention of this wording was to clarify that if optional credentials are requested, but there are no matching credentials, do not include an empty entry in the JSON-encoded object (eg. "my_optional_credential": []).
If this is already covered in another section I can remove this wording.
Co-authored-by: Kristina <52878547+Sakurann@users.noreply.github.com>
| @@ -978,7 +981,7 @@ When a VP Token is returned, the respective response includes the following para | |||
|
|
|||
| `vp_token`: | |||
| : REQUIRED. The structure of this parameter depends on the query language used to request the presentations in the Authorization Request: | |||
| * If DCQL was used, this is a JSON-encoded object; the keys are the `id` values used for the Credential Queries in the DCQL query, and the values are the Verifiable Presentations that match the respective Credential Query. The Verifiable Presentations are represented as strings or objects depending on the format as defined in (#format_specific_parameters). The same rules as above apply for encoding the Verifiable Presentations. | |||
| * If DCQL was used, this is a JSON-encoded object containing entries where: the key is the `id` value used for a Credential Query in the DCQL query; and the value is an array of one or more Verifiable Presentations that match the respective Credential Query. When `multiple` is omitted, or set to `false`, the array MUST contain only one Verifiable Presentation. There MUST NOT be any entry in the JSON-encoded object for optional Credential Queries when there are no matching Credentials for the respective Credential Query. Each Verifiable Presentation is represented as a string or object, depending on the format as defined in (#format_specific_parameters). The same rules as above apply for encoding the Verifiable Presentations. | |||
There was a problem hiding this comment.
I think we need to take a step back and consider how we reference a returned verifiable presentation against not only a credential query but also a credential set otherwise with complex queries it may become increasingly difficult for the verifier to understand how the query was satisfied when a credential set was used. If we accept this proposal as is, without discussing that I think we might make that issue worse.
There was a problem hiding this comment.
@tplooker My understanding is these changes shouldn't add complexity to credential set functionality.
The only change is that the RP can now receive more than one presentation if they have specified so using multiple in the credential query, so instead of performing a single check on a single presentation the RP would perform the same check on each presentation in the array. Essentially the checks are now always performed in a loop.
This complexity is added to the check at the credential query level rather than the credential set level.
Though I do see your point that there is more complexity being added overall, moreso when factoring in other desired changes such as #397.
There was a problem hiding this comment.
Agreed, have made a comment with regard to that issue, another example I was thinking of here though is how will this feature interact with the credential_sets feature more generally? For example.
{
"credentials": [
{
"id": "foo",
"multiple": true,
....
},
{
"id": "bar",
"multiple": false,
....
},
],
"credential_sets": [
{
"purpose": "some purpose",
"options": [
[ "foo" ],
[ "bar" ]
]
}
]
}
Basically in response to the credential_sets query I might get one credential in response to the underlying "bar" credential_query OR N credentials in response to the underlying "foo" query.
Again maybe we view this as an edge case and therefore are not that concerned but its worth considering how the complexity might compound here.
There was a problem hiding this comment.
what are the implications? reconsidering a change introduced in this PR? adding a note in this PR? opening an issue? no action?
There was a problem hiding this comment.
@tplooker i think this is an edge case but also that the spec makes sense for the use cases I'm dealing with. To make foo and bar concrete an RP could ask for either my transcript OR multiple course badges
Signed-off-by: Stefan Charsley <charsleysa@gmail.com>
For what is worth, I have implemented such a use-case (see #298 (comment)). I believe that there would be additional use-cases that could take advantage of this feature. Certainly, yhe way that this is handled by Wallet UX is important, but perhaps this is another concern. |
We have implemented this as well. The UI is pretty simple with checkbox selection. For credential queries where only one can be selected, the other credentials become disabled. When multiple can be selected, they all remain enabled.
|
Closes #298
Signed-off-by: Stefan Charsley charsleysa@gmail.com