Transaction Data

OpenID4VP has a feature for 'TransactionData'. 18013-5 has an implicit mechanism for doing this with RequestInfo.

This feature allows the Verifier to provide an additional payload which

• Instructs the Wallet as to what needs to be done to get consent from the user
• Includes the hash of the payload in the cryptographic proof (kb-jwt/device-signed) in the response to provide proof that the user did consent to this.

The canonical use case is Payments, which a Payment Context is provided with the details of the transaction. The Wallet is responsible for rending them, and returning the hash signed by a DPC. Other use cases are digital signatures of documents and delegation. This is used for strong customer authentication to authorize a purchase.

The feature needs to:

• Specify which credentials are valid to use with the transaction_data
• Be (optionally) combined with the presentation of other credentials
• Be extensible to different transaction types (based on use case)

Some points of discussion:

• responsibilities of the TransactionData type designed, Credential designed and this protocol about how it's used/included
• how to ensure failure and interaction with query language

Start by reviewing the OpenID4VP TransactionData feature and the ISO/IEC 18013-5 RequestInfo mechanism described in the issue. Map the responsibilities for the TransactionData type, credential selection, consent, cryptographic proof, extensibility, failure handling, and query-language interaction; done means these protocol questions have a decided specification.