Clarify an empty object in a VP Token cannot be used to signify an error response by awoie · Pull Request #745 · openid/OpenID4VP

awoie · 2026-06-18T17:23:19Z

Fixes #743

needs errata? change 1.0?

I also improved the vp_token definition because it is a quite important part of the spec and the readability was not great.

I removed this editorially because I don't think it had any meaning anymore:

The same rules as above apply for encoding the Presentations.

awoie · 2026-06-18T17:31:42Z

We probably will need to apply this logic to DC API as well. I will need to double check if this is included with the current proposed text.

fkj

If people don't object to the rewriting of the definition, I agree that this makes it easier to understand what we actually mean.

Sakurann · 2026-07-02T15:26:45Z

wg discussion, should be in the errata as well.

Co-authored-by: Kristina <52878547+Sakurann@users.noreply.github.com>

New test module oid4vp-1final-wallet-negative-test-required-non-matching-credential sends a DCQL query whose credential_sets require both the real credential and a non-existent one. As the query as a whole cannot be satisfied, the wallet must not return a vp_token - neither an empty object nor a partial one containing only the real credential - as clarified in openid/OpenID4VP#745. The module accepts either an error response (access_denied expected; other codes give a warning; encrypted error responses are supported in the .jwt response modes) or the wallet rejecting the request and displaying an error, verified via a screenshot placeholder. AddOptionalNonMatchingCredentialToDcqlQuery is refactored into an abstract base shared with the new required variant, and the browser API response parsing/rejection handling in AbstractVP1FinalWalletTest is extracted into reusable helpers. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Per WG consensus on #743, an empty VP Token (i.e., {}) MUST NOT be used, including to signify an error. When the Wallet has no Presentation to return - e.g., no consent, no matching Credentials, or a DCQL query satisfiable without any Presentation because all unfulfilled Credential Queries are optional - any response it returns MUST be an error response rather than a VP Token. Also fixes the truncated sentence in the vp_token requirements, applies the same clarification to 1.0 as an errata set 1 change with changelog entries in both documents, and removes the accidentally committed .DS_Store.

awoie · 2026-07-09T10:28:34Z

Please review again @jogu @paulbastian @Sakurann . @jogu Note that if my memory is correct that the WG agreed to prohibit empty vp_token's even for the case where the DCQL query has only optional queries.

An empty vp_token object cannot be used to signify an error response; the wallet must return an authorization error response instead. This is being clarified for OID4VP 1.1 and the 1.0 errata in openid/OpenID4VP#745 (which fixes openid/OpenID4VP#743). Previously an empty object was rejected by the entry-count check with a misleading 'seems to contain more than one credential' message. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

…iple' Per OID4VP 1.0 section 8.1 the array for a Credential Query must contain exactly one Presentation when 'multiple' is omitted or false ('only one' in the 1.0 text, reworded to 'exactly one' in openid/OpenID4VP#745). Previously any extra presentations in the array were silently ignored. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

New test module oid4vp-1final-wallet-negative-test-required-non-matching-credential sends a DCQL query whose credential_sets require both the real credential and a non-existent one. As the query as a whole cannot be satisfied, the wallet must not return a vp_token - neither an empty object nor a partial one containing only the real credential - as clarified in openid/OpenID4VP#745. The module accepts either an error response (access_denied expected; other codes give a warning; encrypted error responses are supported in the .jwt response modes) or the wallet rejecting the request and displaying an error, verified via a screenshot placeholder. AddOptionalNonMatchingCredentialToDcqlQuery is refactored into an abstract base shared with the new required variant, and the browser API response parsing/rejection handling in AbstractVP1FinalWalletTest is extracted into reusable helpers. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

An empty vp_token object cannot be used to signify an error response; the wallet must return an authorization error response instead. This is being clarified for OID4VP 1.1 and the 1.0 errata in openid/OpenID4VP#745 (which fixes openid/OpenID4VP#743). Previously an empty object was rejected by the entry-count check with a misleading 'seems to contain more than one credential' message. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

…iple' Per OID4VP 1.0 section 8.1 the array for a Credential Query must contain exactly one Presentation when 'multiple' is omitted or false ('only one' in the 1.0 text, reworded to 'exactly one' in openid/OpenID4VP#745). Previously any extra presentations in the array were silently ignored. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

