EUIDW for Payments - How?

[cyberphone]

Currently, there are hundreds of wallets intended for payment authorization/initiation. Obviously the payment use case is very interesting and could also be crucial for the success of the EUIDW. One of the consortium members https://www.nobidconsortium.com/ target this use case. What seems to be missing is how this is to be architected. Building on a secret/proprietary scheme is unlikely to make it on a grand scale.

Whatever system you build, it will also have to compete with https://www.epicompany.eu/. EPI intends to build a universal wallet with payments in mind.

I also lack the connection to Open Banking which could make payment support easier and potentially ubiquitous.

I believe a specific payment task force would be needed to get somewhere.

[francis-pouatcha]

Currently, there are hundreds of wallets intended for payment authorization/initiation. Obviously the payment use case is very interesting and could also be crucial for the success of the EUIDW. One of the consortium members https://www.nobidconsortium.com/ target this use case. What seems to be missing is how this is to be architected. Building on a secret/proprietary scheme is unlikely to make it on a grand scale.

I suspect Berlin Group Open Finance (BGOF) and nobid will be looking at the open banking change request for Signed Payments Requests.

Whatever system you build, it will also have to compete with https://www.epicompany.eu/. EPI intends to build a universal wallet with payments in mind.

As same players are behind BGOF and EPI, I hope both some day find a common ground.

I also lack the connection to Open Banking which could make payment support easier and potentially ubiquitous.

Hier is IMHO the connection:

• The change request to introduce signed payment, accepted by BGOF.
• The EU fida regulation referencing EUID Wallet as a possible medium for SCA.

[cyberphone]

I don't know the current state of the Signed Payment Request with respect to a corresponding "wallet". The one I recall was a very complex solution based on eIDAS certificates. The scheme used in Apple Pay seems more reasonable.

Other developments like SPC (https://www.w3.org/TR/secure-payment-confirmation/), created by the "Big Tech" is not only a mature specification, it is already available in most client devices.

[cyberphone]

FAPI and OBIE seem uninterested in Signed Payment Request; they insist sticking to OAuth which puts the ID Wallet in a awkward position from a standards perspective.

[cyberphone]

I would also consider taking the opportunity introducing e-Receipts. This could even be an "Industry First" 😉 Technically this is actually quite simple, and does not (unlike current proprietary solutions), require that users subscribe to a service provider; an e-receipt can be delivered directly [and anonymously] to the wallet after a successful transaction.

More can be found at: https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework/issues/101

[cyberphone]

@francis-pouatcha Since the Signed Payment Request "by design" does not enable developing and testing new payment concepts using Open Banking sandboxes, this API will never fly. 3.5 years without any known progress proves this. The Berlin group will unlikely get another shot at this topic either.

Also see https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework/issues/104

[digeorgi]

Thank you for your input. We've noted the discussion of possible payment solutions and their integration with the EUDI Wallet. As the issue of payment using the EUDI Wallet needs further analysis and drill-down, the Commission decided to allocate a specific use-case in the new LSP call. Payments implementation will be verified in this use case, and valuable insights will be gathered, and then published as either guidelines, technical specifications or best practices. Please follow this track to be informed. Thank you, your feedback is invaluable to us

[earizon]

My intuition following the UNIX philosophy "Do one thing and do it right" is to split wallets into different use cases.

• A credential wallet must take "user credentials" (biometrics, signatures from secure key device, ...) as input and create "identity tokens" (claims about identity) as output (to be consumed by any app).
• A payment wallet must take "identity tokens" plus "payment intention" information as input (source account, destination account, expected balanced before/after payment) and output "payment orders" as output.

Ideally the architecture would be able to "pipe" a la UNIX:

 (this is just pseudo shell-script code for UNIX/Linux/BSD fans)
$ cat credentials | identity_wallet --outclaimlist a,b,c | payment_wallet --identity --STDIN --payment-info ...

Neither identity not payment wallets must be coupled to each other. A payment wallet must be able to obtain identity information through any existing identity mechanism (private ones, OIDC, SAMLv2 as well as the new OIDC4VP-eudiw- one). An EU identity wallet must be prepared to be used by payment wallets as well as any other wallet, app or service (health, public services, ...).