Repository navigation
Relax transaction data - #808
Open
GarethCOliver wants to merge 2 commits into
Open
GarethCOliver wants to merge 2 commits into
GarethCOliver wants to merge 2 commits into
Conversation
Instead of rejecting the whole request when any transaction_data object has an unrecognized/unsupported type or does not conform to its type definition, the Wallet treats the Credential Queries referenced by such an object as unsatisfiable and otherwise ignores it. The request only fails if the DCQL query can no longer be satisfied as a result. This allows a Verifier to offer alternative transaction data types (e.g. different versions, or ecosystem-specific types) in a single request, each bound to its own Credential Query, combined with credential_sets. - Move the normative rule out of the parameter definition into a new 'Processing Rules' subsection of the Transaction Data section - Add a cross-reference in the DCQL 'Selecting Credentials' rules - Scope the invalid_transaction_data error conditions accordingly - Align the mdoc KeyAuthorizations text with the new behaviour - Drop the single-credential MUST from the credential_ids definition - Add an illustrative example (transaction_data_alternatives.json) - Add Document History entry
Removed example from transaction_data handling clarification.
jogu
reviewed
Oct 23, 2026
jogu
left a comment
jogu
left a comment
Collaborator
There was a problem hiding this comment.
Generally looks good to me, and I see why you described it as clunky now. (And I don't see how we can make it less clunky without a breaking change.)
A few nits, but there's two parts I'm not clear on the expected behaviour.
I think we should apply to 1.0 too, but that can wait until the wording is finalised.
| } | ||
| ``` | ||
|
|
||
| A Wallet that supports `payment_v2` but not `payment_v1` ignores the first `transaction_data` object, treats `payment_card_v1` as unsatisfiable, and returns a Presentation for `payment_card_v2` including the `payment_v2` transaction data. A Wallet that supports neither type cannot satisfy the Credential Set Query and rejects the request. |
Collaborator
There was a problem hiding this comment.
It's probably not particularly important, but we did try to tighten up 'rejects the request' style wording elsewhere to be specific:
Suggested change
| A Wallet that supports `payment_v2` but not `payment_v1` ignores the first `transaction_data` object, treats `payment_card_v1` as unsatisfiable, and returns a Presentation for `payment_card_v2` including the `payment_v2` transaction data. A Wallet that supports neither type cannot satisfy the Credential Set Query and rejects the request. | |
| A Wallet that supports `payment_v2` but not `payment_v1` ignores the first `transaction_data` object, treats `payment_card_v1` as unsatisfiable, and returns a Presentation for `payment_card_v2` including the `payment_v2` transaction data. A Wallet that supports neither type cannot satisfy the Credential Set Query, so it does not return a VP Token and any response it returns is an `invalid_transaction_data` error response, as described above. |
|
|
||
| ### Processing Rules {#transaction_data_processing} | ||
|
|
||
| A Wallet is not required to recognize or support every transaction data type. A `transaction_data` object is unprocessable by a Wallet if it contains a transaction data type that the Wallet does not recognize or support, or if it does not conform to the definition of its transaction data type. Note that the same object can be unprocessable by one Wallet and processable by another. The Wallet MUST handle an unprocessable `transaction_data` object as follows: |
Collaborator
There was a problem hiding this comment.
A transaction data that has a value in credential_ids that isn't actually in the DCQL query is technically undefined now (the language allows ignoring it and proceeding or returning an error). Probably it's best for interoperability if the behaviour is clear:
Suggested change
| A Wallet is not required to recognize or support every transaction data type. A `transaction_data` object is unprocessable by a Wallet if it contains a transaction data type that the Wallet does not recognize or support, or if it does not conform to the definition of its transaction data type. Note that the same object can be unprocessable by one Wallet and processable by another. The Wallet MUST handle an unprocessable `transaction_data` object as follows: | |
| A Wallet is not required to recognize or support every transaction data type. A `transaction_data` object is unprocessable by a Wallet if it contains a transaction data type that the Wallet does not recognize or support, or if it does not conform to the definition of its transaction data type. Note that the same object can be unprocessable by one Wallet and processable by another. A `transaction_data` object whose `credential_ids` contains a value that does not match the `id` of any Credential Query in the request MUST be rejected as described in (#error-response). The Wallet MUST handle an unprocessable `transaction_data` object as follows: |
| It is RECOMMENDED that each transaction data type defines a data element (`NameSpace`, `DataElementIdentifier`, `DataElementValue`) to be used to return the processed transaction data. Additionally, it is RECOMMENDED that it specifies the processing rules, potentially including any hash function to be applied, and the expected resulting structure. | ||
|
|
||
| Some document types support some transaction data ((#transaction_data)) to be protected using mdoc authentication, as part of the `DeviceSigned` data structure [@ISO.18013-5]. In those cases, the specifications of these document types include which transaction data types are supported, and the issuer includes the relevant data elements in the `KeyAuthorizations`. If a Wallet receives a request with a `transaction_data` type whose data element is unauthorized, the Wallet MUST reject the request due to an unsupported transaction data type. | ||
| Some document types support some transaction data ((#transaction_data)) to be protected using mdoc authentication, as part of the `DeviceSigned` data structure [@ISO.18013-5]. In those cases, the specifications of these document types include which transaction data types are supported, and the issuer includes the relevant data elements in the `KeyAuthorizations`. If a Wallet receives a request with a `transaction_data` type whose data element is unauthorized for a Credential, the Wallet MUST treat that `transaction_data` object as unsupported for that Credential and MUST NOT return the Credential for the referenced Credential Query, following the rules in (#transaction_data_processing). |
Collaborator
There was a problem hiding this comment.
This might be slightly clearer/more consistent, though I can live with the current text too:
Suggested change
| Some document types support some transaction data ((#transaction_data)) to be protected using mdoc authentication, as part of the `DeviceSigned` data structure [@ISO.18013-5]. In those cases, the specifications of these document types include which transaction data types are supported, and the issuer includes the relevant data elements in the `KeyAuthorizations`. If a Wallet receives a request with a `transaction_data` type whose data element is unauthorized for a Credential, the Wallet MUST treat that `transaction_data` object as unsupported for that Credential and MUST NOT return the Credential for the referenced Credential Query, following the rules in (#transaction_data_processing). | |
| Some document types support some transaction data ((#transaction_data)) to be protected using mdoc authentication, as part of the `DeviceSigned` data structure [@ISO.18013-5]. In those cases, the specifications of these document types include which transaction data types are supported, and the issuer includes the relevant data elements in the `KeyAuthorizations`. If a Wallet receives a request with a `transaction_data` type whose data element is unauthorized for a Credential, the Wallet MUST NOT use that Credential to satisfy the referenced Credential Queries, i.e., the Credential is treated as if it did not match them. |
| - The Wallet MUST otherwise ignore the unprocessable object. The presence of an unprocessable `transaction_data` object MUST NOT, by itself, cause the Wallet to reject the request if the DCQL query can still be satisfied without the Credential Queries referenced by that object. | ||
| - If, as a consequence of the rules above, the DCQL query cannot be satisfied, the Wallet MUST NOT return a VP Token, and any response returned SHOULD be an error response using the error code `invalid_transaction_data` (see (#error-response)). | ||
|
|
||
| These rules allow a Verifier to include, in a single request, alternative `transaction_data` objects that each reference a different Credential Query, for example, different versions of a transaction data type, or transaction data types specific to different ecosystems, and to use `credential_sets` to express that returning any one of the referenced Credentials is sufficient. A Wallet can then authorize the transaction using a Credential whose associated transaction data type it supports, while ignoring the other alternatives rather than rejecting the whole request. |
Collaborator
There was a problem hiding this comment.
This might be slightly easier to read, though I can live with the current wording:
Suggested change
| These rules allow a Verifier to include, in a single request, alternative `transaction_data` objects that each reference a different Credential Query, for example, different versions of a transaction data type, or transaction data types specific to different ecosystems, and to use `credential_sets` to express that returning any one of the referenced Credentials is sufficient. A Wallet can then authorize the transaction using a Credential whose associated transaction data type it supports, while ignoring the other alternatives rather than rejecting the whole request. | |
| These rules allow a Verifier to include alternative `transaction_data` objects in a single request, each referencing a different Credential Query. The alternatives can be, for example, different versions of a transaction data type, or transaction data types specific to different ecosystems. The Verifier uses `credential_sets` to express that returning any one of the referenced Credentials is sufficient. A Wallet can then authorize the transaction using a Credential whose associated transaction data type it supports, ignoring the other alternatives rather than rejecting the whole request. |
|
|
||
| * `type`: REQUIRED. String that identifies the type of transaction data. This value determines parameters that can be included in the `transaction_data` object. The specific values are out of scope for this specification. It is RECOMMENDED to use collision-resistant names for `type` values. | ||
| * `credential_ids`: REQUIRED. Non-empty array of strings each referencing a Credential requested by the Verifier that can be used to authorize this transaction. The string matches the `id` field in the DCQL Credential Query. If there is more than one element in the array, the Wallet MUST use only one of the referenced Credentials for transaction authorization. | ||
| * `credential_ids`: REQUIRED. Non-empty array of strings each referencing a Credential requested by the Verifier that can be used to authorize this transaction. The string matches the `id` field in the DCQL Credential Query. |
Collaborator
There was a problem hiding this comment.
I'm confused by the removal of:
If there is more than one element in the array, the Wallet MUST use only one of the referenced Credentials for transaction authorization.
I can't see anywhere else where we define what to do if there's more than one element?
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.
Resolves #794
This relaxes transaction data so that an 'unprocessable' transaction_data merely makes associated Credential Queries unsatisfiable rather than requiring the whole request to be failed.
As part of this, removed the weird MUST requirement of 'exactly one credential from credential ids' text, as Credential Queries are now (correctly) the way to enforce that.