Subject: [OAUTH-WG] Question regarding RFC 8628

From: Robache Hervé <[email-masked]>
Date: Mon, 18 Nov 2019 08:24:32 +0000

Dear all

We are considering using RFC8628 for a specific use case that is related to the version 2 of Payment Service Directive in Europe (PSD2).

The purpose of the work is to provide a decoupled authentication flow for a payment Service User (PSU) aiming to grant access to a Third Party Provider (TPP) for his/her data hosted by a Bank.
The sequence should be as followed:

-          Nominal flow (as specified by the RFC)

o   The TPP asks the PSU about the Bank identity

o   The TPP posts a Device Access Token Request to the Bank

o   The Bank sends back a Device Access Token response to the TPP

o   The TPP starts to poll the bank for gaining the access token

-          Derived flow

o   The "verification_uri_complete" will not be displayed to the PSU but used as an [app link]/[universal link] on a smartphone in order to launch the bank's app.

o   The bank's app authenticates the PSU and asks for consent confirmation

-          Back to the nominal flow

o   The TPP gets its access token

Two questions have raised during the work

-          As RFC8628 is supposed to work on separate devices, can the usage be extrapolated to separate apps on the same device (i.e. the PSU's smartphone)?

-          One issue of the derived flow is that, after authentication, the PSU is still facing the bank's app

o   We would like to go back to the TPP's app as fluently as possible. The use of another [app link]/[universal link]could do the job is provided by the TPP. We consider adding this uri as an additional parameter to the "verification_uri_complete".

o   Is this compliant with RFC8628?

Thanks in advance for your answers.

Hervé Robache

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.

---

From: Rob Otto <[email-masked]>
Date: Mon, 18 Nov 2019 08:39:46 +0000

Salut Hervé

I wonder if you have looked at all at the OpenID Connect Client-Initiated
BackChannel Authentication (CIBA) flow for this use case? Certainly the
feeling amongst the Open Banking community here in the UK is that  it might
be a better fit for decoupled authentication than the Device Authorisation
Grant. There is even a FAPi (Financial-Grade API) profile of CIBA that is
making its way through the standardisation process - and even has a working
conformance testing suite.

The other option, that could make life easier when it comes to the final
step you mention (switching back to the TPP app from the Bank app) is to
use an app-to-app redirect model under OIDC. Again this is a popular model
for same-device scenarios that's been implemented by many banks here in the
UK.

If you'd like more information on either of these approaches, I'm happy to
share.

Best regards
Rob

On Mon, 18 Nov 2019 at 08:24, Robache Hervé <[email-masked]> wrote:

> Dear all
>
>
>
> We are considering using RFC8628 for a specific use case that is related
> to the version 2 of Payment Service Directive in Europe (PSD2).
>
>
>
> The purpose of the work is to provide a decoupled authentication flow for
> a payment Service User (PSU) aiming to grant access to a Third Party
> Provider (TPP) for his/her data hosted by a Bank.
>
> o   The “verification_uri_complete” will not be displayed to the PSU but
> used as an [app link]/[universal link] on a smartphone in order to launch
> the bank’s app.
>
> o   The bank’s app authenticates the PSU and asks for consent confirmation
>
> -          As RFC8628 is supposed to work on separate devices, can the
> usage be extrapolated to separate apps on the same device (i.e. the PSU’s
> smartphone)?
>
> -          One issue of the derived flow is that, after authentication,
> the PSU is still facing the bank’s app
>
> o   We would like to go back to the TPP’s app as fluently as possible.
> The use of another [app link]/[universal link]could do the job is provided
> by the TPP. We consider adding this uri as an additional parameter to the
> “verification_uri_complete”.
>
> 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é.
> 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.
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

-- 
<https://www.pingidentity.com>
<https://www.pingidentity.com>
Rob Otto
EMEA Field CTO/Solutions Architect
[email-masked]

c: +44 (0) 777 135 6092
Connect with us: 
<https://www.glassdoor.com/Overview/Working-at-Ping-Identity-EI_IE380907.11,24.htm>
[image:
LinkedIn logo] <https://www.linkedin.com/company/21870> [image: twitter
logo] <https://twitter.com/pingidentity> 
<https://www.facebook.com/pingidentitypage> 
<https://www.youtube.com/user/PingIdentityTV> 
<https://plus.google.com/u/0/114266977739397708540> 
<https://www.pingidentity.com/en/blog.html>
<https://www.google.com/url?q=https://www.pingidentity.com/content/dam/ping-6-2-assets/Assets/faqs/en/consumer-attitudes-post-breach-era-3375.pdf?id%3Db6322a80-f285-11e3-ac10-0800200c9a66&source=gmail&ust=1541693608526000&usg=AFQjCNGBl5cPHCUAVKGZ_NnpuFj5PHGSUQ>
<https://www.pingidentity.com/en/events/d/identify-2019.html>

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._