New test module oid4vp-1final-wallet-negative-test-required-non-matching-credential sends a DCQL query whose credential_sets require both the real credential and a non-existent one. As the query as a whole cannot be satisfied, the wallet must not return a vp_token - neither an empty object nor a partial one containing only the real credential - as clarified in openid/OpenID4VP#745. The module accepts either an error response (access_denied expected; other codes give a warning; encrypted error responses are supported in the .jwt response modes) or the wallet rejecting the request and displaying an error, verified via a screenshot placeholder. AddOptionalNonMatchingCredentialToDcqlQuery is refactored into an abstract base shared with the new required variant, and the browser API response parsing/rejection handling in AbstractVP1FinalWalletTest is extracted into reusable helpers. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

brentzundel · 2026-07-16T15:44:40Z

WG discussion: @awoie will make some changes to address @jogu remainning concern

brentzundel · 2026-07-16T15:46:47Z

@paulbastian will review as well

…ed privacy considerations of dc api, so it applies to regular flow as well Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Co-authored-by: Joseph Heenan <joseph@authlete.com>

awoie · 2026-08-06T13:42:00Z

@jogu You're right, {#privacy-error-responses} would have changed the published anchor and broken existing links. So I dropped the explicit anchor and used (#error-responses) for the three cross-references instead.

DC API specificity: Partly agreed. The underlying consideration isn't unique to the DC API. A Wallet in a redirect-based flow that returns an error depending on whether it can match the request leaks the same information, which is what the two SHOULD NOT paragraphs below the list already address. But you're right that the bullets were phrased as unconditional, and that absolute only holds for the DC API. Rather than moving them back under the DC API heading, I scoped the lead-in:

Where the fact that an error response is returned, or the content of that error response, depends on the Wallet's ability to satisfy the request, the narrower a request is, the more information is revealed:

and added a note after the list:

