Make "payment-authorization" a separate super project

[cyberphone]

Mixing identity-related applications and payment authorization will make specifications unnecessary complex. These topics also have quite different champions.

A separate payment-authorization project would act as a placeholder for all OpenID related standards when used for payment authorizations. Associated documents would presumably be highly profiled. Extensive amounts of examples would also be needed. Putting such in OpenID core documents would only contribute to "pollution".

If we consider implementations, it seems very unrealistic to have a single wallet application that handles everything from selective disclosures to payment authorizations. It would be a "frankenwallet".

Major, not yet addressed features, such as e-receipts (https://cyberphone.github.io/doc/defensive-publications/e-receipts.pdf) would take too much bandwidth from the identity core. It would preferably be a sub-project under payment-authorization.

An account balance lookup option would affect credential provisioning, etc. Apple Pay already have this.

In https://cyberphone.github.io/doc/saturn/saturn-v3-presentation.pdf you can find yet another set of features worth consideration, including:

• discovery services
• stacked messages
• non-direct payments
• in-line confidential issuer-to-payer messaging
• risk-based user authentication

For my current prototype which predates OpenID payment solutions, I have decided to scrap JSON in favor of Deterministically Encoded CBOR: https://github.com/cyberphone/cbor-everywhere

[cyberphone]

Non-direct payments introduce UX concerns as well:

[cyberphone]

As a developer I feel a bit wary about being forced building request and response messages on top of OpenID4VP since it wasn't originally designed for payments. "Presentation" doesn't really apply to payments either. The response is rather an "Authorization" object that the requester in most cases would not be able to verify[*]. The only presentation I'm aware of, is in the wallet itself, showing virtual payment cards for the user to select from.

However, nothing prevent us from separating payment requests from other requests, making a unified wallet realistic, at least on paper. This mechanism would then be the common denominator for OpenID4VP. Maybe it is already there? I have some difficulties "deciphering" the massive amounts of documents referring to other documents 😉

*] This is not entirely true. In my vision, an authorization object would contain clear text information like amount and selected payment network, both which must be verified by the Payee. Only PII-related data like account and signature key info would be encrypted and thus not possible to verify by the Payee.

[cyberphone]

Somewhat confusing: https://github.com/EWC-consortium/eudi-wallet-rfcs?tab=readme-ov-file#candidate-rfcs-work-in-progress

[cyberphone]

A fundamental difference between identity-related services and traditional payment scenarios is that in the former the service provider is supposed to be trusted and in the EUIDW even certified. Merchants OTOH, are not necessarily trusted (or even known by the payer) except for the delivery of products or services. That is, technical trust in Merchants with respect to payments is out of scope for the wallet; it is provided by the payment backend. Trust in the client is exclusively a part of the account holding bank who also is the most likely issuer of the payment credential.

[Sakurann]

suggest closing this as a duplicate of #168. the current direction is for openid4vp spec to only define a general transaction data mechanism and any specifics for use-cases like payment/QES will be defined in respective standards body

[cyberphone]

@Sakurann feel free closing this issue. However, I would not expect the payment experts (they are...?) to actually build on OpenID4VP. "Credential Presentation" is not really applicable to payments, you rather just use credentials (authorize) and ideally without leaking any PII to non-trusted parties like Merchants.

Payment/QES does not appear to be particularly realistic either, since in payments the established scheme is: Issuer = RP = Bank. KYC is a more likely use case but it not related to payments but to enrollment in a bank.

There is to my knowledge currently no standards body that is authoritative for defining payment wallets. Not even the W3C and the FIDO alliance appear to have had much success with https://www.w3.org/TR/secure-payment-confirmation/. One of the reasons is the business model issue. SPC was designed for Stripe & Co; the banks were not involved and unfortunately banks do not really have people working with open standards either. Banks are currently investing billions of EUR in EPI so I would not expect much from them at this early stage. The Berlin group and EPC are only open to stakeholders which would eliminate almost everybody in OpenID.

This is why I proposed such a group within OpenID.

FWIW, I'm working on a concrete proposal that builds on my Saturn concept. It is of course just a proposal but starting with a blank piece of paper is simply put too hard. A counter-proposal from the OAuth2-powered folks would be much appreciated. Well, objectives is of course the most important thing.

@bc-pi @jogu @selfissued @tlodderstedt @sakimura

