Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Broaden transaction data requirements #423

Open
sander opened this issue Feb 11, 2025 · 4 comments · May be fixed by #421
Open

Broaden transaction data requirements #423

sander opened this issue Feb 11, 2025 · 4 comments · May be fixed by #421
Assignees
Milestone

Comments

@sander
Copy link

sander commented Feb 11, 2025

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
Copy link

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
Copy link
Author

sander commented Feb 20, 2025

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
Copy link

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
Copy link
Collaborator

Sakurann commented Mar 6, 2025

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants