Conversation
The spec used "terminate", "reject", and "return an error" without defining how they differ, and stated the unsupported transaction_data requirement twice in different words (sections 5.8 and 8.4). - Define that terminating request processing means no response is returned to the Verifier, as no authentic request (and hence no trusted response endpoint) was obtained. - Harmonize the unsupported transaction_data wording: section 5 now defers to the Transaction Data section, which specifies that the Wallet must not return a VP Token and that any response returned is an invalid_transaction_data error response. Aborting without a response remains possible per the privacy considerations, resolving the tension between the previous unconditional "MUST return an error" and the SHOULD NOT in the Error Responses privacy section. - List the unsupported parameter case under invalid_transaction_data. Fixes #454 Fixes #757
jogu
changed the title
jogu
added a commit
to openid-certification/conformance-suite
that referenced
this pull request
Sep 7, 2026
OID4VP 1.0 §8.5 defines invalid_transaction_data for transaction_data entries with an unknown or unsupported type; openid/OpenID4VP#790 clarifies in §8.4 that any response a wallet returns in that situation must use this error code. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_013nrt5DAzUoNbJ7eVVqbDz8
jogu
added a commit
to openid-certification/conformance-suite
that referenced
this pull request
Sep 7, 2026
…transaction_data test The request in this test is authentic (validly signed, correct client_id), so a wallet has a trusted response endpoint and per OID4VP 1.0 §8.4 (as clarified by openid/OpenID4VP#790) may return an invalid_transaction_data error response — over direct post or as a fulfilled Digital Credentials API response — instead of aborting without responding. Previously any direct post call failed the test before the body was parsed, and any fulfilled DC API response failed even when it carried the spec-mandated protocol error. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_013nrt5DAzUoNbJ7eVVqbDz8 Closes #1969
jogu
added a commit
to openid-certification/conformance-suite
that referenced
this pull request
Sep 8, 2026
OID4VP 1.0 §8.5 defines invalid_transaction_data for transaction_data entries with an unknown or unsupported type; openid/OpenID4VP#790 clarifies in §8.4 that any response a wallet returns in that situation must use this error code. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_013nrt5DAzUoNbJ7eVVqbDz8
jogu
added a commit
to openid-certification/conformance-suite
that referenced
this pull request
Sep 8, 2026
…transaction_data test The request in this test is authentic (validly signed, correct client_id), so a wallet has a trusted response endpoint and per OID4VP 1.0 §8.4 (as clarified by openid/OpenID4VP#790) may return an invalid_transaction_data error response — over direct post or as a fulfilled Digital Credentials API response — instead of aborting without responding. Previously any direct post call failed the test before the body was parsed, and any fulfilled DC API response failed even when it carried the spec-mandated protocol error. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_013nrt5DAzUoNbJ7eVVqbDz8 Closes #1969
javereec
reviewed
Sep 10, 2026
javereec
left a comment
javereec
left a comment
Contributor
There was a problem hiding this comment.
Looks good, just one small suggestion.
Collaborator
|
discussed today: needs review. |
jogu
commented
Sep 10, 2026
Co-authored-by: Joseph Heenan <joseph@heenan.me.uk>
fkj
reviewed
Sep 16, 2026
fkj
left a comment
fkj
left a comment
Member
There was a problem hiding this comment.
Looks fine except it plays a little loose with normative wording. My suggestions should obviously also be fixed in the errata if they are accepted.
Collaborator
|
Discussed today. @jogu will respond too @fkj , @fkj will then re-view. @c2bo and @GarethCOliver and Jim Richards will review |
Co-authored-by: Frederik Krogsdal Jacobsen <fkj@users.noreply.github.com>
Collaborator
|
Discussed in call. Ready for review from @c2bo @fkj @GarethCOliver |
fkj
approved these changes
Sep 25, 2026
javereec
approved these changes
Sep 28, 2026
c2bo
approved these changes
Sep 28, 2026
| The Wallet that received the `transaction_data` parameter in the request MUST include a representation or reference to the data in the respective Credential presentation. How this is done is transaction data type specific. Credential Formats can give recommendations of how to handle transaction data, such as those in (#format_specific_parameters). | ||
|
|
||
| If the Wallet does not support `transaction_data` parameter, it MUST return an error upon receiving a request that includes it. | ||
| If the Wallet does not support the `transaction_data` parameter, it MUST reject a request that includes it: the Wallet MUST NOT return a VP Token for such a request, and any response returned MUST be an error response using the error code `invalid_transaction_data` (see (#error-response)). As described in (#error-responses), the Wallet MAY instead cancel the flow without returning a response to the Verifier. |
Member
There was a problem hiding this comment.
Do we want the MUST here for the error type? I guess we can always not return anything, but I am wondering if we absolutely want to restrict the error type here.
Member
There was a problem hiding this comment.
Alternative:
Suggested change
| If the Wallet does not support the `transaction_data` parameter, it MUST reject a request that includes it: the Wallet MUST NOT return a VP Token for such a request, and any response returned MUST be an error response using the error code `invalid_transaction_data` (see (#error-response)). As described in (#error-responses), the Wallet MAY instead cancel the flow without returning a response to the Verifier. | |
| If the Wallet does not support the `transaction_data` parameter, it MUST reject a request that includes it: the Wallet MUST NOT return a VP Token for such a request, and any response returned SHOULD be an error response using the error code `invalid_transaction_data` (see (#error-response)). As described in (#error-responses), the Wallet MAY instead cancel the flow without returning a response to the Verifier. |
Collaborator
|
Discusssed in group call. MUST should be a SHOULD as here: #790 (comment) |
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The spec used "terminate", "reject", and "return an error" without defining how they differ, and stated the unsupported transaction_data requirement twice in different words (sections 5.8 and 8.4).
Fixes #454
Fixes #757
Fixes #795