How to encode transaction_data in the presentation request

[Sakurann]

(opening a new issue that emerged as part of the discussion of #172)

it has been brought up that encoding of transaction_data needs to be designed so that it helps the verifier to check that transaction data that the wallet includes in the response has not been modified. There seems to be multiple options:

1. (current design) transaction_data is array of objects in the request and the response. the verifier needs to check if the transaction_data object(s) in the response have not been modified, which is not exactly the simplest.
2. transaction_data is array of strings in the request, where each string is a base64url encoded object of a distinct transaction data type. the response has two options:
   a. wallet includes the exact same string (base64url encoded object) in the response
   b. wallet includes the hash of the base64url encoded string in the response (need to understand what would be the value of hashing)
3. transaction_data is array of objects in the request, where each object contains type value, and a string that is a base64url encoded typed object. during the WG call, there have already been a concern raised that mixing up encoded and non-encoded parameters is not clean/complicates processing.
4. transaction_data itself is a string that is a base64url encoded array of multiple objects with different transaction data types. This probably prevents the use-case when the verifier is passing multiple transaction data types and is asking to bind each of them to different credentials (ie use credential A for qes_authorization and credential B for payment_confirmation). probably same option to hash or not as in 2a and 2b:
   a. string in the response
   b. hash in the response

[Sakurann]

Had a discussion with the implementers/experts of QES use-case on this topic and there was a strong support towards option 2 as it makes it easier for the verifier to ensure it is receiving in the response what it has sent in the request (better than option 1), allows to include different transaction types in different presentations in the response which is useful since different transaction data types have different legal requirements in terms of how long to store the credential with transaction data (better than option 4), and is easier to process than option 3, because for example it does not introduce error condition when the type value in the decoded object does not match the type passed outside an encoded string, etc.

[yaromin]

I'd vote for 2b. Why do we need base64 in this case?

[Sakurann]

WG discussion:

• first agreed that it should be option 2a or 2b.
• rough consensus around option 2b. the benefit of a hashing being reducing the amount of decodable information leaking and potentially large size of the string (hashing over the base64url encoded string to normalize possible variations when hashing over the object)