search

openid / OpenID4VP

58 stars 20 forks source link

Encrypted payment authorizations #196

Open cyberphone opened 5 months ago

cyberphone commented 5 months ago

Since the Payee (Merchant) is not an RP, but rather wants/needs some kind of indication that it has been or is about to be paid, the PII-part of the Payer authorization data handed over to the Payee should be encrypted.

To accomplish this, virtual payment credentials could preferable be fitted with a host-name identifier which through a .well-known extension would be used to retrieve the current issuer-specific public encryption key, algorithm, and update frequency. Encryption keys should be shared by multiple Payers to avoid they becoming PIIs as well. The update frequency would typically be very modest, permitting caching of encryption keys. Caching also enables payments to be performed without the wallet having Internet access.

In the case payment intermediaries need to know the Payer account number, this information could provided by the Issuer after successful Payer authorization. This should only apply to legacy card payment networks.

Sakurann commented 1 day ago

transaction data is part of credential presentation, so when the response is encrypted it is part of the encrypted response. am I right that there is no specific ask here?

cyberphone commented 20 hours ago

Since the third(!) iteration of the DigitalLabor/Nobid specification has just been withdrawn, my assumption is that we at the moment haven't even the slightest sign of consensus on how the EUIDW-4-Payment solution should be architected.

Personally, I don't see the point using OpenID4VP for payment authorizations, at least if you build on the time-proven RP=Issuer concept.

Encryption in a payment authorization scenario is only needed in a "pass-through" wallet where authorization data containing PII, pass through (technically) untrusted parties like Merchants. However, the encryption in this case would only be partial since Merchants still need to know where to send the authorization data.

The current EWC solution does not build on the "pass-through" concept and is thus better aligned with OpenID4VP. However, this comes with considerable functional limitations as well as an abysmal UI (https://github.com/openid/OpenID4VP/issues/313). I don't see how transaction_data can solve problems that stem from a flawed/suboptimal architecture.

Given the current situation, I believe we can safely conclude that payment authorizations are years away so you might as well close all issues related to payments.