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
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
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:
Some points of discussion: