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 <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? 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, but it is particularly a risk here because RAR is pitching itself as a way to do payment transactions. > > In the simplest of all scenarios the client sends authorization details > instead of scope values through the user browser and this way starts the > authorization process with the AS. > > When RAR is combined with PAR, the client first stores the authorization > request including authorization details at the AS in exchange for a reference > to this data. It then uses this reference to start the authorization process. > This is more secure and robust than sending the data through the browser. > > So what is the risk here and why do you think unsolicited backchannel > requests are sent to your device? > > >> >> I can’t think of another transactional auth system that allows this without >> some kind of initial indication of user consent. For example, in Apple Pay >> all payment requests must be initiated from an explicit user gesture, >> providing some indication that the user wants to use this. The Dropbox >> Chooser and Saver APIs also have to be triggered from a user gesture. Again, >> this provides some confirmation that the user actually initiated the >> interaction. >> >> In OAuth, the AS doesn’t have this level of integration into the client’s UI >> so it needs some other way to establish user consent. By the time the user >> has a payment confirmation request on their screen it’s too late. >> >> >>>>>>> In case of open banking the user legally consents to this process at >>>>>>> the client (TPP) even before the OAuth/Payment Initiation dance starts. >>>>>> >>>>>> How does the bank (ASPSP) confirm that this actually happened? >>>>> >>>>> It does not because it is not the responsibility of the ASPSP. The TPP is >>>>> obliged by law to obtain consent. >>>> >>>> If the TPP can be trusted to obey the law about this, why not also trust >>>> them to be honest about transactions? Why enforce one thing with access >>>> tokens but take the other on trust? Especially as the actual transactions >>>> are more likely to have a rigorous audit trail. >>>> >>>> If we could trust clients to obtain consent we wouldn’t need OAuth at all. >>> >>> I thought the same initially, but we must distinguish between legal consent >>> and strong authentication/transaction authorization in such a case. Legal >>> consent can be obtained in various ways including the traditional OAuth >>> user consent but also in other places. Authenticating the user (probably >>> with 2FA) and getting authorization for a certain transaction (the meaning >>> of PSD2 SCA) must be conducted by the AS. >>> >> >> Do you mean legal protection for the bank or their users? As a user, if an >> OB client acts in a way that I don’t like, but doesn’t break any actual laws >> or policies, what’s my recourse? In normal OAuth I can revoke the grant to >> that client. This is not possible in transactional uses of RAR, and that >> seems like a big difference that significantly changes the relationship >> between users and clients. >> >> — Neil
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
