where `type` values of the transaction data and content specific to that type should be defined

[Sakurann]

related to #156.

1. there have been conflicting comments whether type values should be "open-ended" so that e.g. each open banking jurisdiction for authorization of payments or data sharing and include attributes that are part of the consent grant and are need to be displayed to the end user or "strictly defined".
2. there have been different views whether those type values and the content of the transaction data object should be defined in OpenID4VP spec? in DCP WG? in each industry organization?

[Sakurann]

copying @selfissued 's comment here as the original issue #156 is now pending close

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.

[selfissued]

Here's some examples of payment standards we may want to be able to utilize. They cover both Account-to-Account (A2A) and Card standards, along with local standards:

ISO20022 (A2A), e.g.:

Berlin Group NextGenPSD2 XS2A Framework NextGenPSD2 Framework - Implementation Guidelines (berlin-group.org)

Open Banking UK Specifications - Developer Zone - Confluence (atlassian.net), including FAPI Request 2 Pay UK (Bill Payments)

EMVCo (Cards), e.g.:

3D Secure https://en.wikipedia.org/wiki/3-D_Secure Secure Payments Confirmation (Web Payments) https://w3c.github.io/secure-payment-confirmation/

There are other local standards that will matter in some jurisdictions, e.g.:

UPI (India) https://www.npci.org.in/PDF/npci/upi/Product-Booklet.pdf

[javereec]

I enquired with Steve Pannifer and Neil McEvoy from Consult Hyperion who have a lot of experience in payments industry. Below is the initial feedback that they gave.

---

It is important to distinguish between card payments and A2A payments. They work very differently.

Card payments are “pull” payments. The consumer provides card details to the merchant who then “pulls” the payment from the issuer. Two potential issues with card payments that immediately come to mind:

• PCI: It could bring the wallet into PCI scope (unless PAN tokenisation is done by the wallet)
• SCA: Today SCA is typically done by the issuer (via the 3DS rails). The card payment schemes allow for ‘Delegated Authentication’ to carried out by the merchant where there is an established relationship between the merchant and consumer, and the merchant (via its acquirer) has satisfied the scheme that it has a sufficiently robust authentication process and uses network tokens (i.e. provided by the scheme) to avoid storage of PANs. SCA by the issuer is not required in this case. So this addresses the situation where the merchant is also the wallet issuer and it’s a “Card On File” transaction, but does not address the user wanting to pay with a non-merchant wallet or for one-off payments.

Other things to look at with regard to card payments include:

• ApplePay and GooglePay integration of wallet into ecomm checkouts which are proprietary. They are based on EMV although not exactly.
• EMV SRC (Secure Remote Commerce) although adoption of that has been pretty slow.

A2A payments are “push” payments. The merchant provides their bank details to the consumer, who then instructs their bank to “push” the payment to the merchant’s bank account. This does not seem to fit neatly with idea of wallet presenting payment credentials to a merchant. Perhaps if the wallet doubled up as a PISP in PSD2 terminology (payment initiation service provider) then it could invoke a payment and then present a confirmation credential back to the merchant. This would require the wallet to be certified as a TPP under PSD2. There may be UX issues too. The payment would not really be coming from the wallet – the consumer would need to authenticate to their bank and approve the payment, which potentially could occur in the wallet or out of band.

[cyberphone]

@javereec A properly designed wallet may not necessarily need to bother about "push" or "pull" payments: https://cyberphone.github.io/wallet-core/doc

I'm not alone having this idea: https://www.smartpaymentassociation.com/publications-smart-payment-association/position-papers-smart-payment-association/entry/the-instant-payment-card-initiating-a-sepa-credit-transfer-at-the-point-of-sale