No problem. You are always welcome.
> Am 26.11.2019 um 14:07 schrieb Robache Hervé <[email protected]>: > > Thanks Torsten, I didn't notice this point in CIBA. > > Sorry about asking a so silly question. > > Hervé > > -----Message d'origine----- > De : Torsten Lodderstedt [mailto:[email protected]] > Envoyé : mardi 26 novembre 2019 11:33 > À : Robache Hervé > Cc : Joseph Heenan; [email protected] > Objet : Re: [OAUTH-WG] Question regarding RFC 8628 > > 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> > > > > 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.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
