> 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? > 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
