[OAUTH-WG] Question regarding RFC 8628

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 Provid

Re: [OAUTH-WG] Question regarding RFC 8628

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 Aut

Re: [OAUTH-WG] Question regarding RFC 8628

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 redirec

Re: [OAUTH-WG] Question regarding RFC 8628

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 sugg

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 tw

Re: [OAUTH-WG] Question regarding RFC 8628

Hi Hervé > On 18 Nov 2019, at 14:20, Robache Hervé wrote: > > 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 [redirec

Re: [OAUTH-WG] WGLC for "OAuth 2.0 Security Best Current Practice"

> On 17. Nov 2019, at 05:42, Vineet Banga wrote: > > > On Fri, Nov 15, 2019 at 11:51 PM Torsten Lodderstedt > wrote: > > >> On 16. Nov 2019, at 02:07, Vineet Banga > >> wrote: > >> > >> Just one comment/question at the moment: > > >3.1.1 - Is there any recommendation around leveraging st

Re: [OAUTH-WG] review draft-ietf-oauth-security-topics-13 [3/3]

Hi Hans, > On 18. Nov 2019, at 04:11, Hans Zandbelt wrote: > > Hi, > > Please find my feedback from page 21 onwards below. > > Hans. > > Overall I would argue there's room for a very concise guidance section that > says: do this, don't do that, without explanation, just as a reference for

Re: [OAUTH-WG] WGLC for "OAuth 2.0 Security Best Current Practice"

> Am 19.11.2019 um 13:39 schrieb Vineet Banga : > > Let me restate my original question. I agree with the usage of state for CSRF > protection, but it can also be used to capture the application state (as > specified in: [I-D.bradley-oauth-jwt-encoded-state]). I am asking if there is > any re

Re: [OAUTH-WG] review draft-ietf-oauth-security-topics-13 [2/3]

Hi Hans, > On 11. Nov 2019, at 17:57, Hans Zandbelt wrote: > > Hi, > > Please find my feedback on page 11-20 below. > > Hans. > > P14 > 4.2.4 For an RP there should be more explicit text and guidance about having > a single dedicated immutatable redirect URI per client that "demultiplexes"

Re: [OAUTH-WG] New Version Notification for draft-fett-oauth-dpop-03.txt

On Thu, Nov 14, 2019 at 7:20 PM Neil Madden wrote: > I can't attend Singapore either in person or remotely due to other > commitments. I broadly support adoption of this draft, but I have some > comments/suggestions about it. > Thanks Neil. And sorry to hear that you won't be in Singapore. This