<div dir="ltr"><div dir="ltr">On Fri, Jun 5, 2020 at 2:59 AM Ralph Bragg <<a href="mailto:ralph.bragg@raidiam.com">ralph.bragg@raidiam.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div lang="EN-GB">
<div class="gmail-m_-7982646414066772744WordSection1">
<p class="MsoNormal"><span>Hi,<u></u><u></u></span></p>
<p class="MsoNormal"><span><u></u> <u></u></span></p>
<p class="MsoNormal"><span>Glad to see that CIBA might solve the use case, having a flow where the UI/UX isn’t interrupted for a TPP was a significant driver for the inclusion of this in the OBIE specs. Authorization becomes
optional / configurable and identity is what ever is agreed as part of the market initiative specification for login_hint or id_token.<u></u><u></u></span></p>
<p class="MsoNormal"><span><u></u> <u></u></span></p>
<p class="MsoNormal"><span>I personally think of CIBA as more as a decoupled authorization rather than authentication protocol and using the standard id_token_hint or login_token_hint will allow TPP’s to persist and assert
an identity of a PSU that a bank can rely on. Technically there’s nothing stopping a TPP asking for the same experience with a redirect. The format of login_hint as defined in OIDC Core could be a signed object which in turn could be wrapped in a signed request.
A TPP can already indicate that an ASPSP should not perform any additional authentication or authorization by including the prompt=none on a redirect
</span><a href="https://openid.net/specs/openid-connect-core-1_0.html" target="_blank">https://openid.net/specs/openid-connect-core-1_0.html</a><u></u><u></u></p>
<p class="MsoNormal"><span><u></u> <u></u></span></p>
<p class="MsoNormal"><span>An ecosystem specification could require that ASPSPs ensure that the authentication mechanisms available to a PSU are conveyed in an id_token to a TPP for the purposes signalling if a PSU supports
a CIBA flow. This would be quite useful but personally something I see that a market initiative will need to specify as the non-technical requirements for the delay and ux that different mechanisms of asynchronous AuthZ/AuthN have will be acceptable or not-acceptable
to different markets and indeed different TPPs!<u></u><u></u></span></p>
<p class="MsoNormal"><span><u></u> <u></u></span></p>
<ul style="margin-top:0cm" type="disc">
<li class="gmail-m_-7982646414066772744MsoListParagraph" style="margin-left:0cm"><span>If there is a need to ‘discover’ the authentication mechanisms a customer supports<u></u><u></u></span></li><li class="gmail-m_-7982646414066772744MsoListParagraph" style="margin-left:0cm"><span>A market initiative deems this to be critical<u></u><u></u></span></li><li class="gmail-m_-7982646414066772744MsoListParagraph" style="margin-left:0cm"><span>And it needs to be done before a TPP initiates a transaction that may require additional authorization
<u></u><u></u></span></li><li class="gmail-m_-7982646414066772744MsoListParagraph" style="margin-left:0cm"><span>And a TPP has a means of asserting the identity of the calling PSU<u></u><u></u></span></li></ul>
<p class="MsoNormal"><span><u></u> <u></u></span></p>
<p class="MsoNormal"><span>I’d suggest a market initiative
<u>could</u> require Banks accept either a redirect. { prompt=none, response_type= id_token, scope=openid, claim=available_authn_mechanisms?, login_hint={signed id} or CIBA equivalent to be given an id_token without any user interaction.
<u></u><u></u></span></p>
<p class="MsoNormal"><span><u></u> <u></u></span></p>
<p class="MsoNormal"><span>This would then allow a TPP to make a choice based on the mechanisms available to a PSU<u></u><u></u></span></p>
<p class="MsoNormal"><span>All of this can be done with the
<u>existing standards </u>using FAPI profiles. <u></u><u></u></span></p>
<p class="MsoNormal"><span><u></u> <u></u></span></p>
<p class="MsoNormal"><span>Another market initiative extension might be useful is to include as part of the CIBA
</span><span style="font-size:9pt;font-family:Menlo;color:rgb(23,43,77);background:rgb(244,245,247)">request_context
</span><span>an indication that the TPP takes full responsibility for AuthN and AuthZ capturing. An ASPSP can then either reject the request because it can’t fulfil those requirements (say as a result of TRA or a PSU opting
into Bank only AuthZ reconfirmation) or ignore them.</span><u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">If you could provide a list of the use cases and scenarios I’d be happy to confirm if they’ve been considered in any of the jurisdictions that FAPI is being considered and what options for the specs were suggested.<u></u><u></u></p>
<p class="MsoNormal"><span><u></u></span></p></div></div></blockquote><div>I documented a sample open banking workflow in the ticket: <a href="https://bitbucket.org/openid/fapi/issues/295/possible-support-for-embedded-sca-mode#comment-57684988">https://bitbucket.org/openid/fapi/issues/295/possible-support-for-embedded-sca-mode#comment-57684988</a> . This can serve as a basic input for the specification of the embedded approach.</div><div><br></div><div></div><div>-- <br></div></div><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div>Francis Pouatcha</div><div>Co-Founder and Technical Lead at adorys</div><div><a href="https://adorsys-platform.de/solutions/" target="_blank">https://adorsys-platform.de/solutions/</a></div></div></div></div></div></div></div></div></div></div></div>