> On 8. Jul 2020, at 18:59, Neil Madden <[email protected]> wrote: > > > >> On 8 Jul 2020, at 17:21, Torsten Lodderstedt <[email protected]> wrote: >> >> >> >>> On 8. Jul 2020, at 18:17, Neil Madden <[email protected]> wrote: >>> >>>> On 8 Jul 2020, at 15:40, Justin Richer <[email protected]> wrote: >>>> >>>> The two-phase approach is exactly what OBUK does, where you get one access >>>> token using client credentials before getting a more specific one in >>>> context of the user’s consent. This ends up being awkward to implement at >>>> best, since OAuth involves the user too early in the process to allow for >>>> this kind of thing. PAR might help address this dichotomy, but RAR can >>>> provide places for this to fill in. >>> >>> I’m not sure how client credentials would help here. The point I’m making >>> is that the _user_ needs to consent to two separate things: >>> >>> 1. An initial consent to allow this app/service to initiate payment >>> requests on my behalf. >> >> 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? In case of open banking the user legally consents to this process at the client (TPP) even before the OAuth/Payment Initiation dance starts. > >> >>> 2. Consent to individual transactions. >>> >>> RAR (and open banking?) completely omits step 1 at the moment, which seems >>> crucial. Especially if you’re doing something like CIBA backchannel where >>> step 1 is effectively consent for this app to spam my phone with payment >>> approval requests. >>> >>>> >>>> With XYZ, I tried to design for that kind of multi-stage transaction >>>> pattern more explicitly, with the idea that you could continue your >>>> request in context and vary it over time, or even start a new request in >>>> the context of an existing one. This is something that I intend to >>>> continue with the soon-to-be-formed GNAP working group, if you want to >>>> bring this use case there. >>> >>> RAR is adopted by the OAuth WG so I think this needs to be discussed here. >>> >>> — Neil >>> _______________________________________________ >>> OAuth mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/oauth >>
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
