You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
The text was updated successfully, but these errors were encountered:
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?
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.
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 sametransaction_data_hashes_alg
.Wouldn't it make more sense to make the
transaction_data_hashes
an array of objects, where each entry has ahash
and ahash_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 allowssha-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 entryThe text was updated successfully, but these errors were encountered: