[Openid-specs-fapi] Strong MERCHANT Authentication

[Francis Pouatcha]

On Sat, Apr 11, 2020 at 12:30 AM Anders Rundgren <
anders.rundgren.net at gmail.com> wrote:

> On 2020-04-10 23:56, Francis Pouatcha wrote:
> >
> <snip>
> >> 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.
> >
> > Of course the "Four Corner Model" shows the difference between a
> Merchant and a PISP. What if instead of using an authority object a
> merchant uses a certificate issued by certification authority (like eIDas
> QTSP) on behalf of the bank? I think the state of technology wants us to
> use PKI + CTs.
>
> Well, with my 20Y+ PKI background it was not an easy decision to drop PKI
> (I actually started with PKI), but if you look really close you will find
> that the authority object concept actually is 100% PKI, albeit using a
> different format and distribution method.
>
> Since the RP (User Bank) needs a whole bunch of *certified* data (name,
> account, keys [including old ones], etc, and maybe things I haven't even
> thought of...), X.509 containers don't appear to be very practical. The
> publishing also eliminates OCSP/CRL.
>
> A slightly dated paper describing the rationale:
> https://cyberphone.github.io/doc/defensive-publications/authority-objects.pdf
>
> Anyway, the #1 problem with respect to adoption is that this kind of trust
> model is new and unproven.  The same goes for countersignatures.
>
What you are suggesting (having the user sign his payment order) is the way
to go. In order to achieve wide adoption we need to have this integrated
and coordinated with existing Open Banking standards and help move all in
the same direction. The eIDas initiative, the EBA institution registry and
EBICS key management experience are components to look at, as banks are
being mandated by law to deal with them.

A new key management scheme will cause more confusion.

>
>
> >
> >     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.
> >
> > Existing open banking initiatives have not foreseen user private key
> based SCA. Neither do they include existing standards like EBICS. I guess
> the banking world is not accustomed to end users digitally signing
> transactions, as it is still not obvious to trust end users protecting
> those private keys. Progress is being made in this domain.
>
> Apple introduced this back in 2014.  They also offer a great UI and
> seamless Web2Wallet integration.
>
> Open Banking have none of that, there's not even a wallet.
>
Let's try to get it adopted by open banking standards.

Regards.
--
Francis Pouatcha
Co-Founder and Technical Lead at adorys
https://adorsys-platform.de/solutions/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-fapi/attachments/20200419/f0084957/attachment-0001.html>