Signed payment requests are impractical

[cyberphone]

In https://github.com/digitallabor-berlin/eudiw-sca/blob/ea5db12b59f583f79e3c866896565fa6c93ae2e4/openbanking-r2s.md#payment there is a line:

4. Verify the signature of the authorisation request

Although this seem logical it introduces dependencies on wallet-local trust anchors which complicate deployment. In addition, this scheme (guessing here...) makes the Payer the initiator since it is the Payer's signature that embeds the Payee request including the Payee receive account.

A more scalable and flexible solution is that the request is unsigned as well as free from merchant account information. To make this secure and trustworthy, the authorization response is put in a new container which is subsequently signed by the Payee. The correctness of the created object is then off-loaded to the payment backend. The Payee cannot change anything in the authorization response since it is signed by the Payer. WYSIWYS.

The core idea here is keeping the wallet as simple as possible.

This is how EMV payment terminals work as well.

[jogu]

Hi @cyberphone

Unsigned requests are permitted by the OpenID4VP specification. What action are you requesting the DCP WG takes?

[cyberphone]

Hi @jogu Essentially all of my OpenID4VP issues depend on if there is any connection between DigitalLabor's specification and OpenID4VP. Since the former indeed refers to OpenID4VP, the DCP WG should consider dealing with https://github.com/openid/OpenID4VP/issues/188. There are literally hundreds of minor and major issues begging for answers and I surely do not want to convert this repository into a mess.

Since DigitalLabor in just five months have come up with three entirely different authorization and initiation flows, the specification is obviously anything but stable. Given the fierce competition in the payment space, I would backpadel a bit and begin with objectives. @sakimura @Sakurann

[jogu]

We (the DCP WG) are not really in a position to tell DigitalLabor that they shouldn't use signed requests. (There's a very high chance that EU law requires them to use signed requests anyway, certainly the conclusion at this point on other credential requests to EU wallets is that the law requires them to be signed.)

[cyberphone]

We (the DCP WG) are not really in a position to tell DigitalLabor that they shouldn't use signed requests.

Right, https://github.com/openid/OpenID4VP/issues/188 is the only issue the DCP WG needs to bother with. Without a defined trust-, privacy-, and security-model we are left with opinions only. If DigitalLabor is not interested in a concerted effort, I would consider creating an alternative specification, including the currently missing Open Banking interface. In addition, nothing in their specification indicates that they have looked into multi-phase payments although such are fundamental for market acceptance. It is also worth knowing that DSGV (the owner of DigitalLabor), is also a founding member of EPI.

That is, payments (unlike identity) requires an infrastructure where you try to pinpoint "Who is doing What and with Whom and Why" as I like to express it 😁

According to some people on LinkedIn, the latest draft even violates PSD2 by letting the Payee run the show. Apparently this needs some discussions as well.

(There's a very high chance that EU law requires them to use signed requests anyway, certainly the conclusion at this point on other credential requests to EU wallets is that the law requires them to be signed.)

This makes perfect sense for identity-related operations where you want to assure that the request and requester are authentic.

However, payment-standards such as EMV or W3C's SPC do not build on such assumptions; they delegate the check to the backend. Security-wise this is (AFAICT...) identical, while scaling becomes unlimited. That is, if you accidentally authorize a transaction to a fraudulent merchant, this will be caught by the backend and the request will be denied. There is already a ton of other error conditions that cannot be cleared upfront, with "insufficient funds" likely being the most common 😆

This requires that payment requests use a fixed schema, otherwise the backend cannot verify the correctness of a response.

[jogu]

As per above we only need to worry about #188 so closing this one.