[OAUTH-WG] Question regarding RFC 8628

Robache Hervé <herve.robache@stet.eu> Mon, 18 November 2019 08:24 UTC

Return-Path: <herve.robache@stet.eu>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id C60AC12085F for <oauth@ietfa.amsl.com>; Mon, 18 Nov 2019 00:24:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id Nnbq_RdS3-Vk for <oauth@ietfa.amsl.com>; Mon, 18 Nov 2019 00:24:36 -0800 (PST)
Received: from mx.stet.eu (mx.stet.eu []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A65AD1200A3 for <oauth@ietf.org>; Mon, 18 Nov 2019 00:24:35 -0800 (PST)
Received: from mail.stet.eu ([]) by mx.stet.eu with ESMTP id xAI8OX7T001190-xAI8OX7V001190 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=CAFAIL) for <oauth@ietf.org>; Mon, 18 Nov 2019 09:24:33 +0100
Received: from STEMES002.steteu.corp ( by STEMES002.steteu.corp ( with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 18 Nov 2019 09:24:32 +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; Mon, 18 Nov 2019 09:24:32 +0100
From: Robache Hervé <herve.robache@stet.eu>
To: "oauth@ietf.org" <oauth@ietf.org>
Thread-Topic: Question regarding RFC 8628
Thread-Index: AdWd5gc8ZXfXLSK0SieoRUzTBpAA7Q==
Date: Mon, 18 Nov 2019 08:24:32 +0000
Message-ID: <dc925414da474a0a85d0b28be3009679@STEMES002.steteu.corp>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
x-tm-as-product-ver: SMEX-
x-tm-as-result: No-28.873200-8.000000-10
x-tmase-matchedrid: CVSPODxXzzKeGXFpAoGIoRoKdKvps9couNOxolvglUnPW3MF4hbkljWd LNzNpJuc63BZ+u8CIN1LsR2qi/tEEW1+plp1E5JO3zen1b+Th8ovdO1WpYGeABhaPDHak0t05i7 s7vRp3u+dF8cLePk03VcVGMO7PGHhyL+l/HI0f2rBtFDYGmaWKtoKfgOoKJc21xLW0OKX8iPIeA QugZMNBFtyNHRhmjtfAllRMNbKfG3a8AiR/nR5g8KVNVkgZd/Iy3fMd7pCml4wMfxyID/dnTRGW ZgDtiVIuedj3pQS7iZ7EW7ad22PFwxFU+TNBx+FbtitCkncbRnyCvICuK46cvAlhlr8vzcdLg4a EfqmR9dv4LXaUTxzCM5gLQgIAFB+QNOCx+A+HEecxB01DrjF95kShYcLpGH9lnl3JcyTSxK6JV/ T/Mrtr3uU7RlpYlRv1qs/xP9nRfmrnFkOWyixsTv9SnF9EU8nZml6I9/puERXJ/NTgaKQpp0lhL iscuITV+lCDzhvoi1YNeOziqUbUu6zXY4f1Mhp0rzmSCelis9fqgAMtax3Q6zG9MIKeG/Gzd1nd OghRTDtxRrExCB63gIVcha099c2vi/XXOZZp4qqDSBu0tUhr515MaKbV6QvvT9/feR/0aW3F617 Nam+4VJjEBeghlDXZidiiEoOZ/5B7s+L8t1zG8Vbb3pjW5MnxO20cNGQz3Vz9PcZ9BS/Gdn10Jn r8+EBdT86lTeOQqzd4VjvtZC1+oyCdCnUhkaOjpyluct2Nr0hIDrMt7IypUhcmj54ab4UiLrIVM ftV9AGCwjlKtyOgbw3cX26wX+ro8WMkQWv6iUfACoClnjRoaBxD3njREdhOMB0shqXhHqkonnIJ iWLzpccoTWliXtxapm9l1CQJK4g7R2zpN+0Gd/YDV6sKVTS
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
x-tmase-result: 10--28.873200-8.000000
x-tmase-version: SMEX-
x-tm-snts-smtp: FCDABA7E41ABC32DFBCD0DC1573131351C1208D3F2C09925105C7B2BD98D6A002000:9
Content-Type: multipart/alternative; boundary="_000_dc925414da474a0a85d0b28be3009679STEMES002steteucorp_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/1JhRvphyxAMUF1vaWdv2cTtdApo>
Subject: [OAUTH-WG] Question regarding RFC 8628
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 18 Nov 2019 08:24:39 -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.