---

From: Torsten Lodderstedt <[email-masked]>
Date: Mon, 18 Nov 2019 18:39:29 +0800

Hi Hervé,

I assume you want to allow the TPP to send the PSU to the bank’s app on the same device?

In that case, why don’t you just make the bank’s authorization endpoint URL the universal link? If the universal link is defined on the smartphone (since the bank’s app is installed), the redirect will open the app. If the app is not installed, well, it will open the authorization endpoint in the browser. A very robust and simple approach.

There is an excellent article about this topic by Joseph Hernan on openid.net https://openid.net/2019/10/21/guest-blog-implementing-app-to-app-authorisation-in-oauth2-openid-connect/.

best regards,
Torsten.

> Am 18.11.2019 um 16:24 schrieb Robache Hervé <[email-masked]>:
> 
> 
> Dear all
>  
> o   The “verification_uri_complete” will not be displayed to the PSU but used as an [app link]/[universal link] on a smartphone in order to launch the bank’s app.
> -          As RFC8628 is supposed to work on separate devices, can the usage be extrapolated to separate apps on the same device (i.e. the PSU’s smartphone)?
> -          One issue of the derived flow is that, after authentication, the PSU is still facing the bank’s app
> o   We would like to go back to the TPP’s app as fluently as possible. The use of another [app link]/[universal link]could do the job is provided by the TPP. We consider adding this uri as an additional parameter to the “verification_uri_complete”.

---

From: Robache Hervé <[email-masked]>
Date: Mon, 18 Nov 2019 12:51:39 +0000

Hi Rob

Thanks for your answer.

Yes, we also studied CIBA. We are also aware that the REDIRECT app2app flow should be the easiest solution for a mobile-based authentication.

Best regards

Hervé

De : Rob Otto [mailto:[email-masked]]
Envoyé : lundi 18 novembre 2019 09:40
À : Robache Hervé
Cc : [email-masked]
Objet : Re: [OAUTH-WG] Question regarding RFC 8628

Salut Hervé

I wonder if you have looked at all at the OpenID Connect Client-Initiated BackChannel Authentication (CIBA) flow for this use case? Certainly the feeling amongst the Open Banking community here in the UK is that  it might be a better fit for decoupled authentication than the Device Authorisation Grant. There is even a FAPi (Financial-Grade API) profile of CIBA that is making its way through the standardisation process - and even has a working conformance testing suite.

The other option, that could make life easier when it comes to the final step you mention (switching back to the TPP app from the Bank app) is to use an app-to-app redirect model under OIDC. Again this is a popular model for same-device scenarios that's been implemented by many banks here in the UK.

If you'd like more information on either of these approaches, I'm happy to share.

Best regards
Rob

On Mon, 18 Nov 2019 at 08:24, Robache Hervé <[email-masked]<mailto:[email-masked]>> wrote:
Dear all

-          Derived flow

Hervé Robache

[email-masked]<mailto:[email-masked]>

