Re: [OAUTH-WG] A few comments on draft-ietf-oauth-rar-01

[Neil Madden <[e-mail]>]

On 13 Jul 2020, at 16:44, Francis Pouatcha <[e-mail]> wrote:
> 
>> 
>> 
>> Proof of RO (PSU) authorized interaction between the RO and the Client (TPP) prior to starting an payment authorization request is essential.
>> 
>> The NextGenPSD2 specification addresses the problem with a so-called oAuth2 pre-step option. As this requires two authorization operations (SCA) for the release of a single payment, banks implementing oAuth2 pre-step fell under the scrutiny of the EBA (European Banking Association) last June. Now those banks have the burden of proving to their NCA's (national market/country authorities) that pre-step is necessary to mitigate the very problem you are raising in this thread.
> 
> I’m not sure this is the same issue I’m raising in this thread. In particular, what I’m suggesting would *not* need two authorization requests per payment. What I am suggesting is that there is one long-lived authorization between the RO and a client and then individual authorizations of each transaction: 1 + N not 2N. 
> For the first payment you will need 2 authorizations. This is what I mean with the pre-step above.

Well it’s still only 1 authorization for the actual payment. The first authorization is the permission to initiate subsequent payment authorizations. I would imagine that most forms of fine-grained or transactional authorization will be used alongside more traditional forms of OAuth authorization, so this would be pretty natural in practice. For example, on first launch of an app you might get a consent screen like:

FooPay would like to:
 - List your accounts
 - View your account balance
 - Initiate payments from your account (you’ll be asked to approve each one)

> 
> And I understand you want to introduce grant management for the first durable authorization, so RO can revoque this correct?


This is a pretty standard feature of AS software, so I’d opt for “preserve” rather than “introduce”.

— Neil