Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

support returning multiple presentations for a single dcql credential query when requested using multiple #398

Merged
merged 6 commits into from
Feb 27, 2025
Merged

support returning multiple presentations for a single dcql credential query when requested using multiple #398

Changes from all commits
Commits
Show all changes
6 commits
Select commit Hold shift + click to select a range
860c76f
support returning multiple presentations for a single dcql credential…
charsleysa Jan 28, 2025
d912e5d
fix typo
charsleysa Jan 28, 2025
c585737
changes based on feedback
charsleysa Jan 30, 2025
389e7de
apply suggestion
charsleysa Jan 31, 2025
7ba6150
Merge branch 'openid:main' into implment-298
charsleysa Feb 17, 2025
9ee9b81
fix document history
charsleysa Feb 17, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
24 changes: 19 additions & 5 deletions openid-4-verifiable-presentations-1_0.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -669,8 +669,8 @@ unknown properties.

## Credential Query {#credential_query}

A Credential Query is an object representing a request for a presentation of one
Credential.
A Credential Query is an object representing a request for a presentation of one or more matching
Credentials.

Each entry in `credentials` MUST be an object with the following properties:

Expand All @@ -686,6 +686,9 @@ be present more than once.
Verifiable Credential. Valid Credential Format Identifier values are defined in
(#format_specific_parameters).

`multiple`:
: OPTIONAL. A boolean which indicates whether multiple Credentials can be returned for this Credential Query. If omitted, the default value is `false`.

`meta`:
: OPTIONAL. An object defining additional properties requested by the Verifier that
apply to the metadata and validity data of the Credential. The properties of
Expand Down Expand Up @@ -979,7 +982,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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what are the implications? reconsidering a change introduced in this PR? adding a note in this PR? opening an issue? no action?

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i created this issue #439 to continue the discussion if needed.

* In case [@!DIF.PresentationExchange] was used, it is a string or JSON object that MUST contain a single Verifiable Presentation or an array of strings and JSON objects each of them containing a Verifiable Presentation. Each Verifiable Presentation MUST be represented as a string (that is a base64url-encoded value) or a JSON object depending on a format as defined in (#format_specific_parameters). When a single Verifiable Presentation is returned, the array syntax MUST NOT be used. If (#format_specific_parameters) 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 string.

`presentation_submission`:
Expand Down Expand Up @@ -1013,7 +1016,17 @@ brevity):

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

The following is a non-normative example of the contents of a VP Token
containing multiple Verifiable Presentations in the SD-JWT VC format when the
Credential Query has `multiple` set to `true` (shortened for brevity):

```json
{
"my_credential": ["eyJhbGci...QMA", "eyJhbGci...QMA", ...]
}
```

Expand Down Expand Up @@ -2277,7 +2290,7 @@ An example DCQL query using the mdoc format is shown in (#more_dcql_query_exampl

```json
{
"my_credential": "<base64url-encoded DeviceResponse>"
"my_credential": ["<base64url-encoded DeviceResponse>"]
}
```

Expand Down Expand Up @@ -2812,6 +2825,7 @@ The technology described in this specification was made available from contribut
* add language on client ID and nonce binding for ISO mdocs and W3C VCs
* clarify the behavior is not to sign when authorization_signed_response_alg is omitted
* add a note on the use of apu/apv in the JWE header of encrypted responses
* support returning multiple presentations for a single dcql credential query when requested using `multiple`

-24

Expand Down