From 0daaeccbc29a9ce417b48e204871da4f0a246bb1 Mon Sep 17 00:00:00 2001 From: Oliver Terbu Date: Thu, 18 Jun 2026 18:20:04 +0100 Subject: [PATCH 1/7] fix: fixes #743 --- .DS_Store | Bin 0 -> 8196 bytes 1.1/openid-4-verifiable-presentations-1_1.md | 26 ++++++++++++++++++- 2 files changed, 25 insertions(+), 1 deletion(-) create mode 100644 .DS_Store diff --git a/.DS_Store b/.DS_Store new file mode 100644 index 0000000000000000000000000000000000000000..feab560ac2801dee5afe3fb1bacfff1789527783 GIT binary patch literal 8196 zcmeHMZEO@p7@l`qU{+kZ{QwFqu=E5$3S3Jo-{#sYgo3oSSLn3`j@`QzR`zzw?cN;% zl^Tta;76j-82tDp@hjn%AD}VOpwS;{3|5Tsk6$q{{xH$_@dJ$S?Cc>NHZjH+8+VeO zcjldWXXbt9d3JB+2qDm(&omKIPY9v-Fey*P>`xMFXU|nh2sD)_0qu!9tXqzbwKMwg zRlP$+7=bVXVFbbmgb@fM@Lz}kezRGk<9zpdYnX=-2qW;ni~xH-sQ54$3*;!5{;LBs z{|JDR9Rd7=WtkOFs)39Ja+FJK!35kCB{zlOhymOj^=i;B7RXU9xjBL0@BzWh5S&oJ zpB=|n{q6)}T!wiVfiMDBM}X0%f;5rkq)9Jcetx%1*NaBagHTa9Y4Q|0g-)fr68oHD z!qdFG+pgt?Sgp@-EWK3L^c|*AOv!a|$M!VSHgdj!nK7`-&VJL*IK_4+Z)aTJHo+UH zNX3*q>+s>`RnbOua=F1^OoirZI+cV4;k*DcCgPl=&>?0Oy?ZS>Tz6?jX03> z#%oFrx=zlE`{Sl$Iqw?11`cZ$j1C;!O`1468?&y=PY_R4)vF7aEMK{LL))e;UA<#+ zbxm#EbV(Y-sM?-+t7+u67tM^fZ$NX?hMh6(z5NB#HFeAAv$d>I4UM8WHf#1AS(&TM zFEy2$P&q=AdEGpaH@(}(YO8BxsX@6;lwYDdGq}KQPKM2t@mrJzWih2gOdrn~m~*wX zR9Pm<8trq@4?aXxY8GWz?Awo!;HIt8Dk^8h?Utq+7FVs6)>C<_*k9n=!Ijgc7!{Lg zC!0klU9O8O8>##*-OVPxS#!PaVZ$yhDXw%!xMybEQsAnb{Gp6U{ zcr+T6TPPi1gSBNcIF3Af&a6bAqTu$JcELpWSVgnO_Myhf0B!8M@p`Z&B(H+OE{vQ^qP5qbA%6=&Lvne_`6 zEseIWxvBjU9yxqVh`pQ%KKQSoj1PVvAmzYCPAYTfN$PfFhjFl+ktL?eQy7CO!>rN} zkyLpS@`qQiUyRks$Q@p7T&AkBfRyFcre;-=E0B;r`;{A)VHJYP+I5m7S0XjVF$G~S z&6CI~)4h+Kq zI0Q%F4mgUSKL*F)es};Lgva0nJONL_QwaIz;CXlfUWAts_Gb|IXW=b)8{UBr;T(*? z$8g>!z_;)N`~tt0LAt99(hTYWqzj3hZ8`Q{)RYKtW#@@mtKiG7XXpQoJOy|N? zhY<)P@RuS0l^uzWcI-Od%Z;72Rebi~!xHN^%B63D*%cQ7Sikg#A(mC_%4}kR9OV)< anEv&P0RJcX-~Zhme*eSozYp9Ap8XDoJAVWK literal 0 HcmV?d00001 diff --git a/1.1/openid-4-verifiable-presentations-1_1.md b/1.1/openid-4-verifiable-presentations-1_1.md index 198af1b2..c977cd96 100644 --- a/1.1/openid-4-verifiable-presentations-1_1.md +++ b/1.1/openid-4-verifiable-presentations-1_1.md @@ -1140,6 +1140,9 @@ 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). +The Wallet MUST return a VP Token only if the set of Presentations represented +by the VP Token satisfies the requirements of the DCQL query according to (#dcql_query_lang_processing_rules). + A VP Token can be returned in the Authorization Response or the Token Response depending on the Response Type used. See (#response_type_vp_token) for more details. If the Response Type value is `vp_token`, the VP Token is returned in the Authorization Response. When the Response Type value is `vp_token id_token` and the `scope` parameter contains `openid`, the VP Token is returned in the Authorization Response alongside a Self-Issued ID Token as defined in [@!SIOPv2]. @@ -1161,8 +1164,27 @@ The behavior with respect to the VP Token is unspecified for any other individua When a VP Token is returned, the respective response includes the following parameters: + `vp_token`: -: REQUIRED. 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 Presentations that match the respective Credential Query. When `multiple` is omitted, or set to `false`, the array MUST contain only one 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 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 Presentations. +: REQUIRED. A JSON-encoded object subject to the following requirements: + + * Each key MUST be the `id` of a Credential Query in the DCQL query. + + * Each value MUST be an array containing one or more Presentations matching + the corresponding Credential Query. + + * When `multiple` is omitted or set to `false`, the array MUST contain exactly + one Presentation. + + * The object MUST NOT contain an entry for an optional Credential Query when + there are no matching Credentials for that Credential Query. + + * Each Presentation MUST be encoded as a string or object according to + (#format_specific_parameters). + + * The object MAY be empty only if the DCQL query can be satisfied without + returning any Presentation according to + (#dcql_query_lang_processing_rules). Other parameters, such as `code` (from [@!RFC6749]), or `id_token` (from [@!OpenID.Core]), and `iss` (from [@RFC9207]) can be included in the response as defined in the respective specifications. @@ -3665,3 +3687,5 @@ The technology described in this specification was made available from contribut * Clarified that Multi-RP-sig section means Verifier Info instead of attestations * Updated origin examples to remove trailing slash * Clarified that request_uri_method is a case-sensitive string + * Clarify that empty objects in VP Tokens cannot be used to signify an error response + * Editorial improvement of the `vp_token` section From e23168f87bd4cf99f5a8d9946a0dbc6626fd3681 Mon Sep 17 00:00:00 2001 From: Oliver Terbu Date: Thu, 2 Jul 2026 17:35:17 +0200 Subject: [PATCH 2/7] Apply suggestion from @Sakurann Co-authored-by: Kristina <52878547+Sakurann@users.noreply.github.com> --- 1.1/openid-4-verifiable-presentations-1_1.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/1.1/openid-4-verifiable-presentations-1_1.md b/1.1/openid-4-verifiable-presentations-1_1.md index c977cd96..3f2e630c 100644 --- a/1.1/openid-4-verifiable-presentations-1_1.md +++ b/1.1/openid-4-verifiable-presentations-1_1.md @@ -1182,7 +1182,7 @@ When a VP Token is returned, the respective response includes the following para * Each Presentation MUST be encoded as a string or object according to (#format_specific_parameters). - * The object MAY be empty only if the DCQL query can be satisfied without + * The object MUST NOT be empty returning any Presentation according to (#dcql_query_lang_processing_rules). From ebb686cd7afef7b3f04674c6cc6a730c01fae0f1 Mon Sep 17 00:00:00 2001 From: Oliver Terbu Date: Thu, 9 Jul 2026 12:27:55 +0200 Subject: [PATCH 3/7] Prohibit empty VP Tokens; require an error response instead 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. --- .DS_Store | Bin 8196 -> 0 bytes .gitignore | 1 + 1.0/openid-4-verifiable-presentations-1_0.md | 33 ++++++++++++++++++- 1.1/openid-4-verifiable-presentations-1_1.md | 21 ++++++++---- 4 files changed, 47 insertions(+), 8 deletions(-) delete mode 100644 .DS_Store diff --git a/.DS_Store b/.DS_Store deleted file mode 100644 index feab560ac2801dee5afe3fb1bacfff1789527783..0000000000000000000000000000000000000000 GIT binary patch literal 0 HcmV?d00001 literal 8196 zcmeHMZEO@p7@l`qU{+kZ{QwFqu=E5$3S3Jo-{#sYgo3oSSLn3`j@`QzR`zzw?cN;% zl^Tta;76j-82tDp@hjn%AD}VOpwS;{3|5Tsk6$q{{xH$_@dJ$S?Cc>NHZjH+8+VeO zcjldWXXbt9d3JB+2qDm(&omKIPY9v-Fey*P>`xMFXU|nh2sD)_0qu!9tXqzbwKMwg zRlP$+7=bVXVFbbmgb@fM@Lz}kezRGk<9zpdYnX=-2qW;ni~xH-sQ54$3*;!5{;LBs z{|JDR9Rd7=WtkOFs)39Ja+FJK!35kCB{zlOhymOj^=i;B7RXU9xjBL0@BzWh5S&oJ zpB=|n{q6)}T!wiVfiMDBM}X0%f;5rkq)9Jcetx%1*NaBagHTa9Y4Q|0g-)fr68oHD z!qdFG+pgt?Sgp@-EWK3L^c|*AOv!a|$M!VSHgdj!nK7`-&VJL*IK_4+Z)aTJHo+UH zNX3*q>+s>`RnbOua=F1^OoirZI+cV4;k*DcCgPl=&>?0Oy?ZS>Tz6?jX03> z#%oFrx=zlE`{Sl$Iqw?11`cZ$j1C;!O`1468?&y=PY_R4)vF7aEMK{LL))e;UA<#+ zbxm#EbV(Y-sM?-+t7+u67tM^fZ$NX?hMh6(z5NB#HFeAAv$d>I4UM8WHf#1AS(&TM zFEy2$P&q=AdEGpaH@(}(YO8BxsX@6;lwYDdGq}KQPKM2t@mrJzWih2gOdrn~m~*wX zR9Pm<8trq@4?aXxY8GWz?Awo!;HIt8Dk^8h?Utq+7FVs6)>C<_*k9n=!Ijgc7!{Lg zC!0klU9O8O8>##*-OVPxS#!PaVZ$yhDXw%!xMybEQsAnb{Gp6U{ zcr+T6TPPi1gSBNcIF3Af&a6bAqTu$JcELpWSVgnO_Myhf0B!8M@p`Z&B(H+OE{vQ^qP5qbA%6=&Lvne_`6 zEseIWxvBjU9yxqVh`pQ%KKQSoj1PVvAmzYCPAYTfN$PfFhjFl+ktL?eQy7CO!>rN} zkyLpS@`qQiUyRks$Q@p7T&AkBfRyFcre;-=E0B;r`;{A)VHJYP+I5m7S0XjVF$G~S z&6CI~)4h+Kq zI0Q%F4mgUSKL*F)es};Lgva0nJONL_QwaIz;CXlfUWAts_Gb|IXW=b)8{UBr;T(*? z$8g>!z_;)N`~tt0LAt99(hTYWqzj3hZ8`Q{)RYKtW#@@mtKiG7XXpQoJOy|N? zhY<)P@RuS0l^uzWcI-Od%Z;72Rebi~!xHN^%B63D*%cQ7Sikg#A(mC_%4}kR9OV)< anEv&P0RJcX-~Zhme*eSozYp9Ap8XDoJAVWK diff --git a/.gitignore b/.gitignore index bf1528da..aedc929f 100644 --- a/.gitignore +++ b/.gitignore @@ -1,3 +1,4 @@ # ignore markdown2rfc output *.html *.xml +.DS_Store diff --git a/1.0/openid-4-verifiable-presentations-1_0.md b/1.0/openid-4-verifiable-presentations-1_0.md index 0b1982e9..a16ba062 100644 --- a/1.0/openid-4-verifiable-presentations-1_0.md +++ b/1.0/openid-4-verifiable-presentations-1_0.md @@ -1144,6 +1144,17 @@ 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). +The Wallet MUST return a VP Token only if the set of Presentations returned in +the VP Token satisfies the requirements of the DCQL query according to +(#dcql_query_lang_processing_rules). If the Wallet does not return any +Presentation, for example, because the End-User did not give consent, the +requested Credentials are not available, or the DCQL query can be satisfied +without returning any Presentation (i.e., all Credential Queries that cannot +be fulfilled are optional), the Wallet MUST NOT return a VP Token; if the +Wallet returns a response, it MUST be an error response as defined in +(#error-response). In particular, an empty VP Token (a JSON object without +any entries) MUST NOT be used to signify an error. + A VP Token can be returned in the Authorization Response or the Token Response depending on the Response Type used. See (#response_type_vp_token) for more details. If the Response Type value is `vp_token`, the VP Token is returned in the Authorization Response. When the Response Type value is `vp_token id_token` and the `scope` parameter contains `openid`, the VP Token is returned in the Authorization Response alongside a Self-Issued ID Token as defined in [@!SIOPv2]. @@ -1166,7 +1177,25 @@ The behavior with respect to the VP Token is unspecified for any other individua When a VP Token is returned, the respective response includes the following parameters: `vp_token`: -: REQUIRED. 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 Presentations that match the respective Credential Query. When `multiple` is omitted, or set to `false`, the array MUST contain only one 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 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 Presentations. +: REQUIRED. A JSON-encoded object subject to the following requirements: + + * Each key MUST be the `id` of a Credential Query in the DCQL query. + + * Each value MUST be an array containing one or more Presentations matching + the corresponding Credential Query. + + * When `multiple` is omitted or set to `false`, the array MUST contain exactly + one Presentation. + + * The object MUST NOT contain an entry for an optional Credential Query when + there are no matching Credentials for that Credential Query. + + * Each Presentation MUST be encoded as a string or object according to + (#format_specific_parameters). + + * The object MUST NOT be empty: it MUST contain at least one entry. If there + is no Presentation to return and the Wallet returns a response, it MUST be + an error response as defined in (#error-response) instead of a VP Token. Other parameters, such as `code` (from [@!RFC6749]), or `id_token` (from [@!OpenID.Core]), and `iss` (from [@RFC9207]) can be included in the response as defined in the respective specifications. @@ -3598,6 +3627,8 @@ The technology described in this specification was made available from contribut * Updated origin examples to remove trailing slash * Clarify that `aud` corresponds to `issuer` Wallet Metadata paremeter if Dynamic Discovery is used * Clarified that request_uri_method is a case-sensitive string + * Clarify that a VP Token cannot be empty and that empty objects in VP Tokens cannot be used to signify an error response; an error response is returned instead + * Editorial improvement of the `vp_token` section -final diff --git a/1.1/openid-4-verifiable-presentations-1_1.md b/1.1/openid-4-verifiable-presentations-1_1.md index 3f2e630c..d2eb1377 100644 --- a/1.1/openid-4-verifiable-presentations-1_1.md +++ b/1.1/openid-4-verifiable-presentations-1_1.md @@ -1140,8 +1140,16 @@ 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). -The Wallet MUST return a VP Token only if the set of Presentations represented -by the VP Token satisfies the requirements of the DCQL query according to (#dcql_query_lang_processing_rules). +The Wallet MUST return a VP Token only if the set of Presentations returned in +the VP Token satisfies the requirements of the DCQL query according to +(#dcql_query_lang_processing_rules). If the Wallet does not return any +Presentation, for example, because the End-User did not give consent, the +requested Credentials are not available, or the DCQL query can be satisfied +without returning any Presentation (i.e., all Credential Queries that cannot +be fulfilled are optional), the Wallet MUST NOT return a VP Token; if the +Wallet returns a response, it MUST be an error response as defined in +(#error-response). In particular, an empty VP Token (a JSON object without +any entries) MUST NOT be used to signify an error. A VP Token can be returned in the Authorization Response or the Token Response depending on the Response Type used. See (#response_type_vp_token) for more details. @@ -1164,7 +1172,6 @@ The behavior with respect to the VP Token is unspecified for any other individua When a VP Token is returned, the respective response includes the following parameters: - `vp_token`: : REQUIRED. A JSON-encoded object subject to the following requirements: @@ -1182,9 +1189,9 @@ When a VP Token is returned, the respective response includes the following para * Each Presentation MUST be encoded as a string or object according to (#format_specific_parameters). - * The object MUST NOT be empty - returning any Presentation according to - (#dcql_query_lang_processing_rules). + * The object MUST NOT be empty: it MUST contain at least one entry. If there + is no Presentation to return and the Wallet returns a response, it MUST be + an error response as defined in (#error-response) instead of a VP Token. Other parameters, such as `code` (from [@!RFC6749]), or `id_token` (from [@!OpenID.Core]), and `iss` (from [@RFC9207]) can be included in the response as defined in the respective specifications. @@ -3687,5 +3694,5 @@ The technology described in this specification was made available from contribut * Clarified that Multi-RP-sig section means Verifier Info instead of attestations * Updated origin examples to remove trailing slash * Clarified that request_uri_method is a case-sensitive string - * Clarify that empty objects in VP Tokens cannot be used to signify an error response + * Clarify that a VP Token cannot be empty and that empty objects in VP Tokens cannot be used to signify an error response; an error response is returned instead * Editorial improvement of the `vp_token` section From e9332821616ba0b86fb9b0ea5c8dbca46e6d287a Mon Sep 17 00:00:00 2001 From: Oliver Terbu Date: Thu, 30 Jul 2026 17:00:36 +0200 Subject: [PATCH 4/7] fix: add privacy considerations as per josephs suggestion; restructured privacy considerations of dc api, so it applies to regular flow as well Co-Authored-By: Claude Opus 5 --- 1.0/openid-4-verifiable-presentations-1_0.md | 25 ++++++++++++-------- 1.1/openid-4-verifiable-presentations-1_1.md | 25 ++++++++++++-------- 2 files changed, 30 insertions(+), 20 deletions(-) diff --git a/1.0/openid-4-verifiable-presentations-1_0.md b/1.0/openid-4-verifiable-presentations-1_0.md index cdade225..a59cc33a 100644 --- a/1.0/openid-4-verifiable-presentations-1_0.md +++ b/1.0/openid-4-verifiable-presentations-1_0.md @@ -1153,7 +1153,9 @@ without returning any Presentation (i.e., all Credential Queries that cannot be fulfilled are optional), the Wallet MUST NOT return a VP Token; if the Wallet returns a response, it MUST be an error response as defined in (#error-response). In particular, an empty VP Token (a JSON object without -any entries) MUST NOT be used to signify an error. +any entries) MUST NOT be used to signify an error. Privacy considerations that +apply when returning an error response, in particular with regard to End-User +consent, are defined in (#privacy-error-responses). A VP Token can be returned in the Authorization Response or the Token Response depending on the Response Type used. See (#response_type_vp_token) for more details. @@ -2059,17 +2061,11 @@ Untrusted or unrecognized Request URI endpoints SHOULD be rejected or require En If the Wallet is acting within a trust framework that allows the Wallet to determine whether a Request URI belongs to a certain Client Identifier, the Wallet is RECOMMENDED to validate the Verifier's authenticity and authorization given by the Client Identifier and that the Request URI corresponds to this Verifier. If the link cannot be established in those cases, the Wallet MUST refuse the request. -## Error Responses +## Error Responses {#privacy-error-responses} Error responses SHOULD avoid including sensitive or detailed contextual information that could be used to infer the End-User's data. -### `wallet_unavailable` Authorization Error Response {#authorization_error_responsewith_the_wallet_unavailable_error_code} - -In the event that another component is invoked instead of the Wallet, the End-User SHOULD be informed and give consent before the invoked component returns the `wallet_unavailable` Authorization Error Response to the Verifier. - -### 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. +The following considerations apply irrespective of the mechanism used to invoke the Wallet, i.e., to both redirect-based flows and the Digital Credentials API. The considerations in the subsections below apply only to the mechanism they refer to. The narrower a request is, the more information is revealed: @@ -2084,6 +2080,14 @@ A Wallet SHOULD NOT return any OpenID4VP protocol errors without End-User intera A Wallet SHOULD NOT return any OpenID4VP protocol errors before obtaining End-User consent, when processing a request containing value matching (to avoid revealing values of claims without consent), or issuer selection (to avoid revealing that the End-User has a Credential from a particular authority). Additionally, the End-User consent protects against undetected, repeated requests to the Wallet. +### `wallet_unavailable` Authorization Error Response {#authorization_error_responsewith_the_wallet_unavailable_error_code} + +In the event that another component is invoked instead of the Wallet, the End-User SHOULD be informed and give consent before the invoked component returns the `wallet_unavailable` Authorization Error Response to the Verifier. + +### 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. + ## Establishing Trust in the Issuers {#privacy_trusted_authorities} This specification introduces an extension point that allows for a Verifier to express expected Issuers or trust frameworks that certify Issuers. It is important to understand the implications of these trust establishment mechanisms on the privacy of the overall system. @@ -2609,7 +2613,7 @@ The following is a non-normative example of the payload of a signed OpenID4VP re Every OpenID4VP Request results in a response being provided through the Digital Credentials API (DC API), or in a canceled flow. If a response is provided, the response is an instance of the `DigitalCredential` interface, as defined in [@!W3C.Digital_Credentials_API], and the OpenID4VP Response parameters as defined for the Response Type are represented as an object within the `data` property. -Protocol error responses are returned as an object within the `data` property. This object has a single property with the name `error` and a value containing the error response code as defined in (#error-response). Note that a protocol error generated by the Wallet will still result in a fulfilled promise for the Digital Credentials API request. Privacy considerations specific to returning error responses over the Digital Credentials API can be found in (#privacy-dc-api-error). +Protocol error responses are returned as an object within the `data` property. This object has a single property with the name `error` and a value containing the error response code as defined in (#error-response). Note that a protocol error generated by the Wallet will still result in a fulfilled promise for the Digital Credentials API request. Privacy considerations that apply to returning error responses can be found in (#privacy-error-responses) and (#privacy-dc-api-error). The following is a non-normative example of a `data` object containing an error: @@ -2639,6 +2643,7 @@ The following privacy considerations from OpenID4VP apply: * Selective Disclosure as described in (#selective-disclosure). * Privacy implications of mechanisms to establish trust in Issuers as described in (#privacy_trusted_authorities). +* Error Responses as described in (#privacy-error-responses) and (#privacy-dc-api-error). # Credential Format Specific Parameters and Rules {#format_specific_parameters} diff --git a/1.1/openid-4-verifiable-presentations-1_1.md b/1.1/openid-4-verifiable-presentations-1_1.md index 6776fd1b..14e5be66 100644 --- a/1.1/openid-4-verifiable-presentations-1_1.md +++ b/1.1/openid-4-verifiable-presentations-1_1.md @@ -1149,7 +1149,9 @@ without returning any Presentation (i.e., all Credential Queries that cannot be fulfilled are optional), the Wallet MUST NOT return a VP Token; if the Wallet returns a response, it MUST be an error response as defined in (#error-response). In particular, an empty VP Token (a JSON object without -any entries) MUST NOT be used to signify an error. +any entries) MUST NOT be used to signify an error. Privacy considerations that +apply when returning an error response, in particular with regard to End-User +consent, are defined in (#privacy-error-responses). A VP Token can be returned in the Authorization Response or the Token Response depending on the Response Type used. See (#response_type_vp_token) for more details. @@ -2131,17 +2133,11 @@ Untrusted or unrecognized Request URI endpoints SHOULD be rejected or require En If the Wallet is acting within a trust framework that allows the Wallet to determine whether a Request URI belongs to a certain Client Identifier, the Wallet is RECOMMENDED to validate the Verifier's authenticity and authorization given by the Client Identifier and that the Request URI corresponds to this Verifier. If the link cannot be established in those cases, the Wallet MUST refuse the request. -## Error Responses +## Error Responses {#privacy-error-responses} Error responses SHOULD avoid including sensitive or detailed contextual information that could be used to infer the End-User's data. -### `wallet_unavailable` Authorization Error Response {#authorization_error_responsewith_the_wallet_unavailable_error_code} - -In the event that another component is invoked instead of the Wallet, the End-User SHOULD be informed and give consent before the invoked component returns the `wallet_unavailable` Authorization Error Response to the Verifier. - -### 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. +The following considerations apply irrespective of the mechanism used to invoke the Wallet, i.e., to both redirect-based flows and the Digital Credentials API. The considerations in the subsections below apply only to the mechanism they refer to. The narrower a request is, the more information is revealed: @@ -2156,6 +2152,14 @@ A Wallet SHOULD NOT return any OpenID4VP protocol errors without End-User intera A Wallet SHOULD NOT return any OpenID4VP protocol errors before obtaining End-User consent, when processing a request containing value matching (to avoid revealing values of claims without consent), or issuer selection (to avoid revealing that the End-User has a Credential from a particular authority). Additionally, the End-User consent protects against undetected, repeated requests to the Wallet. +### `wallet_unavailable` Authorization Error Response {#authorization_error_responsewith_the_wallet_unavailable_error_code} + +In the event that another component is invoked instead of the Wallet, the End-User SHOULD be informed and give consent before the invoked component returns the `wallet_unavailable` Authorization Error Response to the Verifier. + +### 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. + ## Establishing Trust in the Issuers {#privacy_trusted_authorities} This specification introduces an extension point that allows for a Verifier to express expected Issuers or trust frameworks that certify Issuers. It is important to understand the implications of these trust establishment mechanisms on the privacy of the overall system. @@ -2681,7 +2685,7 @@ The following is a non-normative example of the payload of a signed OpenID4VP re Every OpenID4VP Request results in a response being provided through the Digital Credentials API (DC API), or in a canceled flow. If a response is provided, the response is an instance of the `DigitalCredential` interface, as defined in [@!W3C.Digital_Credentials_API], and the OpenID4VP Response parameters as defined for the Response Type are represented as an object within the `data` property. -Protocol error responses are returned as an object within the `data` property. This object has a single property with the name `error` and a value containing the error response code as defined in (#error-response). Note that a protocol error generated by the Wallet will still result in a fulfilled promise for the Digital Credentials API request. Privacy considerations specific to returning error responses over the Digital Credentials API can be found in (#privacy-dc-api-error). +Protocol error responses are returned as an object within the `data` property. This object has a single property with the name `error` and a value containing the error response code as defined in (#error-response). Note that a protocol error generated by the Wallet will still result in a fulfilled promise for the Digital Credentials API request. Privacy considerations that apply to returning error responses can be found in (#privacy-error-responses) and (#privacy-dc-api-error). The following is a non-normative example of a `data` object containing an error: @@ -2712,6 +2716,7 @@ The following privacy considerations from OpenID4VP apply: * Selective Disclosure as described in (#selective-disclosure). * Privacy implications of mechanisms to establish trust in Issuers as described in (#privacy_trusted_authorities). +* Error Responses as described in (#privacy-error-responses) and (#privacy-dc-api-error). # Credential Format Specific Parameters and Rules {#format_specific_parameters} From 9545216bc1f08ebba9a3a92d00d5fe2c8a745b2a Mon Sep 17 00:00:00 2001 From: Oliver Terbu Date: Thu, 6 Aug 2026 15:07:29 +0200 Subject: [PATCH 5/7] Applied Joseph's suggestion Co-authored-by: Joseph Heenan --- 1.0/openid-4-verifiable-presentations-1_0.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/1.0/openid-4-verifiable-presentations-1_0.md b/1.0/openid-4-verifiable-presentations-1_0.md index a59cc33a..961bfc86 100644 --- a/1.0/openid-4-verifiable-presentations-1_0.md +++ b/1.0/openid-4-verifiable-presentations-1_0.md @@ -1186,7 +1186,7 @@ When a VP Token is returned, the respective response includes the following para * Each value MUST be an array containing one or more Presentations matching the corresponding Credential Query. - * When `multiple` is omitted or set to `false`, the array MUST contain exactly + * When `multiple` was omitted in the DCQL query or set to `false`, the array MUST contain exactly one Presentation. * The object MUST NOT contain an entry for an optional Credential Query when From 10b483cef864e6d43627b02647a1ffdffeffdd07 Mon Sep 17 00:00:00 2001 From: Oliver Terbu Date: Thu, 6 Aug 2026 15:08:05 +0200 Subject: [PATCH 6/7] Applied Joseph's suggestion Co-authored-by: Joseph Heenan --- 1.0/openid-4-verifiable-presentations-1_0.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/1.0/openid-4-verifiable-presentations-1_0.md b/1.0/openid-4-verifiable-presentations-1_0.md index 961bfc86..cf578405 100644 --- a/1.0/openid-4-verifiable-presentations-1_0.md +++ b/1.0/openid-4-verifiable-presentations-1_0.md @@ -1144,8 +1144,8 @@ 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). -The Wallet MUST return a VP Token only if the set of Presentations returned in -the VP Token satisfies the requirements of the DCQL query according to +The Wallet MUST return a VP Token only if it contains a set of + Presentations that satisfy the requirements of the DCQL query according to (#dcql_query_lang_processing_rules). If the Wallet does not return any Presentation, for example, because the End-User did not give consent, the requested Credentials are not available, or the DCQL query can be satisfied From b786ec9b8891524bc019f4e8a33f8437e7558cff Mon Sep 17 00:00:00 2001 From: Oliver Terbu Date: Thu, 6 Aug 2026 15:34:25 +0200 Subject: [PATCH 7/7] fix: applied Joseph's suggestions --- 1.0/openid-4-verifiable-presentations-1_0.md | 12 +++++++----- 1.1/openid-4-verifiable-presentations-1_1.md | 18 ++++++++++-------- 2 files changed, 17 insertions(+), 13 deletions(-) diff --git a/1.0/openid-4-verifiable-presentations-1_0.md b/1.0/openid-4-verifiable-presentations-1_0.md index cf578405..f858a770 100644 --- a/1.0/openid-4-verifiable-presentations-1_0.md +++ b/1.0/openid-4-verifiable-presentations-1_0.md @@ -1155,7 +1155,7 @@ Wallet returns a response, it MUST be an error response as defined in (#error-response). In particular, an empty VP Token (a JSON object without any entries) MUST NOT be used to signify an error. Privacy considerations that apply when returning an error response, in particular with regard to End-User -consent, are defined in (#privacy-error-responses). +consent, are defined in (#error-responses). A VP Token can be returned in the Authorization Response or the Token Response depending on the Response Type used. See (#response_type_vp_token) for more details. @@ -2061,19 +2061,21 @@ Untrusted or unrecognized Request URI endpoints SHOULD be rejected or require En If the Wallet is acting within a trust framework that allows the Wallet to determine whether a Request URI belongs to a certain Client Identifier, the Wallet is RECOMMENDED to validate the Verifier's authenticity and authorization given by the Client Identifier and that the Request URI corresponds to this Verifier. If the link cannot be established in those cases, the Wallet MUST refuse the request. -## Error Responses {#privacy-error-responses} +## Error Responses Error responses SHOULD avoid including sensitive or detailed contextual information that could be used to infer the End-User's data. The following considerations apply irrespective of the mechanism used to invoke the Wallet, i.e., to both redirect-based flows and the Digital Credentials API. The considerations in the subsections below apply only to the mechanism they refer to. -The narrower a request is, the more information is revealed: +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: * A request that can be fulfilled by a broad range of documents will only reveal that the End-User has a Credential from a large set of documents. * A request for a single document type will reveal the End-User is in possession of that Credential. How sensitive this is would depend on the particular Credential. * A request with which can only be satisfied by a single trusted authority will reveal that the End-User has a Credential from a particular authority, from which other attributes may be inferred. * A request with value matching (as defined in (#selecting_claims)) will reveal the specific value of that claim/attribute. +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). + Wallet implementations need to balance the value of error detection to the maintenance and scaling of the Verifier ecosystem with the information that is revealed. A Wallet SHOULD NOT return any OpenID4VP protocol errors without End-User interaction either with the platform or the Wallet. When handling errors, implementations can opt to cancel the flow (the details of which are platform specific) rather than return an OpenID4VP protocol-specific error. This will make the result indistinguishable from other platform aborts, preventing any information from being revealed. @@ -2613,7 +2615,7 @@ The following is a non-normative example of the payload of a signed OpenID4VP re Every OpenID4VP Request results in a response being provided through the Digital Credentials API (DC API), or in a canceled flow. If a response is provided, the response is an instance of the `DigitalCredential` interface, as defined in [@!W3C.Digital_Credentials_API], and the OpenID4VP Response parameters as defined for the Response Type are represented as an object within the `data` property. -Protocol error responses are returned as an object within the `data` property. This object has a single property with the name `error` and a value containing the error response code as defined in (#error-response). Note that a protocol error generated by the Wallet will still result in a fulfilled promise for the Digital Credentials API request. Privacy considerations that apply to returning error responses can be found in (#privacy-error-responses) and (#privacy-dc-api-error). +Protocol error responses are returned as an object within the `data` property. This object has a single property with the name `error` and a value containing the error response code as defined in (#error-response). Note that a protocol error generated by the Wallet will still result in a fulfilled promise for the Digital Credentials API request. Privacy considerations that apply to returning error responses can be found in (#error-responses) and (#privacy-dc-api-error). The following is a non-normative example of a `data` object containing an error: @@ -2643,7 +2645,7 @@ The following privacy considerations from OpenID4VP apply: * Selective Disclosure as described in (#selective-disclosure). * Privacy implications of mechanisms to establish trust in Issuers as described in (#privacy_trusted_authorities). -* Error Responses as described in (#privacy-error-responses) and (#privacy-dc-api-error). +* Error Responses as described in (#error-responses) and (#privacy-dc-api-error). # Credential Format Specific Parameters and Rules {#format_specific_parameters} diff --git a/1.1/openid-4-verifiable-presentations-1_1.md b/1.1/openid-4-verifiable-presentations-1_1.md index 14e5be66..b0024844 100644 --- a/1.1/openid-4-verifiable-presentations-1_1.md +++ b/1.1/openid-4-verifiable-presentations-1_1.md @@ -1140,8 +1140,8 @@ 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). -The Wallet MUST return a VP Token only if the set of Presentations returned in -the VP Token satisfies the requirements of the DCQL query according to +The Wallet MUST return a VP Token only if it contains a set of + Presentations that satisfy the requirements of the DCQL query according to (#dcql_query_lang_processing_rules). If the Wallet does not return any Presentation, for example, because the End-User did not give consent, the requested Credentials are not available, or the DCQL query can be satisfied @@ -1151,7 +1151,7 @@ Wallet returns a response, it MUST be an error response as defined in (#error-response). In particular, an empty VP Token (a JSON object without any entries) MUST NOT be used to signify an error. Privacy considerations that apply when returning an error response, in particular with regard to End-User -consent, are defined in (#privacy-error-responses). +consent, are defined in (#error-responses). A VP Token can be returned in the Authorization Response or the Token Response depending on the Response Type used. See (#response_type_vp_token) for more details. @@ -1182,7 +1182,7 @@ When a VP Token is returned, the respective response includes the following para * Each value MUST be an array containing one or more Presentations matching the corresponding Credential Query. - * When `multiple` is omitted or set to `false`, the array MUST contain exactly + * When `multiple` was omitted in the DCQL query or set to `false`, the array MUST contain exactly one Presentation. * The object MUST NOT contain an entry for an optional Credential Query when @@ -2133,19 +2133,21 @@ Untrusted or unrecognized Request URI endpoints SHOULD be rejected or require En If the Wallet is acting within a trust framework that allows the Wallet to determine whether a Request URI belongs to a certain Client Identifier, the Wallet is RECOMMENDED to validate the Verifier's authenticity and authorization given by the Client Identifier and that the Request URI corresponds to this Verifier. If the link cannot be established in those cases, the Wallet MUST refuse the request. -## Error Responses {#privacy-error-responses} +## Error Responses Error responses SHOULD avoid including sensitive or detailed contextual information that could be used to infer the End-User's data. The following considerations apply irrespective of the mechanism used to invoke the Wallet, i.e., to both redirect-based flows and the Digital Credentials API. The considerations in the subsections below apply only to the mechanism they refer to. -The narrower a request is, the more information is revealed: +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: * A request that can be fulfilled by a broad range of documents will only reveal that the End-User has a Credential from a large set of documents. * A request for a single document type will reveal the End-User is in possession of that Credential. How sensitive this is would depend on the particular Credential. * A request with which can only be satisfied by a single trusted authority will reveal that the End-User has a Credential from a particular authority, from which other attributes may be inferred. * A request with value matching (as defined in (#selecting_claims)) will reveal the specific value of that claim/attribute. +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). + Wallet implementations need to balance the value of error detection to the maintenance and scaling of the Verifier ecosystem with the information that is revealed. A Wallet SHOULD NOT return any OpenID4VP protocol errors without End-User interaction either with the platform or the Wallet. When handling errors, implementations can opt to cancel the flow (the details of which are platform specific) rather than return an OpenID4VP protocol-specific error. This will make the result indistinguishable from other platform aborts, preventing any information from being revealed. @@ -2685,7 +2687,7 @@ The following is a non-normative example of the payload of a signed OpenID4VP re Every OpenID4VP Request results in a response being provided through the Digital Credentials API (DC API), or in a canceled flow. If a response is provided, the response is an instance of the `DigitalCredential` interface, as defined in [@!W3C.Digital_Credentials_API], and the OpenID4VP Response parameters as defined for the Response Type are represented as an object within the `data` property. -Protocol error responses are returned as an object within the `data` property. This object has a single property with the name `error` and a value containing the error response code as defined in (#error-response). Note that a protocol error generated by the Wallet will still result in a fulfilled promise for the Digital Credentials API request. Privacy considerations that apply to returning error responses can be found in (#privacy-error-responses) and (#privacy-dc-api-error). +Protocol error responses are returned as an object within the `data` property. This object has a single property with the name `error` and a value containing the error response code as defined in (#error-response). Note that a protocol error generated by the Wallet will still result in a fulfilled promise for the Digital Credentials API request. Privacy considerations that apply to returning error responses can be found in (#error-responses) and (#privacy-dc-api-error). The following is a non-normative example of a `data` object containing an error: @@ -2716,7 +2718,7 @@ The following privacy considerations from OpenID4VP apply: * Selective Disclosure as described in (#selective-disclosure). * Privacy implications of mechanisms to establish trust in Issuers as described in (#privacy_trusted_authorities). -* Error Responses as described in (#privacy-error-responses) and (#privacy-dc-api-error). +* Error Responses as described in (#error-responses) and (#privacy-dc-api-error). # Credential Format Specific Parameters and Rules {#format_specific_parameters}