<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Apr 10, 2020 at 2:13 AM Anders Rundgren <<a href="mailto:anders.rundgren.net@gmail.com" target="_blank">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-09 21:37, Francis Pouatcha wrote:<br>
><br>
>     >     Personally, I'm into "moderately smart contracts" that are targeted at a more conventional payment market:<br>
>     > <a href="https://cyberphone.github.io/doc/payments/y2020-strong-merchant-authorization.pdf" rel="noreferrer" target="_blank">https://cyberphone.github.io/doc/payments/y2020-strong-merchant-authorization.pdf</a><br>
>     ><br>
>     > Great illustration. This is the way to go. Banking Protocols like EBICS (<a href="http://www.ebics.org/home-page/" rel="noreferrer" target="_blank">http://www.ebics.org/home-page/</a>) 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.<br>
><br>
>     Thanks!  I hope you are right :)<br>
><br>
>     EBICS was new to me.  It looks quite interesting.<br>
><br>
>     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:<br>
>     <a href="https://mobilepki.org/webpay-payeebank/payees/86344" rel="noreferrer" target="_blank">https://mobilepki.org/webpay-payeebank/payees/86344</a><br>
><br>
> 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.<br>
<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></blockquote><div>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.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<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></blockquote><div>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.</div><div><br></div>Regards.<br>--<br>Francis Pouatcha<br>Co-Founder and Technical Lead at adorys<br><div><a href="https://adorsys-platform.de/solutions/" rel="noreferrer" target="_blank">https://adorsys-platform.de/solutions/</a> </div></div></div>