Re: [OAUTH-WG] Question regarding RFC 8628

Torsten Lodderstedt <> Mon, 18 November 2019 10:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2774E12086F for <>; Mon, 18 Nov 2019 02:39:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1uNxCBKua2xA for <>; Mon, 18 Nov 2019 02:39:34 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::1031]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9DA4D12093D for <>; Mon, 18 Nov 2019 02:39:34 -0800 (PST)
Received: by with SMTP id bo14so1372565pjb.1 for <>; Mon, 18 Nov 2019 02:39:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=QsadswRGwknee2H/fwBH5WOvKw+LqoP0Rme2VbOKWnA=; b=smL+qh3MGcz50ya66zR8+HQfVI3ScSUGwkTbfpkcTCCAI86PmnpDpFesiDcL5NFAyi 6Z0FAjaT21J2qcHAuH0i2xRQdT3fjiLamiSzFXhoPyUOOsTPFhkjSZCgJaNU3i+7naiW tkjQa12duZOIVeDFiVb8Z2saJ7nhWLa9wk8YB1eijx5M2W3O+ZDdoWqXCtVp20jk1+Rf gv2cRIkBtx4Sn7JmoutHMYrrXgC/ZMHteQF0EcuNJRpSgre/0UFgcgLDPYXaXPa1fyC9 CLO2D6BQOdBNSgKmh2UIsM9AR+wbb6dnuwzDutshyzTkl72BgQSRFiYnB0nI++zVbHsa HUIg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=QsadswRGwknee2H/fwBH5WOvKw+LqoP0Rme2VbOKWnA=; b=FDhT3vpN3HeN5w7JG8h2uGyYLVEW15arW//RU+mWfXaAgGuI0Wu4dtrGXSYVO+23sw wGGsxvEVVmmu5cKR+1/3kKIQG1H4xqQXwV3OH/Mvcwkt/yJ9OHZT0E5fa4b9SAcplfX1 yhyePYv8E8XtzhhX1OQK/xxSwOugmbzGyl15eW/egrE7YS0ZBvPLR7LoJXFufCLg4wcT vEk9eB1hzYPYxnaBMVuDReVZRkn8DUshmmI429CB54XJ7NVAPBVb4sKRqgGcGpdKyLJt DwG8z5WEQMj7cqXpvcgMA0LqQ00EoNoIDsDkA5uJnERkWZbz4V+zZE+glv7GnVhjYbLL DCXQ==
X-Gm-Message-State: APjAAAWgYaz1EYmteb0QG2qC+KvHKSCeL54H2QPnFYQTm5f7uH1oLT6k eFKHHhpbZMjt503PIdgCRZThv9/w+sgP+1ZZ
X-Google-Smtp-Source: APXvYqy7JwxAxe7V1P3OFtdnxUBrWObH6EUL+cGyUj4dkIKkcgAkIW/SiqEFmI6k5/pMxA4jAli8xA==
X-Received: by 2002:a17:902:322:: with SMTP id 31mr27828187pld.293.1574073572760; Mon, 18 Nov 2019 02:39:32 -0800 (PST)
Received: from [] ([]) by with ESMTPSA id z11sm22962521pfg.117.2019. (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 18 Nov 2019 02:39:31 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail-06793E69-14B0-4E17-ABBA-83D485E6530B"; protocol="application/pkcs7-signature"; micalg="sha-256"
Content-Transfer-Encoding: 7bit
From: Torsten Lodderstedt <>
Mime-Version: 1.0 (1.0)
Date: Mon, 18 Nov 2019 18:39:29 +0800
Message-Id: <>
References: <dc925414da474a0a85d0b28be3009679@STEMES002.steteu.corp>
Cc: "" <>
In-Reply-To: <dc925414da474a0a85d0b28be3009679@STEMES002.steteu.corp>
To: Robache Hervé <>
X-Mailer: iPhone Mail (17A878)
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: Mon, 18 Nov 2019 10:39:37 -0000

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

best regards,

> Am 18.11.2019 um 16:24 schrieb Robache Hervé <>:
> 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