> 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. > > 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. > >> >> 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 >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
