> On 8 Jul 2020, at 17:21, Torsten Lodderstedt <tors...@lodderstedt.net> wrote: > > > >> On 8. Jul 2020, at 18:17, Neil Madden <neil.mad...@forgerock.com> wrote: >> >>> On 8 Jul 2020, at 15:40, Justin Richer <jric...@mit.edu> 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. > >> 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 >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
