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

Extend the transaction data hashes response structure #443

Open
TimoGlastra opened this issue Mar 4, 2025 · 3 comments
Open

Extend the transaction data hashes response structure #443

TimoGlastra opened this issue Mar 4, 2025 · 3 comments

Comments

@TimoGlastra
Copy link
Member

TimoGlastra commented Mar 4, 2025

The transaction_data_hashes_alg can be separate per transaction_data entry, but in the response it is expected that all transaction data hashes use the same transaction_data_hashes_alg.

Wouldn't it make more sense to make the transaction_data_hashes an array of objects, where each entry has a hash and a hash_alg, so that separate entries can be hashed using different algs?

This could also prevent conflicts where I ask for two transaction data hashes for the same credential id, one that only allows sha-256 and the other that only allows sha-512.

I think it could also help with #442, where the object could contain a transaction_data_index to point to the index from the request to make it easier to link between the request entry and the response entry

@Sakurann
Copy link
Collaborator

Sakurann commented Mar 4, 2025

is there a use-case for multiple transaction data objects that use different hash alg? proposed solution of matching alg to an object sounds like an overcomplication to me without a strong use-case.. I thought majority of use-cases will include only one transaction data object?

@TimoGlastra
Copy link
Member Author

No not really, but in that case I think the supported algs should not be duplicated in every transaction data entry, but rather defined once.

However #423 might have impact on this if custom algs will be used for specific use cases.

@GarethCOliver
Copy link

Agree with @TimoGlastra, either algs should be at the top level in both request or response, or it should be on a per-entry level for request and response. Mixing it is a mistake.

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

No branches or pull requests

3 participants