<div dir="ltr"><div dir="ltr"><br></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Apr 11, 2020 at 12:30 AM Anders Rundgren <<a href="mailto:anders.rundgren.net@gmail.com">anders.rundgren.net@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 2020-04-10 23:56, Francis Pouatcha wrote:<br>
> <br>
<snip><br>
>> 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": <a href="https://cyberphone.github.io/doc/saturn/enhanced-four-corner-model.pdf" rel="noreferrer" target="_blank">https://cyberphone.github.io/doc/saturn/enhanced-four-corner-model.pdf</a> The setup process for a small merchant would be of the same magnitude as today.<br>
> <br>
> 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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
A slightly dated paper describing the rationale: <a href="https://cyberphone.github.io/doc/defensive-publications/authority-objects.pdf" rel="noreferrer" target="_blank">https://cyberphone.github.io/doc/defensive-publications/authority-objects.pdf</a><br>
<br>
Anyway, the #1 problem with respect to adoption is that this kind of trust model is new and unproven.  The same goes for countersignatures.<br></blockquote><div>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.</div><div><br></div><div>A new key management scheme will cause more confusion.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
<br>
> <br>
>     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.<br>
> <br>
> 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.<br>
<br>
Apple introduced this back in 2014.  They also offer a great UI and seamless Web2Wallet integration.<br>
<br>
Open Banking have none of that, there's not even a wallet.<br></blockquote><div>Let's try to get it adopted by open banking standards.</div><div> </div><div>Regards.<br>--<br>Francis Pouatcha<br>Co-Founder and Technical Lead at adorys<br><a href="https://adorsys-platform.de/solutions/" rel="noreferrer" target="_blank">https://adorsys-platform.de/solutions/</a><br></div><div><br></div></div></div>