> 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
