Re: [OAUTH-WG] Question regarding RFC 8628

[Rob Otto <[e-mail]>]

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é <[e-mail]> 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.
>
> 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.
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>


-- 
<https://www.pingidentity.com>[image: Ping Identity]
<https://www.pingidentity.com>
Rob Otto
EMEA Field CTO/Solutions Architect
[e-mail]

c: [phone]
Connect with us: [image: Glassdoor logo]
<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> [image: facebook logo]
<https://www.facebook.com/pingidentitypage> [image: youtube logo]
<https://www.youtube.com/user/PingIdentityTV> [image: Google+ logo]
<https://plus.google.com/u/0/114266977739397708540> [image: Blog logo]
<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._