Hi Hervé, the flow you outline is equivalent to CIBA (https://openid.net/specs/openid-client-initiated-backchannel-authentication-core-1_0-ID1.html).
RFC8628/device grant type and CIBA differ as follows: - RFC8628 provides the client with an URL for the authorisation process - CIBA requires the client to provide a user identifier to the AS/OP, the AS in turn uses an out of band mechanism to communicate with the user best regards, Torsten. > On 26. Nov 2019, at 09:26, Robache Hervé <[email protected]> wrote: > > Dear all > > Thanks again for your clarifications. After discussion with the French > community, we think that a full decoupled flow could be the following one > > <image002.png> > > From my perspective, this flow is very similar to RFC8628 or CIBA, except > the following difference: instead of providing the customer with the > authentication URI through the third party, the bank notifies directly the > customer on a specific device or mobile app. > > Do you have any thought on this flow? > > Thanks in advance > > Hervé > > De : Robache Hervé > Envoyé : lundi 18 novembre 2019 15:21 > À : 'Joseph Heenan'; Torsten Lodderstedt > Cc : [email protected] > Objet : [OAUTH-WG] Question regarding RFC 8628 > > Thanks Joseph > > I agree with you. There should be no issue when the URL is registered during > the TPP app installation. > > From my perspective, this URL should be passed during the authorization > request within the [redirect_uri] field. > > By the way, most of the French banks will use Oauth2 AC and not OpenId > Connect. I guess that the sequence diagram is roughly the same, isn’t it? > > Best regards > > Hervé > > De : Joseph Heenan [mailto:[email protected]] > Envoyé : lundi 18 novembre 2019 14:49 > À : Torsten Lodderstedt > Cc : Robache Hervé; [email protected] > Objet : Re: [OAUTH-WG] Question regarding RFC 8628 > > Hi all, > > Thanks, Torsten. > > > On 18 Nov 2019, at 13:22, Torsten Lodderstedt <[email protected]> wrote: > > Hi Hervé, > > looping in Joseph. > > > On 18. Nov 2019, at 21:17, Robache Hervé <[email protected]> wrote: > > Thanks Torsten > > Yes, we study this flow as well. Actually we consider the two following flows > for a mobile-based authentication > > - DECOUPLED : via a RFC8628-derived or CIBA approach (as suggested > by Rob) > - REDIRECT : via the flow specified in the OpenId link you gave. > > The main issue encountered so far is to give back the focus on the third > party app. Third Parties fear that their app will be kept in the back of the > mobile screen. > > @Joseph: what’s your take on this concern? > > In app2app, it really shouldn’t happen - if the device OS has not properly > registered the universal link, the TPP website would open instead and > authorization code can still be processed (though admittedly supporting this > use case may require a bit more care to ensure session mixup attacks can’t > happen). > > > > > This could happen when the TPP app [app link]/[universal link] is not > properly registered or forwarded to the bank app. > - In the REDIRECT approach this means that the authorization code > cannot be forwarded to the TPP > > I don’t really understand how the ‘app link’ would not be properly registered > to the bank app. The universal link should be the same URL as for the > redirect uri on the TPP website. Obviously if the TPP registers their > redirect uri incorrectly with the bank the flow won’t work, but this applies > equally to the web based flows, and it’s not the kind of problem you see > occur on a production system. > > The evidence from the UK so far is that drop-off rates (where the user does > not successfully complete the authentication and return to the third party) > are far lower for app2app compared to a normal oauth2 browser based redirect > flow; I can’t put my hand on the actual figures right now but from memory > around 5 times more users successfully completed an app2app flow than the > usual web flows. > > > - In the DECOUPLED approach it less critical since the TPP polls the > bank and eventually gets its token once the PSU has authenticated. > > But in the decoupled flow, the PSU first has to enter her PSU ID in order to > allow the TPP to identity the PSU towards the ASPSP. This is less convenient > and leaks PII. > > Not necessarily the PSU ID, but generally something that can be used to > identify the user. In theory it could be an ephemeral id, though in reality > there’s all sorts of issues with implementing that, particularly on a ’same > device’ flow. It’s definitely less convenient, particularly for the first > TPP<->ASPSP interaction where the TPP will necessarily have to collect more > info from the user than would be necessary in a redirect based flow. > > The user also has to manually switch back to the TPP app at the end of the > flow. > > My general opinion is that for most use cases where the consumption and > authentication devices are the same device a decoupled flow should not be > used, as for that use case app2app presents a far better user experience - > both in terms of the number of steps and the time taken to successfully > complete all the steps. > > Joseph > > > > Ce message et toutes les pièces jointes sont établis à l'intention exclusive > de ses destinataires et sont confidentiels. > Si vous recevez ce message par erreur ou s'il ne vous est pas destiné, merci > de le détruire ainsi que toute copie de votre système et d'en avertir > immédiatement l'expéditeur. > Toute lecture non autorisée, toute utilisation de ce message qui n'est pas > conforme à sa destination, toute diffusion ou toute publication, totale ou > partielle, est interdite. > L'Internet ne permettant pas d'assurer l'intégrité de ce message électronique > susceptible d'altération, STET décline toute responsabilité au titre de ce > message dans l'hypothèse où il aurait été modifié, déformé ou falsifié. > N'imprimez ce message que si nécessaire, pensez à l'environnement. > > This message and any attachments is intended solely for the intended > addressees and is confidential. > If you receive this message in error, or are not the intended recipient(s), > please delete it and any copies from your systems and immediately notify the > sender. > Any unauthorized view, use that does not comply with its purpose, > dissemination or disclosure, either whole or partial, is prohibited. > Since the internet cannot guarantee the integrity of this message which may > not be reliable, STET shall not be liable for the message if modified, > changed or falsified. > Do not print this message unless it is necessary, please consider the > environment. > <oledata.mso>
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
