[Openid-specs-fapi] Strong MERCHANT Authentication
anders.rundgren.net at gmail.com
Fri Apr 10 06:13:48 UTC 2020
On 2020-04-09 21:37, Francis Pouatcha wrote:
> > Personally, I'm into "moderately smart contracts" that are targeted at a more conventional payment market:
> > https://cyberphone.github.io/doc/payments/y2020-strong-merchant-authorization.pdf
> > Great illustration. This is the way to go. Banking Protocols like EBICS (http://www.ebics.org/home-page/) has been making use of the signature key-pairs in the corporate context for a while. Now it is also open for individual customers. We will slowly be witnessing progress in this direction.
> Thanks! I hope you are right :)
> EBICS was new to me. It looks quite interesting.
> In my particular use case, secure lookup services are used rather than X.509 certificates due to the amount of structured and certified data needed by verifiers:
> Submitting a payment request to a bank is associated with a lot of provisions including AML, GDPR, ... (no matter if it is a credit transfer or a direct debit). European PSD2 uses eIDas certificates for TPP. I like the concept of strong merchant authentication as Merchant could also be issued certificates. Merchant will then use certified key-pair to submit the customer's signed payment request to the bank. Without any third party. I suspect major merchants will endup acquiring tpp certificates.
Right, you are thinking in terms of PSD2 TTPs (PISPs). However, Strong Merchant Authorization is a part of a rather different approach to payment authorizations which builds on the since ages back established "Four Corner Model": https://cyberphone.github.io/doc/saturn/enhanced-four-corner-model.pdf The setup process for a small merchant would be of the same magnitude as today.
Although not shown in the slide, the return from step #3 is counter-signed by the User Bank (PKI) which means that the Merchant (through the payment network PKI) can verify it to be genuine. This scheme is also used for dealing with non-direct payments, where the (not shown) return rather contains a "grant" which the Merchant can subsequently use (again through counter-signing) to activate a previous reservation or perform a recurring payment transaction.
Note that Merchants have no rights on their own; they can only act on things that are already authorized by the user. This is like a highly specialized federated indentity system.
> This makes the scheme scale trust-wise in the same way as the bank network itself without introducing new parties in the soup. Merchant hosting services may though be needed since banks typically are not equipped for dealing with small merchants.
> Webendpoint base pki will be tough, as it takes a lot of time and effort to implement new trust schemes across networks. Adding a sort of "Certificate Transparency" system to Country-Authority issued certificates (like PSD2's eIDas) will fulfill the purpose.
That may indeed be needed for the banks participating in a payment network. There would (in my mind) be a separate PKI for each payment network.
> What I liked in your suggestion is the end user carrying his own key-pair. This will make open banking a lot easier, as we might use it to kill redirect processes.
I must admit that I don't fully understand how this could impact Open Banking. In the depicted scheme User keys are only recognized (and actually readable) by the User Bank.
> Francis Pouatcha
> Co-Founder and Technical Lead at adorys
More information about the Openid-specs-fapi