> On 13 Jul 2020, at 01:52, Francis Pouatcha <[email protected]> wrote: > > > Hi Neil, > > IMHO the purpose of RAR is to provide a rich substitute for oAuth2 scopes. > > The point you are addressing in this thread is nevertheless very pertinent, > even though not directly related to RAR.
I think it is absolutely related. > > 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. > > 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 <[email protected]> wrote: >> >> > On 9 Jul 2020, at 18:34, Torsten Lodderstedt <[email protected]> >> > wrote: >> > >> >> On 9. Jul 2020, at 19:28, Neil Madden <[email protected]> wrote: >> >> >> >> On 9 Jul 2020, at 18:10, Torsten Lodderstedt <[email protected]> >> >> 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 >> [email protected] >> https://www.ietf.org/mailman/listinfo/oauth > > > -- > Francis Pouatcha > Co-Founder and Technical Lead > adorsys GmbH & Co. KG > https://adorsys-platform.de/solutions/
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
