Re: [OAUTH-WG] Question regarding RFC 8628

Robache Hervé <> Tue, 26 November 2019 08:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8B7F312003F for <>; Tue, 26 Nov 2019 00:26:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DC_PNG_UNO_LARGO=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Yt0jJtaIdnfA for <>; Tue, 26 Nov 2019 00:26:10 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1BB2B12081B for <>; Tue, 26 Nov 2019 00:26:06 -0800 (PST)
Received: from ([]) by with ESMTP id xAQ8Q3KR007786-xAQ8Q3KT007786 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=CAFAIL); Tue, 26 Nov 2019 09:26:03 +0100
Received: from STEMES002.steteu.corp ( by STEMES002.steteu.corp ( with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 26 Nov 2019 09:26:03 +0100
Received: from STEMES002.steteu.corp ([fe80::61f9:86a6:9add:e621]) by STEMES002.steteu.corp ([fe80::61f9:86a6:9add:e621%14]) with mapi id 15.00.1497.000; Tue, 26 Nov 2019 09:26:03 +0100
From: Robache Hervé <>
To: Joseph Heenan <>, Torsten Lodderstedt <>
CC: "" <>
Thread-Topic: [OAUTH-WG] Question regarding RFC 8628
Thread-Index: AdWeII26US5M3faEQ+WvksYaVb0XzwGEZkIA
Date: Tue, 26 Nov 2019 08:26:03 +0000
Message-ID: <c3601d96013842ed8570823ce0d07fad@STEMES002.steteu.corp>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: yes
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
x-tm-as-product-ver: SMEX-
x-tm-as-result: No-22.083600-8.000000-10
x-tmase-matchedrid: 6jmP1Ht9qSueGXFpAoGIoe5i6weAmSDKqr0Np6cKdO5fQRiqw0gT4DcI a9gjeLdiWRv4gMq+CegHdptXFFME7wRytbWF0BphCgHQMFomsrRv+B0owAW3BpcDGDiTFmuGs03 PiUbxvvhR1tTDNqr8dVjZYFGVYSCavqDeDn7UX95DO9NSmfde1K6IBbSnfz+3CwWRLqiC/UqTvZ kBseIwt+1GNG8gfAYq1EsO4+XMhUs8Ph3xmtQMM36Y5s54+e3KwcNYF/8uAnxKddiF2Wo8edk2l 7i3oc4zRw3fpQHgw3sSs4PEHE58E2GA/BgSguhrW4b3LWV65TthS5mf1VdlYW+fXVEQ/fGeLKiG E4quj62tMJUmFtokrLdxpg1wk3ZZqtUjpgakDg4mEURBmKrZlDYCN3h43uATjFFYmmGGytxNc6P VcEC7cClO83MoWhLa1gfFWv2A3tFuVFQ4+Z0ChqmGTQytjAwlmRKFhwukYf10+P0tQGP+S3uKC/ mB6YsP50kZRfUS7pmGCLqQvRi5SAtOjMpOrPSt9VjtTc1fwmBRvgR0hkbG4DuwTDpX8ii0RGTvU rkVuyNWGLjxzYP1N+Lpee4QwI3eT11Qm3nv9lJtJYfOb0q5O2ZrKp1iUZhLuFQeUK7rNFsxLOo7 8h7rqFKSO61FHUul3GP0YVYnhxHH4Bb5h1nA8V9WMqffuCQmOh+3EpVSzUbDv5dDcuT2edRlmyj fMuuvPqh/Toa5DvXO9GIXQI4vS2fcSuJaXwtioYYDKbevse1VogWRsEaR/rLWf00E+3M1o1Uypg rbZr7ezkYoPxTs3pKlrkWVMYlhweGG47UzGkyrm7DrUlmNkIlfAW57f8KpmBJMroHl9O11NYf7U qBJ/CdXB5z8HM7hZMVYtyRnc/x5LAuoLWfu8twk9syBlhOci1Q/lWFA9dRnLdKPXE/ywp3zdOY4 m5CF2X8N5yzEaamByf9vwiEp9A==
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
x-tmase-result: 10--22.083600-8.000000
x-tmase-version: SMEX-
x-tm-snts-smtp: 6190CA6CA80881E2519ECEC0949854B2F18A2419B0FE6398A34530745713D4502000:9
Content-Type: multipart/related; boundary="_006_c3601d96013842ed8570823ce0d07fadSTEMES002steteucorp_"; type="multipart/alternative"
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [OAUTH-WG] Question regarding RFC 8628
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 26 Nov 2019 08:26:13 -0000

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


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


De : Robache Hervé
Envoyé : lundi 18 novembre 2019 15:21
À : 'Joseph Heenan'; Torsten Lodderstedt
Cc :
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


De : Joseph Heenan []
Envoyé : lundi 18 novembre 2019 14:49
À : Torsten Lodderstedt
Cc : Robache Hervé;
Objet : Re: [OAUTH-WG] Question regarding RFC 8628

Hi all,

Thanks, Torsten.

On 18 Nov 2019, at 13:22, Torsten Lodderstedt <<>> wrote:

Hi Hervé,

looping in Joseph.

On 18. Nov 2019, at 21:17, Robache Hervé <<>> 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.


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.