where in the response to include `transaction_data`

[Sakurann]

two options:

1. Current design is to include transaction_data (object or string depending on the outcome of #173) in the presentation, which is credential format specific (ie KB JWT in SD-JWT, session transcript in mdoc, etc).
2. Alternative that has been proposed is to define a new thingy (something like a transaction_data_token) that includes transaction_data and is signed using the key that is used for cryptographic key binding of credential presentation to which this transaction data is bound to.

Option 1 would require each credential format to define how to include transaction data in the response. Option 2 would require defining how to express when multiple transaction data types have been requested to be bound to different credentials(ie use credential A for qes_authorization and credential B for payment_confirmation).

[Sakurann]

had a discussion with QES use-case experts/implementers and there was an interesting input that option 2 might open up a new attack vector where verifier can spoof the binding between transaction data and the credential used to identify the user (assumption is that transaction_data_token in option 2 is bound to nonce and has iat):

1. verifier sends a presentation request with nonceA and requests presentation of QEAA without transaction data
2. verifier sends another presentation request with the same nonceA and requests to bind transaction data to PID
3. verifier can later claim that it is QEAA and not PID that is bound to a specific transaction data because they have the same nonce - different iat values in transaction_data_token might become the only way to detect something is wrong?

maybe not a concern, but thought it is worth raising this.

[awoie]

had a discussion with QES use-case experts/implementers and there was an interesting input that option 2 might open up a new attack vector where verifier can spoof the binding between transaction data and the credential used to identify the user (assumption is that transaction_data_token in option 2 is bound to nonce and has iat):

1. verifier sends a presentation request with nonceA and requests presentation of QEAA without transaction data
2. verifier sends another presentation request with the same nonceA and requests to bind transaction data to PID
3. verifier can later claim that it is QEAA and not PID that is bound to a specific transaction data because they have the same nonce - different iat values in transaction_data_token might become the only way to detect something is wrong?

maybe not a concern, but thought it is worth raising this.

I'm not arguing for option 2 atm, but I was wondering if including a hash of transaction_data in the token would solve the issue?

[cyberphone]

Always including the transaction data in the response should solve the problem as well as eliminating the need to repeat it. An example: https://fido-web-pay.github.io/specification/#seq-4.3

[Sakurann]

after WG discussion leaning towards option 1, some people said they need time to think, will come back to see if there is rough consensus around option 1 later. arguments so far:

• what about credential formats that use ZKP? a separate transaction_data might be limiting in the future? ie binding a ZKP presentation to a transaction_data_token might be challenging? also using the ZKP key to sign transaction_data_token that is very likely to be a JWT would be challenging?
• creating two separate signatures/token using the same public key potentially resulting in extra UX and increase costs if cloud HSM is used, for example.
• what needs to be defined if transaction_data_token is used:
  • it's format (JWT?); how it is signed (if mdoc, cose_key needs to be transformed to jwk?)
  • etc.