-
Notifications
You must be signed in to change notification settings - Fork 26
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
Comments
To my understanding, the issue mainly proposes the generalization of 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 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 |
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 |
WG discussion
|
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:
transaction_data_hashes_alg
is omitted, do not require a default value ofsha-256
. This enables a credential format to specify hash algorithms.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
The text was updated successfully, but these errors were encountered: