Extend the transaction data hashes response structure

[TimoGlastra]

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]

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]

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]

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.