Broaden transaction data requirements

[sander]

Context: This enables the QES creation use case where transaction data contains parameters for advanced e-signature creation. In these cases, the transaction data do not get hashed in their JSON representation format using a single hash algorithm. Instead, the X.509 credential format specifies specific ways of processing, that still meet the broadened requirements.

Proposed changes:

• When transaction_data_hashes_alg is omitted, do not require a default value of sha-256. This enables a credential format to specify hash algorithms.
• Broaden transaction_data_hashes specification in VP token. This enables advanced e-signature (AdES) processing rather than straight hashing of a serialised JSON array.

Draft PR: #421

[babisRoutis]

To my understanding, the issue mainly proposes the generalization of transaction_data_hashes.
Instead of defining as an array, use the term "representation" of hashes (check the associated PR).

I have the impression that the scope of the PR should be - somehow - be extended to include an explicit description of this representation (of the transaction_data_hashes) for each format of Appendix B.

For instance, for SD-JWT-VC format there could be an explicit description where this representation is defined as an array of base64-encoded hashes (check #418)

The same should be for mso_mdoc and the other formats, I guess, since currently, the spec doesn't provide any hint on how to include holder-signed transaction_data

[sander]

I agree with @babisRoutis the spec should have that explicit description for the credential formats specified in OID4VP. But it seems to be an orthogonal issue #418 (high impact, probably needs sync with the credential format groups) to the current issue (low impact, just enables specifying the new X.509 format elsewhere).

[babisRoutis]

I agree with @babisRoutis the spec should have that explicit description for the credential formats specified in OID4VP. But it seems to be an orthogonal issue #418 (high impact, probably needs sync with the credential format groups) to the current issue (low impact, just enables specifying the new X.509 format elsewhere).

Somehow I missed #330 , which hopefully will address "representation" of holder-signed transaction_data to the DeviceResponse.
Perhaps, this PR has the right scope 😄

[Sakurann]

WG discussion

• suggestion is to make it more flexible to how transaction_data_hashes are included in the response (precedent is nonce and aud in the credential)
• agreement that this change makes sense - next step is to review the PR.