Transaction Authorization using Credential Presentations

[tlodderstedt]

In EUDI Wallet context, we frequently hear the requirement to authorize transactions (electronic signatures and payments) with the wallet. At OSW, a couple of us discussed the idea to make that an extension of a credential presentation. The basic idea is to send transaction data with the presentation request, eg the document to be signed, which causes the wallet to show this data to the user and gather consent. If the user consents, the data is added to the signed credential presentation.

[Sakurann]

Here is the first draft of the proposal: https://docs.google.com/document/d/1E_UlB3fh9zbWiPrzFThEnt69hYN60CWk/edit

[selfissued]

How does this relate to the Dynamic Credential Request feature of OpenID4VCI at https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0-13.html#name-dynamic-credential-request ? Both use presentations to authorize actions in progress.

[Sakurann]

in-person WG discussion:

• a lot of interest in using this mechanism for payments too (@Sakurann to add payments example to the proposal gdoc)
• overall no objection to the problem statement
• discussion needed where to put transaction_data in the request when multiple credentials can satisfy the request.

[RByers]

Here's some references for the context I gave in the meeting for why I argued this was potentially extremely important for payments ecosystem:

• With tracking (including fingerprinting) being clamped down on in browsers, payments providers are finding it increasingly difficult to mitigate fraud risk.
• W3C Web Payments Working group has worked for years to try to address this issue with a WebAuthn and Payment Request extension called Secure Payment Confirmation, which has been integrated into the 3D Secure specification.
• Chrome has supported this API and despite experimental results showing 7pp conversion uplift, Chrome has not seen much adoption for two primary reasons:
  • WebAuthn implementations have has been reluctant to provide the device-binding and attestation signals which would be necessary to satisfy regulations like PSD2 SCA (critical in EU)
  • For years Secure Payment Confirmation has been supported only in Chromium-based browsers, with no indication of support from the WebKit engine which is required to be used by all browsers on iOS

It seems inevitable to me that the EUDI infrastructure (including the Digital Credential API) will be used to satisfy this high-importance use case. Adding direct support to OID4VC makes sense to me. Perhaps we can work with the Web Payments Working Group to re-use existing work here, like sharing the data format for transaction details?

[awoie]

in-person WG discussion:

• a lot of interest in using this mechanism for payments too (@Sakurann to add payments example to the proposal gdoc)
• overall no objection to the problem statement
• discussion needed where to put transaction_data in the request when multiple credentials can satisfy the request.

Just to keep in mind that we will probably also need to think about how to feed transaction_data into the verifiable presentations (i.e. KB-JWT, DeviceResponse or SessionTranscript). Should be no problem but we have to define that.

[ianbjacobs]

@RByers thank you for the SPC call-out! See also the draft proposal for a Revised txAuthSimple extension

[hisgarden]

@RByers @ianbjacobs : This is a great collaboration opportunities among OpenID4VP, W3C and FIDO, as FIDO UAF WG has been advocating Transaction Confirmation capabilities on browser, as referenced in this FIDO Transaction Confirmation White Paper, published in Aug 2020: It provides an overview on Transaction Confirmation and the drivers for its support including: regulatory requirements (PSD2, eIDAS); addressing friendly and mobile fraud; and to enable online binding agreements. It explains current approaches for Transaction Confirmation, including through FIDO protocols for native applications, and the value of adding support for it directly in web browsers. It concludes with a call for feedback from relying parties on whether they would like to see Transaction Confirmation should be supported directly in web browsers. The https://github.com/w3c/webauthn/issues/2022 is based on the implementation done on the native mobile app using FIDO Universal Authentication Framework (UAF). For more technical details, please contact Rolf Lindemann @rlin1

[bc-pi]

Consider having the type in this context be more collision resistant or formalized than in RAR.

[selfissued]

I support defining this functionality. I made several suggestions in the document on how to better align the data formats used with other choices made in our protocols.

[Sakurann]

for those with the expertise in payment confirmation use-case, I took a look at secure payment confirmation w3c document and are PaymentCurrencyAmount total/currency and PaymentCredentialInstrument the main two parameters that need to be present in the request? So are there any specific concerns with the following structure of the payment_confirmation type of transaction data (taken from RAR)?:

"instructedAmount": {
      "currency": "EUR",
      "amount": "123.50"
   },
   "creditorName": "Merchant A",
   "creditorAccount": {
      "bic":"ABCIDEFFXXX",
      "iban": "DE02100100109307118603"
   },
   "remittanceInformationUnstructured": "Ref Number Merchant"

[OR13]

Wallet presents encryption keys along with credentials? Verifier processes presentation, and encrypts confidential response details to the wallet, to protect against platform layer attacker?

[Sakurann]

there does not seem to be any objection to pursuing/prioritizing this feature. especially, for payments, this feature is emerging as a very important one.

Few questions that have been emerging:

1. in the request, where to include transaction_data object: a) inside particular input_descriptor, b) inside presentation_definition, c) outside presentation_definition, in the request. b)-c) seems to be preferred for the usecases when the verifier wants to say "user can authenticate using credential A or credential B, and transaction_data should be included in the one that the user chose", because option a) would mean duplicating the same transaction data accross input_descriptors. b)-c) also means including input_descriptor_id or some kind of identifier that points to the input_descriptor that describes the credential used to identify the user. For now, I changed the proposal in google doc to option b)

2. in the response, whether transaction_data should be included in the presentation specific to that credential format (KB JWT for sd-jwt vc, etc.) or a separate token should be defined that is signed using the same user key as the requested credential presentation, but is a separate object.

[selfissued]

I agree that we want to prioritize being able to perform transaction conformations. I have two comments about the mechanisms proposed in the first draft:

1. We are not payment schema experts. Therefore, we should not invent payment schemas and put them into our specification. Rather, we should recommend the use of payment schemas developed by payment experts. Talking to some actual payment experts, they caution me that even if we were to come up with a perfect payment schema today, it would be out of date in a year, as new payment and interchange modalities and regulations unfold. Rather than spending our time inventing a schema, we should spend our time researching and recommending payment schemas that are being actively maintained by experts in that industry.
2. Our specification should use a consistent set of conventions and mechanisms. Those employed by the https://cloudsignatureconsortium.org/wp-content/uploads/2023/04/csc-api-v2.0.0.2.pdf are quite different than those employed by OAuth and OpenID specs. A needless difference, for instance is the use of base64 rather than base64url encoding of data. And the use of OIDs outside of X.509 certificates is also very strange. Let's use consistent conventions in our spec, rather ones borrowed from unaligned specifications.

[Sakurann]

there is a WG consensus to work on the transaction data and prioritize this item, because that transaction data helps multiple use-cases and solves some particular problems.

Closing this issue since agreed to continue brushing up the mechanism in the separate issues: #168, #172, #173 and #174 (and future new ones on this topic)

[cyberphone]

@Sakurann @selfissued There is no need to involve "schemes" in a user authorization request; this part should be handled in the next step based on returned payment method (derived from the selected credential). That is, the wallet does not have to know anything about payment schemes. By deferring "schemes" you also get away from having to specify creditor (merchant) account details in the request which is good since this may also depend on used "scheme". For "inspiration" you may take a peek in: https://www.w3.org/TR/payment-request/ https://cyberphone.github.io/doc/defensive-publications/emv-data-enhancement.pdf

BTW, using the authorization/SCA flow used by Digitallabor (#180, the support for "schemes" is pretty much zero. Personally, I believe this issue is more important than all other issues combined...

[Sakurann]

please continue payment specific discussion in issues dedicated to those (there are multiple)