<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
        {font-family:"Trebuchet MS";
        panose-1:2 11 6 3 2 2 2 2 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0cm;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
span.EmailStyle18
        {mso-style-type:personal-reply;
        font-family:"Calibri",sans-serif;
        color:windowtext;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-size:10.0pt;}
@page WordSection1
        {size:612.0pt 792.0pt;
        margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
        {page:WordSection1;}
--></style>
</head>
<body lang="EN-GB" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">Thanks for the commentary Francois. Apart from the security issues and the existential challenge that having a body that’s concerned with identity and good security practices implement a mechanism
 to facilitate user impersonation, the primary technical challenge I have around imbedded is the practicality of biometrics as called out by the EBA Opinion.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">The last time that this body and the OBIE considered how to facilitate a request to convey credentials as a ‘hint’, the prevailing recommendation was to standardize a login_token_hint as part of
 a CIBA flow. Either a CIBA or Device Flow can be used to facilitate POS journeys and they have been documented and published by the OBIE.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">We stopped short of publishing the formats for login_token_hint because of the variability however recommendations are made to ensure that the ID isn’t guessable or it includes input binding. There
 is nothing stopping a CIBA flow being initiated with a token of  {userId: rbragg, password: this_is_a_sub_optimal_suggestion } a bank can choose to ignore the “hint” of a password or take it on face value. I personally would prefer to describe conceptually
 via unofficial communications how this can be done rather than condone or encourage the practice of users surrendering passwords to parties to whom they are not intended and that have completely reasonable technical alternatives that offer far greater security
 and privacy benefits.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">My 2c – be interested in others views.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span style="font-size:12.0pt;color:black">From: </span></b><span style="font-size:12.0pt;color:black">Francis Pouatcha <fpo@adorsys.de><br>
<b>Date: </b>Thursday, 4 June 2020 at 15:36<br>
<b>To: </b>Dave Tonge <dave.tonge@momentumft.co.uk><br>
<b>Cc: </b>Financial API Working Group List <openid-specs-fapi@lists.openid.net>, Anders Rundgren <anders.rundgren.net@gmail.com>, Ralph Bragg <ralph.bragg@raidiam.com><br>
<b>Subject: </b>Re: [Openid-specs-fapi] Issue #295: Possible support for "embedded" SCA mode (openid/fapi)<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<div>
<p class="MsoNormal">Thanks for sharing Ralph,<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">- From a legal perspective, many ASPSP still provided AIS and PIS to their customers through embedded interfaces. As long as this occurs, TPP will keep fighting to obtain the same privileges, as the embedded approach provides the smoothest
 user experience.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">- From a technical perspective, there is a huge misunderstanding around authentication and authorization in the open banking space. Many frictions caused by multiple SCA, multiple redirections are due to the fact that initial open banking
 market initiatives did not draw clear lines between "authentication" and "authorization" of the PSU.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">--> Authenticating a PSU with the purpose of establishing a session between the PSU -> TPP -> ASPSP can occur once, can be well done using redirection and can be durable.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">--> Authorizing a payment or additional account access is very tight to banking business logic and should be embedded inside the PSU -> TPP interface,<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">----> as there is a dynamic linking between transaction data and the second factor (TAN, signature, ...)<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">----> as this will take away all hazard associated with involving unwanted third parties in this interaction, including the leakage of transaction data embedded into unencrypted jwt token in browser caches, ...<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">----> as this will allow TPP to provide frictionless banking interfaces to PSU<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">- We also witness the EBA here mentioning the PoS use case that does not work with mandatory redirection.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<div>
<p class="MsoNormal">From this EBA opinion paper, you can see the embedded approach is still a battleground between TPPs and ASPSP in the EEA open banking space. This battle will continue till we have well implemented reference practices that are secure and
 smooth on the market.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">IMHO the final solution will move toward having hybrid solutions with redirected authentication and embedded authorizations.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">This I reraised the point of reconsidering the embedded approach.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><a href="mailto:dave.tonge@momentumft.co.uk">@Dave Tonge</a> Where do I find the previous discussion or FAPI change request related to the embedded approach?<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Best regards.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">/Francis<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">On Thu, Jun 4, 2020 at 8:10 AM Dave Tonge <<a href="mailto:dave.tonge@momentumft.co.uk">dave.tonge@momentumft.co.uk</a>> wrote:<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm">
<div>
<div>
<p class="MsoNormal"><span style="font-family:"Trebuchet MS",sans-serif">Thanks for sharing Ralph - its an interesting document.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Trebuchet MS",sans-serif"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Trebuchet MS",sans-serif">We had a discussion </span>with Francis Pouatcha who brought the issue up again - as a way of helping harmoisation efforts with the Berlin Group and banks that have implemented their standards.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Trebuchet MS",sans-serif"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Trebuchet MS",sans-serif"><o:p> </o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">On Thu, 4 Jun 2020 at 14:04, Ralph Bragg via Openid-specs-fapi <<a href="mailto:openid-specs-fapi@lists.openid.net" target="_blank">openid-specs-fapi@lists.openid.net</a>> wrote:<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm">
<p class="MsoNormal">Hi,<br>
<br>
Opinion piece from the EBA on the validity of redirect and decoupled flows; I haven't digested the whole lot completely but it's broadly supportive of redirect and decoupled provided it's done well.<br>
<br>
Dave T - I'm curious about the embedded mode requirement and where this has come from?<br>
<br>
<a href="https://eba.europa.eu/eba-publishes-opinion-obstacles-provision-third-party-provider-services-under-payment-services" target="_blank">https://eba.europa.eu/eba-publishes-opinion-obstacles-provision-third-party-provider-services-under-payment-services</a><br>
<br>
Cheers,<br>
Ralph<br>
<br>
On 04/06/2020, 11:02, "Openid-specs-fapi on behalf of Joseph Heenan via Openid-specs-fapi" <<a href="mailto:openid-specs-fapi-bounces@lists.openid.net" target="_blank">openid-specs-fapi-bounces@lists..openid.net</a> on behalf of
<a href="mailto:openid-specs-fapi@lists.openid.net" target="_blank">openid-specs-fapi@lists.openid.net</a>> wrote:<br>
<br>
<br>
<br>
    > On 4 Jun 2020, at 10:21, Anders Rundgren <<a href="mailto:anders.rundgren.net@gmail.com" target="_blank">anders.rundgren.net@gmail.com</a>> wrote:<br>
    > <br>
    > On 2020-06-04 11:01, Joseph Heenan wrote:<br>
    >> Hi Anders,<br>
    >> Can you describe with a few lines of text (without referring to Saturn :-) ) how a protocol could address the EMV use case within FAPI or one of the other mechanisms we’re discussing please?<br>
    >> ( <a href="https://cyberphone.github.io/doc/payments/open-banking-direct-mode.pdf" target="_blank">
https://cyberphone.github.io/doc/payments/open-banking-direct-mode.pdf</a> seems mostly to be rehashing OpenID’s “sub” and OAuth2’s refresh token, and I can’t see where the result differs from using those two?)<br>
    > <br>
    > The document you are referring to is the best description I have so I can only repeat myself :)<br>
    > <br>
    > The technical core of the idea is keeping payment applications like EMV, Saturn, FIDO, etc out of the Open Banking API.<br>
    > The commercial aspect is that such applications would preferably be provided by the respective system owner.<br>
    > The applications (services rather) may or may not be PSD2 compatible.<br>
    > The scheme builds on using OAuth2 as binding system between these services (additional APIs) and the core API, where the former thus works like TPPs.<br>
    > The only really new thing is that the applications are running with higher privileges than existing applications since they are supposed to do SCA on their own.<br>
    > <br>
    > Making Open Banking APIs [technically] usable for any consumer payment may not be such a bad idea.<br>
<br>
    So if I understand correctly, the problem is with the limitations surrounding PSD2 functional APIs?<br>
<br>
    The various mechanisms FAPI supports, including CIBA and the embedded proposal under discussion, are all suitable for the initial user onboarding/binding of the user and (by using refresh tokens) for creating persistent sessions from the TPP to the bank
 for that user, and that no changes are necessary to the “security” protocols to enable the EMV use case supporting functional APIs you’re describing?<br>
<br>
    Thanks<br>
<br>
    Joseph<o:p></o:p></p>
</blockquote>
</div>
</blockquote>
</div>
<p class="MsoNormal">-- <o:p></o:p></p>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<p class="MsoNormal">Francis Pouatcha<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Co-Founder and Technical Lead at adorys<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><a href="https://adorsys-platform.de/solutions/" target="_blank">https://adorsys-platform.de/solutions/</a><o:p></o:p></p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</body>
</html>