<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Hi Torsten<div class=""><br class=""></div><div class="">I think I agree with you that there are advantages to having a new endpoint.</div><div class=""><br class=""></div><div class="">I think there’s definitely an argument for this new endpoint allowing, somehow, for multiple alternative flows (including CIBA or a redirect) to result based on AS/RP capabilities & the situation of which methods the user has available + various risk indicators.</div><div class=""><br class=""></div><div class="">Fully appreciate your points about OAuth2 and I’m not sure how cleanly it’s possible to do the above within the constraints of OAuth2.</div><div class=""><br class=""></div><div class="">Joseph</div><div class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On 4 Jun 2020, at 09:01, Torsten Lodderstedt <<a href="mailto:torsten@lodderstedt.net" class="">torsten@lodderstedt.net</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="content-type" content="text/html; charset=utf-8" class=""><div dir="auto" class=""><div dir="ltr" class="">XYZ is different in that it generally starts with the backend call and leaves the decision about next steps to the AS while the AS‘s decision is governed by the client‘s capabilities.</div><div dir="ltr" class=""><br class=""></div><div dir="ltr" class="">In case of OAuth2, the client decided the interaction pattern (based on its capabilities and (potentially) AS metadata) and uses the respective endpoint at the AS and passes flow specific parameters.</div><div dir="ltr" class=""><br class=""></div><div dir="ltr" class="">Using another endpoint and grant type better fits the OAuth2 design philosophy. Please note: there are already other backend endpoint based flows in place, e.g. the device flow. Using CIBA to piggyback another flows seem a bit arbitrary to me.</div><div dir="ltr" class=""><br class=""></div><div dir="ltr" class="">Moreover, CIBA is still OIDC not OAuth. If we gone base this work on CIBA, I suggest to make it OAuth.</div><div dir="ltr" class=""><br class=""><blockquote type="cite" class="">Am 04.06.2020 um 09:53 schrieb Joseph Heenan <<a href="mailto:joseph@authlete.com" class="">joseph@authlete.com</a>>:<br class=""><br class=""></blockquote></div><blockquote type="cite" class=""><div dir="ltr" class=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class="">I think I agree with Dave, if I’ve correctly understood his position. Some of the concepts seem similar, in particular a back channel endpoint for initiating an authorization and auth_req_id as a handle for that request and that is accepted at the token endpoint.<div class=""><br class=""></div><div class="">Expanding the existing endpoint would in some ways look similar to how an authorization is initiated in <a href="http://oauth.xyz/" class="">oauth.xyz</a>.</div><div class=""><br class=""></div><div class="">I think the main advantage I would see to reusing parts of CIBA / extending CIBA would be that the RP/AS is in a position to be flexible. Whilst the PSD2 proponents for embedded probably don’t care about it, it gives the option for the AS to decide to run a CIBA flow /or/ an embedded flow taking advantage of extra information it has about the user about which flow is available / more likely to succeed at this point in time. I don’t think it’d be unreasonable to extend that with a response that says “nah, for this user [or in this situation where I’ve decided fraud risk is high] you’re going to have to do a redirect based flow”. It could potentially even return multiple possible methods to the RP, which could be advantageous - i.e. “here’s how you proceed with embedded flow, but actually if you’re on a mobile device and the user has an app installed that will handle <some url> then you might want to use that as there’s a 100% higher chance the flow will complete successfully”.<br class=""><div class=""><br class=""></div><div class="">Joseph</div><div class=""><br class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On 4 Jun 2020, at 08:42, Torsten Lodderstedt via Openid-specs-fapi <<a href="mailto:openid-specs-fapi@lists.openid.net" class="">openid-specs-fapi@lists.openid.net</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="content-type" content="text/html; charset=utf-8" class=""><div dir="auto" class=""><div dir="ltr" class="">The ultimate exchange at the token endpoint might be similar, the flow isn’t. I would rather adopt the pattern then the particular grant type.</div><div dir="ltr" class=""><br class=""><blockquote type="cite" class="">Am 04.06.2020 um 09:40 schrieb Dave Tonge <<a href="mailto:dave.tonge@momentumft.co.uk" class="">dave.tonge@momentumft.co.uk</a>>:<br class=""><br class=""></blockquote></div><blockquote type="cite" class=""><div dir="ltr" class=""><div dir="ltr" class=""><div class="gmail_default" style="font-family:trebuchet ms,sans-serif">I agree that a new endpoint is probably best. However I'd still like to explore the flow as an extension of CIBA, the reason being:<br class=""> - no new grant type needed</div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif"> - method of getting tokens already established</div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif"> - it is closer to the CIBA flow than the standard redirect flow</div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 4 Jun 2020 at 09:32, Torsten Lodderstedt via Openid-specs-fapi <<a href="mailto:openid-specs-fapi@lists.openid.net" class="">openid-specs-fapi@lists.openid.net</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Embedded SCA is a multi step authentication/authorization process with a variety of different methods. I think, if we gone support it, we should define a new endpoint for it. Otherwise, CIBA endpoints are cluttered with additional logic specific to embedded.<br class="">
<br class="">
> Am 03.06.2020 um 16:23 schrieb dgtonge via Openid-specs-fapi <<a href="mailto:openid-specs-fapi@lists.openid.net" target="_blank" class="">openid-specs-fapi@lists.openid.net</a>>:<br class="">
> <br class="">
> New issue 295: Possible support for "embedded" SCA mode<br class="">
> <a href="https://bitbucket.org/openid/fapi/issues/295/possible-support-for-embedded-sca-mode" rel="noreferrer" target="_blank" class="">https://bitbucket.org/openid/fapi/issues/295/possible-support-for-embedded-sca-mode</a><br class="">
> <br class="">
> Dave Tonge:<br class="">
> <br class="">
> There is currently a legislative requirement for some banks in the EU to allow TPPs to use an “embedded' mode where the TPP collects the user’s credentials and passes them through to the bank.<br class="">
> <br class="">
> While this is not our recommended approach, maybe we should consider a way of supporting it. This would help with harmonisation efforts so that we can try and get FAPI adopted more widely.<br class="">
> <br class="">
> This is how the Berlin Group support this type of interaction:<br class="">
> <br class="">
> ![](<a href="https://bitbucket.org/repo/K7gLBb/images/3573164385-Screenshot%202020-06-03%20at%2016.11.01.png" rel="noreferrer" target="_blank" class="">https://bitbucket.org/repo/K7gLBb/images/3573164385-Screenshot%202020-06-03%20at%2016.11.01.png</a>)<br class="">
> It is important to note that there is a requirement for the TPP to receive back a challenge to present to a user.<br class="">
> <br class="">
> One idea for how to implement this would be to use CIBA as it already has the concept of an “authorization session” via the auth\_req\_id.<br class="">
> <br class="">
> The flow could be:<br class="">
> <br class="">
> * RP → AS: /bc-authorize Create authorization request with a parameter indicating that embedded auth is preferred<br class="">
> * AS → RP: Ask the user for username/password<br class="">
> * RP → AS /token \{auth\_req\_id, auth\_params: \{user, password\}\}<br class="">
> * AS → RP: Ask the user for OTP<br class="">
> * RP → AS /token \{auth\_req\_id, auth\_params: \{OTP\}\}<br class="">
> * AS → RP Token<br class="">
> <br class="">
> No new endpoints would be needed. We would need extensions to the backchannel authentication endpoint and the token endpoint.<br class="">
> <br class="">
> <br class="">
> <br class="">
> <br class="">
> ‌<br class="">
> <br class="">
> ‌<br class="">
> <br class="">
> ‌<br class="">
> <br class="">
> Responsible: Dave Tonge<br class="">
> _______________________________________________<br class="">
> Openid-specs-fapi mailing list<br class="">
> <a href="mailto:Openid-specs-fapi@lists.openid.net" target="_blank" class="">Openid-specs-fapi@lists.openid.net</a><br class="">
> <a href="http://lists.openid.net/mailman/listinfo/openid-specs-fapi" rel="noreferrer" target="_blank" class="">http://lists.openid.net/mailman/listinfo/openid-specs-fapi</a><br class="">
_______________________________________________<br class="">
Openid-specs-fapi mailing list<br class="">
<a href="mailto:Openid-specs-fapi@lists.openid.net" target="_blank" class="">Openid-specs-fapi@lists.openid.net</a><br class="">
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-fapi" rel="noreferrer" target="_blank" class="">http://lists.openid.net/mailman/listinfo/openid-specs-fapi</a><br class="">
</blockquote></div><br clear="all" class=""><div class=""><br class=""></div>-- <br class=""><div dir="ltr" class="gmail_signature"><div dir="ltr" class=""><div class=""><div dir="ltr" class=""><div dir="ltr" class=""><div dir="ltr" class=""><div dir="ltr" class=""><div dir="ltr" class=""><div style="font-size:1em;font-weight:bold;line-height:1.4" class=""><div style="color:rgb(97,97,97);font-family:"Open Sans";font-size:14px;font-weight:normal;line-height:21px" class=""><div style="font-family:Arial,Helvetica,sans-serif;font-size:0.925em;line-height:1.4;color:rgb(220,41,30);font-weight:bold" class=""><div style="font-size:14px;font-weight:normal;color:rgb(51,51,51);font-family:lato,"open sans",arial,sans-serif;line-height:normal" class=""><div style="color:rgb(0,164,183);font-weight:bold;font-size:1em;line-height:1.4" class=""><div style="font-weight:400;color:rgb(51,51,51);line-height:normal" class=""><div style="color:rgb(0,164,183);font-weight:bold;font-size:1em;line-height:1.4" class="">Dave Tonge</div><div style="font-size:0.8125em;line-height:1.4" class="">CTO</div><div style="font-size:0.8125em;line-height:1.4;margin:0px" class=""><a href="http://www.google.com/url?q=http%3A%2F%2Fmoneyhubenterprise.com%2F&sa=D&sntz=1&usg=AFQjCNGUnR5opJv5S1uZOVg8aISwPKAv3A" style="color:rgb(131,94,165)" target="_blank" class=""><img alt="Moneyhub Enterprise" height="50" src="http://content.moneyhub.co.uk/images/teal_Moneyhub-Ent_logo_200x50.png" title="Moneyhub Enterprise" width="200" style="border: none; padding: 0px; border-radius: 2px; margin: 7px;" class="" data-unique-identifier=""></a></div><div style="padding:8px 0px" class=""><div style="padding:8px 0px" class=""><div style="letter-spacing:normal;line-height:normal" class=""><div style="padding:8px 0px" class=""><span style="color:rgb(0,164,183);font-size:11px" class="">Moneyhub Financial Technology, 5th Floor, 10 Temple Back, Bristol, BS1 6FL</span></div><span style="font-size:11px;line-height:15.925px;color:rgb(0,164,183);font-weight:bold" class="">t: </span><span style="font-size:11px;line-height:15.925px" class="">+44 (0)117 280 5120</span><br style="color:rgb(0,164,183);font-size:11px;line-height:15.925px" class=""></div><div style="letter-spacing:normal;line-height:normal" class=""><span style="font-size:11px;line-height:15.925px" class=""><br class=""></span></div><div style="color:rgb(97,97,97);font-family:"Open Sans";letter-spacing:normal" class=""><div style="line-height:1.4" class=""><span style="color:rgb(51,51,51);font-family:lato,"open sans",arial,sans-serif;font-size:0.75em" class="">Moneyhub Enterprise is a trading style of Moneyhub Financial Technology Limited which is authorised and regulated by the Financial Conduct Authority ("FCA"). Moneyhub Financial Technology is entered on the Financial Services Register </span><span style="color:rgb(51,51,51);font-family:lato,"open sans",arial,sans-serif;font-size:0.75em;background-color:transparent" class="">(FRN </span><span style="color:rgb(0,164,183);font-family:lato,"open sans",arial,sans-serif;font-size:10.5px;font-weight:700" class="">809360</span><span style="color:rgb(51,51,51);font-family:lato,"open sans",arial,sans-serif;background-color:transparent;font-size:0.75em" class="">) at <a href="http://fca.org.uk/register" target="_blank" class="">fca.org.uk/register</a>. M</span><span style="color:rgb(51,51,51);font-family:lato,"open sans",arial,sans-serif;background-color:transparent;font-size:10.5px" class="">oneyhub</span><span style="color:rgb(51,51,51);font-family:lato,"open sans",arial,sans-serif;background-color:transparent;font-size:0.75em" class=""> Financial Technology is registered in England & Wales, company registration number </span><span style="color:rgb(51,51,51);font-family:lato,"open sans",arial,sans-serif;background-color:transparent;font-size:0.75em" class=""> </span><span style="font-weight:bold;color:rgb(0,164,183);font-family:lato,"open sans",arial,sans-serif;background-color:transparent;font-size:0.75em" class="">06909772</span><span style="background-color:transparent" class=""><font color="#333333" face="lato, open sans, arial, sans-serif" class=""><span style="font-size:0.75em" class=""> .</span></font></span></div><div style="font-family:lato,"open sans",arial,sans-serif;color:rgb(51,51,51);line-height:1.4" class=""><span style="background-color:transparent;font-size:10.5px" class="">Moneyhub</span><span style="background-color:transparent;font-size:0.75em" class=""> Financial Technology Limited 2018 </span><span style="background-color:transparent;color:rgb(34,34,34);font-family:arial,sans-serif;font-size:x-small" class="">©</span></div><div style="font-family:lato,"open sans",arial,sans-serif;color:rgb(51,51,51);line-height:1.4" class=""><span style="background-color:transparent;font-size:0.75em" class=""><br class=""></span></div><div style="font-family:lato,"open sans",arial,sans-serif;color:rgb(51,51,51);line-height:1.4" class=""><span style="background-color:transparent;font-size:0.75em;color:rgb(136,136,136)" class="">DISCLAIMER: This email (including any attachments) is subject to copyright, and the information in it is confidential. Use of this email or of any information in it other than by the addressee is unauthorised and unlawful. Whilst reasonable efforts are made to ensure that any attachments are virus-free, it is the recipient's sole responsibility to scan all attachments for viruses. All calls and emails to and from this company may be monitored and recorded for legitimate purposes relating to this company's business. Any opinions expressed in this email (or in any attachments) are those of the author and do not necessarily represent the opinions of Moneyhub Financial Technology Limited or of any other group company.</span></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div>
</div></blockquote></div>_______________________________________________<br class="">Openid-specs-fapi mailing list<br class=""><a href="mailto:Openid-specs-fapi@lists.openid.net" class="">Openid-specs-fapi@lists.openid.net</a><br class=""><a href="http://lists.openid.net/mailman/listinfo/openid-specs-fapi" class="">http://lists.openid.net/mailman/listinfo/openid-specs-fapi</a><br class=""></div></blockquote></div><br class=""></div></div></div></blockquote></div></div></blockquote></div><br class=""></div></body></html>