> > 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 <[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/ > > -- 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