--
[Image supprimée par l'expéditeur. Ping Identity]<https://www.pingidentity.com>

Rob Otto
EMEA Field CTO/Solutions Architect
[email-masked]<mailto:[email-masked]>

c: +44 (0) 777 135 6092

Connect with us:

[Image supprimée par l'expéditeur. Glassdoor logo]<https://www.glassdoor.com/Overview/Working-at-Ping-Identity-EI_IE380907.11,24.htm>[Image supprimée par l'expéditeur. LinkedIn logo]<https://www.linkedin.com/company/21870>[Image supprimée par l'expéditeur. twitter logo]<https://twitter.com/pingidentity>[Image supprimée par l'expéditeur. facebook logo]<https://www.facebook.com/pingidentitypage>[Image supprimée par l'expéditeur. youtube logo]<https://www.youtube.com/user/PingIdentityTV>[Image supprimée par l'expéditeur. Google+ logo]<https://plus.google.com/u/0/114266977739397708540>[Image supprimée par l'expéditeur. Blog logo]<https://www.pingidentity.com/en/blog.html>

[Image supprimée par l'expéditeur.]<https://www.pingidentity.com/en/events/d/identify-2019.html>

CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.

---

From: Robache Hervé <[email-masked]>
Date: Mon, 18 Nov 2019 13:17:25 +0000

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. 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

-          In the DECOUPLED approach it less critical since the TPP polls the bank and eventually gets its token once the PSU has authenticated.

Best regards

Hervé

De : Torsten Lodderstedt [mailto:[email-masked]]
Envoyé : lundi 18 novembre 2019 11:39
À : Robache Hervé
Cc : [email-masked]
Objet : [OAUTH-WG] Question regarding RFC 8628

Hi Hervé,

best regards,
Torsten.

Dear all

-          Derived flow

Hervé Robache

---

From: Torsten Lodderstedt <[email-masked]>
Date: Mon, 18 Nov 2019 21:22:01 +0800

Hi Hervé,

looping in Joseph.

> On 18. Nov 2019, at 21:17, Robache Hervé <[email-masked]> wrote:
> 
> Thanks Torsten
>  
> 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? 

> This could happen when the TPP app [app link]/[universal link] is not properly registered or forwarded to the bank app.

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.

best regards,
Torsten.

---

From: Joseph Heenan <[email-masked]>
Date: Mon, 18 Nov 2019 13:48:52 +0000

Hi all,

Thanks, Torsten.

> On 18 Nov 2019, at 13:22, Torsten Lodderstedt <[email-masked]> wrote:
> 
> Hi Hervé,
> 
> looping in Joseph.
> 
>> On 18. Nov 2019, at 21:17, Robache Hervé <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Thanks Torsten
>> 

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).

>> -          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.

> 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

---

From: Robache Hervé <[email-masked]>
Date: Mon, 18 Nov 2019 14:20:57 +0000

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-masked]]
Envoyé : lundi 18 novembre 2019 14:49
À : Torsten Lodderstedt
Cc : Robache Hervé; [email-masked]
Objet : Re: [OAUTH-WG] Question regarding RFC 8628

Hi all,

Thanks, Torsten.

On 18 Nov 2019, at 13:22, Torsten Lodderstedt <[email-masked]<mailto:[email-masked]>> wrote:

Hi Hervé,

looping in Joseph.

On 18. Nov 2019, at 21:17, Robache Hervé <[email-masked]<mailto:[email-masked]>> wrote:

Thanks Torsten

Joseph

---

From: Joseph Heenan <[email-masked]>
Date: Mon, 18 Nov 2019 15:02:06 +0000

Hi Hervé

> On 18 Nov 2019, at 14:20, Robache Hervé <[email-masked]> wrote:
> 
> Thanks Joseph
>  

Exactly, and that same url should have been pre-registered with the authorization server.

> 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?

Correct; pretty much exactly the same as I presume you’d still be using the authorization code flow.

The security concerns for app2app are very similar to basic OAuth2 / OpenID Connect, and to quickly sum those up for anyone reading this that's not familiar with those concerns: it’s very easy to do something that has undesirable security properties, and you should follow documents like FAPI-RW (an OpenID Connect based standard originally, but now JARM exists and has some vendor adoption OpenID Connect is not required) or the OAuth2 security BCP, to ensure your implementation is not vulnerable to the known attacks against OAuth2.

Cheers

Joseph