[bc-pi]

Unsubscribe

[cyberphone]

A 40 second video providing the Saturn "user story": https://www.youtube.com/shorts/ntqQzuWGW14

i believe such a thing is important in order to get people on the same page. Not everybody are capable reading RFCs and similar but may be of use anyway. The competition in the payment space is extremely fierce, making "evangelists" a necessity.

I'm currently trying to sway the industry (including TC-39) to put some weight behind deterministically encoded CBOR
https://github.com/cyberphone/CBOR.js#cborjs
since I believe this would be a perfect match for payment wallets.

[cyberphone]

Deterministically encoded CBOR enables new things.

Assume you have a message like this, where a tag holding a URL acts as an object type Id:

1010([["https://example.com/status"](https://example.com/status), {
   / temperature /
   1: 2.56,
   / weight /
   2: 505,
   / timestamp /
   3: "2024-08-22T15:32:20Z"
}])

Using the CBOR Signature Format (CSF) you would get the following:

1010([["https://example.com/status"](https://example.com/status), {
   1: 2.56,
   2: 505,
   3: "2024-08-22T15:32:20Z",
   / Signature container /
   -1: {
     / Signature algorithm (COSE Ed25519) /
     1: -50,
     / Ed25519 public key in COSE format /
     4: {
       1: 1,
       -1: 6,
       -2: h'fe49acf5b92b6e923594f2e83368f680ac924be93cf533aecaf802e37757f8c9'
     },
     / Signature value /
     6: h'1f10bf2efcfddee741a6dea052ef49e6b67dd549d580be36e5a1d50dc3f9afd5fb92a28ce37dfc877111ff35fb2f4c1f21ff0b0b48bdc04276742e6af033330b'
   }
}])

Compared to COSE you get the following advantages:

• The entire message is signed including the object type Id
• The message is kept in its original form
• Headers are in clear
• Extremely simple algorithm

Should be suitable for a payment wallet.

https://datatracker.ietf.org/doc/draft-ietf-cbor-cde/
https://cyberphone.github.io/javaapi/org/webpki/cbor/doc-files/signatures.html
https://www.ietf.org/archive/id/draft-rundgren-cotx-04.html

[cyberphone]

AFAICT, the interface to the bank seems to be anything but settled. The DigitalLabor folks currently base their solution on Berlin group's "Signed Payment Request", while @jogu recently wondered if you couldn't simply reuse the existing PSD2 Payment Initiation schemes building on OAuth2. That is a valid concern because "Signed Payment Request" has limited uptake and is (IMO) a poorly engineered solution as well.

Just to make things yet a bit more "interesting", I'm currently in the early phases defining another way forward which involves a new architecture. I tested this some 5 years ago and it worked quite well. There's nothing revolutionary about this at all; many Open Banking implementations already work in a similar fashion, although "behind the curtain".

[bc-pi]

Unsubscribe

That was just talk. Putting action behind the words this time.

[cyberphone]

@Sakurann maybe I'm missing something here, but creating a payment system without a sequence diagram seems like a rather difficult mission. Existing payment systems build on sets of tightly matched messages, inextricably associated with specific flows. Please enlighten us!

[bc-pi]

Probably user error on my part but "Unsubscribe" doesn't seem to be working...

[bc-pi]

I don't even see an unsubscribe option here...

[bc-pi]

Admittedly, some of my comments here have been sarcastic or dismissive in nature. My apologies to those in this discussion who have been bothered by such remarks. I’m choosing to view this as an opportunity to reflect on the style and effectiveness of my engagement in forums like this. I encourage others to do the same.

[cyberphone]

Before closing this issue as "inappropriate", may I finish with a summary? Since consumers typically pay for stuff multiple times per week, payment functionality seems like a prerequisite for large-scale uptake of the EUIDW. However, signing a contract and signing a C2B (Consumer To Business) payment request have practically nothing in common, from request and response (transaction) data, to flows.

#156 (comment) appears to agree with this notion:.

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.

It is also worth keeping in mind that existing payment systems build on specific business models. They do have one thing in common though; the desire that one party becomes the center of it all, like EPI. Here, I believe there may be room for innovation, but such ideas will undoubtedly be frowned upon by the traditional payment industry.

[jogu]

closing as duplicate of #168 as per #188 (comment)