On 13 Jul 2020, at 16:44, Francis Pouatcha <[email protected]> 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
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
