Re: [OAUTH-WG] Question regarding RFC 8628

Joseph Heenan <> Mon, 18 November 2019 13:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6C433120987 for <>; Mon, 18 Nov 2019 05:48:59 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 QNPSaLAC--LI for <>; Mon, 18 Nov 2019 05:48:56 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::433]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 657BA120995 for <>; Mon, 18 Nov 2019 05:48:56 -0800 (PST)
Received: by with SMTP id z10so19534073wrs.12 for <>; Mon, 18 Nov 2019 05:48:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=irXemYHOOsl0MRLuFcGkkXH6rYN4Ub705zWdDL6bYyI=; b=Rgef9sKrOqO1b+uqEdiVSZrJUxcUqJ+QQj0JZgTyY9KSV4rd88ui8LyiERF5QB+WSF o9ZeHq6dMyHbG1bfQTBQ2ciRapxAnP4WjwCaYBAnbG+D15kyEbzjyt4GuRovuimg0YrE xy8w9gjHFzf44kWDsl9EAl8yg2C4W+E0D92+PCTU/lGg3CeEHTefVwRbYQNbtT7DR/nk WhyXVQ+gTiZfVfmWYa6mbUji/OEFAXM9XIM+axm+hqrRO+30TPUtycolRtPsmvmHfFGR oG16Qtn7oGOTrTSQtOYoAbmEeazrM8isFG7R6lKLQG1wFNmVENj8UkUSs4YE/LeIblnF zfrA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=irXemYHOOsl0MRLuFcGkkXH6rYN4Ub705zWdDL6bYyI=; b=mUi7Rxsutt+w1oygYyGCMOrC7WY6pK217cekmOlPTFCW0Q4g+7/An3TytD9X3wGldr 6tIc/ymLKzIk1Zf+uawcMNlpmikdQR4KKmhetc3H60RATp1q2xxd/H4/Z1+W8HxQ+7f7 cNJ4gOflZI9L2xHvkUO9/GvDDiA1AXggUKjFrOs1eY8woT6KaVUcXCRjTmC3yVx+Fduc PuL9FYYutHAIJR2T3eZkNyE0KAsYzFWklHGwXkkMv9kWDui0LRx9/VBojQVHo56c0pCp SlZ3E3VMcGdYUhaRQQKqdEnre1AfLWGm82FVpVW0QMTeG1JO/NTHLm/uxWBqhT1tZQzJ vrnw==
X-Gm-Message-State: APjAAAWOvz7slLCyPwnBfngQG9FEztAfpe0jqceIsH9xipugCCbJR+jb 7ES5SgJ9IV2u6VNJSODyL9gCrg==
X-Google-Smtp-Source: APXvYqxMIPvkLBca1WiRnRospUdIT6tmR6Qf/sVmHwGCIODdC+49gW5mIp1d6x4egWOtTtwf/Keufg==
X-Received: by 2002:adf:b686:: with SMTP id j6mr19401092wre.186.1574084934688; Mon, 18 Nov 2019 05:48:54 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id f19sm25721412wrf.23.2019. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 18 Nov 2019 05:48:53 -0800 (PST)
From: Joseph Heenan <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_EDE34BEF-58C0-4EE9-84B5-2CF8E3A1A0E6"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Mon, 18 Nov 2019 13:48:52 +0000
In-Reply-To: <>
Cc: Robache Hervé <>, "" <>
To: Torsten Lodderstedt <>
References: <> <bab1c3a71a924582b25b76ac71d6b960@STEMES002.steteu.corp> <>
X-Mailer: Apple Mail (2.3445.104.11)
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 13:56:04 -0000

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.