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

[Francis Pouatcha <[e-mail]>]

>
> 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.

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

>
>

>
> Let settle with:
> - RAR as a payload for carrying authorization details
> - The decision on whether to protect an authorization transaction with a
> preceding RO authorization to do so shall be left to the target oAuth2
> profile.
>
>
> On Thu, Jul 9, 2020 at 1:58 PM Neil Madden <[e-mail]>
> wrote:
>
>>
>> > On 9 Jul 2020, at 18:34, Torsten Lodderstedt <[e-mail]>
>> wrote:
>> >
>> >> On 9. Jul 2020, at 19:28, Neil Madden <[e-mail]>
>> wrote:
>> >>
>> >> On 9 Jul 2020, at 18:10, Torsten Lodderstedt <[e-mail]>
>> wrote:
>> >>>
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>> What in particular should the use consent with in this step?
>> >>>>>>>>>>
>> >>>>>>>>>> “FooPay would like to:
>> >>>>>>>>>> - initiate payments from your account (you will be asked to
>> approve each one)”
>> >>>>>>>>>>
>> >>>>>>>>>> The point is that a client that I don’t have any kind of
>> relationship with can’t just send me a request to transfer $500 to some
>> account.
>> >>>>>>>>>
>> >>>>>>>>> Are we talking about legal consent or a security measures here?
>> >>>>>>>>
>> >>>>>>>> Normal OAuth consent. My phone is my resource, and I am its
>> resource owner. If a client wants to send payment requests to my phone
>> (e.g. via CIBA backchannel) then it should have to get my permission first.
>> Even without backchannel requests, I’d much rather that only the three
>> clients I’ve explicitly consented to can ask me to initiate payments rather
>> than the hundreds/thousands clients my bank happens to have a relationship
>> with.
>> >>>>>>>
>> >>>>>>> To me it sounds like you would like to require a client to get
>> user authorization to send an authorization request. Would you require the
>> same if I would use scope values to encode a payment initiation request?
>> >>>>>>
>> >>>>>> Yes. If something is sufficiently high value to require
>> per-transaction authorization then initiating transactions itself becomes a
>> privileged operation.
>> >>>>>
>> >>>>> The per transaction authorization alone is a significant increase
>> in security. What is the added value of requiring an authorization to send
>> a per-transaction authorisation request in an additional step?
>> >>>>
>> >>>> Because Open Banking allows any client at any time to send an
>> asynchronous back channel request to my phone to approve a payment. This is
>> pretty risky.
>> >>>
>> >>> Can you please explain how you came to that conclusion and how it
>> relates to RAR?
>> >>
>> >>
>> https://openbankinguk.github.io/read-write-api-site3/v3.1.6/profiles/payment-initiation-api-profile.html
>> >>
>> >> Client (PISP) initiates a payment-order consent using a
>> client_credentials access token, then launches a CIBA backchannel
>> authorization request. What prevents this?
>> >
>> > The fact that the PISP cannot issue this request without a valid user
>> identifier. The demos I’m remembering use a traditional first authorization
>> flow to establish this identifier.
>>
>> An identifier is not an access token or credential.
>>
>> >>
>> >> This relates to RAR, because RAR also has no protection against this.
>> If you use RAR in combination with a backchannel authorization method then
>> the same issue applies. This is a general issue with backchannel approaches,
>> >
>> > Exactly! It's a problem with any kind of backchannel initiated _user
>> interaction_.
>> >
>> >
>> >> but it is particularly a risk here because RAR is pitching itself as a
>> way to do payment transactions.
>> >
>> > The problem is the backchannel request, not RAR. RAR is just a more
>> elaborated scope.
>>
>> I don’t agree. It’s particularly acute with backchannel requests, but it
>> still exists with front channel. If I can redirect your browser to a
>> payment confirmation screen, what percentage of users will click ok? I
>> would guess more than 0. It’s a problem precisely because a one-off
>> interaction is enough to authorize a transaction.
>>
>> It might be that in OB they accept this risk and mitigate it in other
>> ways, e.g. making it easy to reverse transactions, or through sufficient
>> vetting of clients and big legal consequences. As a UK banking user, that
>> wouldn’t make me very happy but OK. The point is that RAR can’t make
>> payment transactions the primary use-case, emphasised throughout the draft,
>> and then fail to even discuss this issue or make any kind of suggestion as
>> how to handle it.
>>
>> — Neil
>>
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>
>
> --
> Francis Pouatcha
> Co-Founder and Technical Lead
> adorsys GmbH & Co. KG
> https://adorsys-platform.de/solutions/
>
>

-- 
Francis Pouatcha
Co-Founder and Technical Lead
adorsys GmbH & Co. KG
https://adorsys-platform.de/solutions/