Note that when the Digital Credentials API is used, this can be the case even if the Wallet behaves identically in all cases, as described in (#privacy-dc-api-error).

The bullets themselves are unchanged. Let me know if you'd rather have them back in the DC API subsection.

Also synced the same changes plus your two earlier suggestions into 1.1, which had drifted from 1.0.

brentzundel · 2026-08-06T16:01:05Z

Discussed in DCP WG call. Changes have been made and @jogu needs to re-review.

jogu · 2026-08-10T10:55:12Z

@@ -1143,6 +1143,19 @@ Additional, more complex examples can be found in (#more_dcql_query_examples).

 A VP Token is only returned if the corresponding Authorization Request contained a `dcql_query` parameter or a `scope` parameter representing a DCQL Query (as defined in #vp_token_request).


Unrelated to this PR, but if I raise a separate PR it would conflict - this renders incorrectly (the #vp_token_request doesn't become a link):

Suggested change

A VP Token is only returned if the corresponding Authorization Request contained a `dcql_query` parameter or a `scope` parameter representing a DCQL Query (as defined in #vp_token_request).

A VP Token is only returned if the corresponding Authorization Request contained a `dcql_query` parameter or a `scope` parameter representing a DCQL Query, as defined in (#vp_token_request).

jogu

Looks good to me I think - spotted to unrelated rendering issues that would be good to include.

jogu · 2026-08-10T11:14:33Z

@@ -1139,6 +1139,19 @@ Additional, more complex examples can be found in (#more_dcql_query_examples).

 A VP Token is only returned if the corresponding Authorization Request contained a `dcql_query` parameter or a `scope` parameter representing a DCQL Query (as defined in #vp_token_request).


Same rendering fix for 1.1:

Suggested change

A VP Token is only returned if the corresponding Authorization Request contained a `dcql_query` parameter or a `scope` parameter representing a DCQL Query (as defined in #vp_token_request).

A VP Token is only returned if the corresponding Authorization Request contained a `dcql_query` parameter or a `scope` parameter representing a DCQL Query, as defined in (#vp_token_request).

fkj

Minor editorial suggestions, but otherwise looks fine to me.

fkj · 2026-08-12T11:58:23Z

+
+### Digital Credential API Error Responses {#privacy-dc-api-error}
+
+Returning any OpenID4VP protocol error, regardless of content, can reveal additional information about the End-User’s underlying Credentials or Wallet in a way that is unique to the Digital Credentials API since reaching the Wallet can be dependent on a Wallet's ability to satisfy the request. For example, platform implementations could only allow Wallets to be selected that satisfy the request. In this case, OpenID4VP protocol error responses can only be returned by a selected Wallet and would therefore reveal that the End-User is in possession of Credentials that satisfy the request. This is in contrast to other engagement methods, in which the Wallet receives the request before learning if it can be fulfilled. What is revealed by a Wallet in those cases depends on how each individual Wallet processes the request.


Suggested change

Returning any OpenID4VP protocol error, regardless of content, can reveal additional information about the End-User’s underlying Credentials or Wallet in a way that is unique to the Digital Credentials API since reaching the Wallet can be dependent on a Wallet's ability to satisfy the request. For example, platform implementations could only allow Wallets to be selected that satisfy the request. In this case, OpenID4VP protocol error responses can only be returned by a selected Wallet and would therefore reveal that the End-User is in possession of Credentials that satisfy the request. This is in contrast to other engagement methods, in which the Wallet receives the request before learning if it can be fulfilled. What is revealed by a Wallet in those cases depends on how each individual Wallet processes the request.

Returning any OpenID4VP protocol error, regardless of content, can reveal additional information about the End-User’s underlying Credentials or Wallet in a way that is unique to the Digital Credentials API since reaching the Wallet can be dependent on a Wallet's ability to satisfy the request. For example, platform implementations could allow only Wallets that satisfy the request to be selected. In this case, OpenID4VP protocol error responses can only be returned by a selected Wallet and would therefore reveal that the End-User is in possession of Credentials that satisfy the request. This is in contrast to other engagement methods, in which the Wallet receives the request before learning if it can be fulfilled. What is revealed by a Wallet in those cases depends on how each individual Wallet processes the request.

fkj · 2026-08-12T12:01:27Z

+
+### Digital Credential API Error Responses {#privacy-dc-api-error}
+
+Returning any OpenID4VP protocol error, regardless of content, can reveal additional information about the End-User’s underlying Credentials or Wallet in a way that is unique to the Digital Credentials API since reaching the Wallet can be dependent on a Wallet's ability to satisfy the request. For example, platform implementations could only allow Wallets to be selected that satisfy the request. In this case, OpenID4VP protocol error responses can only be returned by a selected Wallet and would therefore reveal that the End-User is in possession of Credentials that satisfy the request. This is in contrast to other engagement methods, in which the Wallet receives the request before learning if it can be fulfilled. What is revealed by a Wallet in those cases depends on how each individual Wallet processes the request.


Suggested change

Returning any OpenID4VP protocol error, regardless of content, can reveal additional information about the End-User’s underlying Credentials or Wallet in a way that is unique to the Digital Credentials API since reaching the Wallet can be dependent on a Wallet's ability to satisfy the request. For example, platform implementations could only allow Wallets to be selected that satisfy the request. In this case, OpenID4VP protocol error responses can only be returned by a selected Wallet and would therefore reveal that the End-User is in possession of Credentials that satisfy the request. This is in contrast to other engagement methods, in which the Wallet receives the request before learning if it can be fulfilled. What is revealed by a Wallet in those cases depends on how each individual Wallet processes the request.

Returning any OpenID4VP protocol error, regardless of content, can reveal additional information about the End-User’s underlying Credentials or Wallet in a way that is unique to the Digital Credentials API since reaching the Wallet can be dependent on a Wallet's ability to satisfy the request. For example, platform implementations could allow only Wallets that satisfy the request to be selected. In this case, OpenID4VP protocol error responses can only be returned by a selected Wallet and would therefore reveal that the End-User is in possession of Credentials that satisfy the request. This is in contrast to other engagement methods, in which the Wallet receives the request before learning if it can be fulfilled. What is revealed by a Wallet in those cases depends on how each individual Wallet processes the request.

fix: fixes #743

0daaecc

awoie requested review from GarethCOliver, fkj, jogu and paulbastian June 18, 2026 17:23

awoie marked this pull request as draft June 18, 2026 17:31

fkj approved these changes Jun 19, 2026

View reviewed changes

c2bo reviewed Jun 22, 2026

View reviewed changes

Comment thread 1.1/openid-4-verifiable-presentations-1_1.md Outdated

paulbastian reviewed Jun 22, 2026

View reviewed changes

Comment thread 1.1/openid-4-verifiable-presentations-1_1.md

paulbastian reviewed Jul 2, 2026

View reviewed changes

Comment thread 1.1/openid-4-verifiable-presentations-1_1.md

Apply suggestion from @Sakurann

e23168f

Co-authored-by: Kristina <52878547+Sakurann@users.noreply.github.com>

jogu requested changes Jul 2, 2026

View reviewed changes

Comment thread 1.1/openid-4-verifiable-presentations-1_1.md Outdated

Comment thread .DS_Store Outdated

Comment thread 1.1/openid-4-verifiable-presentations-1_1.md Outdated

awoie marked this pull request as ready for review July 9, 2026 10:28

awoie requested review from Sakurann, c2bo, jogu and paulbastian July 9, 2026 10:28

jogu reviewed Jul 16, 2026

View reviewed changes

Comment thread 1.0/openid-4-verifiable-presentations-1_0.md

Merge branch 'main' into awoie/fix-743

c2be122

paulbastian approved these changes Jul 29, 2026

View reviewed changes

fix: add privacy considerations as per josephs suggestion; restructur…

e933282

…ed privacy considerations of dc api, so it applies to regular flow as well Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

jogu reviewed Aug 3, 2026

View reviewed changes

Comment thread 1.0/openid-4-verifiable-presentations-1_0.md Outdated

Comment thread 1.0/openid-4-verifiable-presentations-1_0.md Outdated

Comment thread 1.0/openid-4-verifiable-presentations-1_0.md Outdated

Comment thread 1.0/openid-4-verifiable-presentations-1_0.md Outdated

awoie and others added 4 commits August 6, 2026 15:07

Applied Joseph's suggestion

9545216

Co-authored-by: Joseph Heenan <joseph@authlete.com>

Applied Joseph's suggestion

10b483c

Co-authored-by: Joseph Heenan <joseph@authlete.com>

fix: applied Joseph's suggestions

b786ec9

fix: resolved conflicts

3e85d3f

awoie requested review from brentzundel and jogu August 6, 2026 15:54

marcoscaceres mentioned this pull request Aug 7, 2026

Clarify error case when wallet returns empty vp_token vs error response vs no response #743

Open

jogu mentioned this pull request Aug 10, 2026

what does a claims path pointer error actually mean #778

Open

jogu approved these changes Aug 10, 2026

View reviewed changes

jogu requested a review from fkj August 10, 2026 11:17

jogu approved these changes Aug 10, 2026

View reviewed changes

fkj reviewed Aug 12, 2026

View reviewed changes

		@@ -1143,6 +1143,19 @@ Additional, more complex examples can be found in (#more_dcql_query_examples).

		A VP Token is only returned if the corresponding Authorization Request contained a `dcql_query` parameter or a `scope` parameter representing a DCQL Query (as defined in #vp_token_request).

		@@ -1139,6 +1139,19 @@ Additional, more complex examples can be found in (#more_dcql_query_examples).

		A VP Token is only returned if the corresponding Authorization Request contained a `dcql_query` parameter or a `scope` parameter representing a DCQL Query (as defined in #vp_token_request).


		### Digital Credential API Error Responses {#privacy-dc-api-error}

		Returning any OpenID4VP protocol error, regardless of content, can reveal additional information about the End-User’s underlying Credentials or Wallet in a way that is unique to the Digital Credentials API since reaching the Wallet can be dependent on a Wallet's ability to satisfy the request. For example, platform implementations could only allow Wallets to be selected that satisfy the request. In this case, OpenID4VP protocol error responses can only be returned by a selected Wallet and would therefore reveal that the End-User is in possession of Credentials that satisfy the request. This is in contrast to other engagement methods, in which the Wallet receives the request before learning if it can be fulfilled. What is revealed by a Wallet in those cases depends on how each individual Wallet processes the request.

Uh oh!

Conversation

awoie commented Jun 18, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

awoie commented Jun 18, 2026

Uh oh!

fkj left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Sakurann commented Jul 2, 2026

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

awoie commented Jul 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

brentzundel commented Jul 16, 2026

Uh oh!

brentzundel commented Jul 16, 2026

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

awoie commented Aug 6, 2026

Uh oh!

brentzundel commented Aug 6, 2026

Uh oh!

jogu Aug 10, 2026

Choose a reason for hiding this comment

Uh oh!

jogu left a comment

Choose a reason for hiding this comment

Uh oh!

jogu Aug 10, 2026

Choose a reason for hiding this comment

Uh oh!

fkj left a comment

Choose a reason for hiding this comment

Uh oh!

fkj Aug 12, 2026

Choose a reason for hiding this comment

Uh oh!

fkj Aug 12, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

7 participants

awoie commented Jun 18, 2026 •

edited

Loading

awoie commented Jul 9, 2026 •

edited

Loading