> On 9 Jul 2020, at 08:28, Dave Tonge <[email protected]> wrote:
>
>
> Hi Neil
>
> From a conceptual point of view I'm not really sure what RAR changes from
> vanilla OAuth?
> For example what is the difference between a client redirecting a user to an
> AS in order to:
> - grant access to sensitive health data
> - initiate a specific payment
> - grant full read/write access to file storage containing sensitive
> commercial data
The difference is that one of these is transactional and the others aren’t.
Normal OAuth relationships are durative and give the user some measure of
control to manage that relationship over time. The transactional uses of RAR
preclude this because every transaction is a completely isolated interaction.
Unless you are suggesting dropping the transactional use-cases from RAR then
this should be considered and addressed.
>
> All of the above could happen with RAR or vanilla OAuth.
>
> Ironically in most jurisdictions, there is more protection for a user if they
> are tricked into initiating a payment vs whether they are tricked into
> granting access to data. Payments can be refunded, data cannot.
> From my perspective if an AS is granting access to sensitive data, payments,
> etc. then it has an obligation to protect its users by not allowing any
> random client to to start an authorization flow.
I’m glad we agree.
> In the case of Open Banking, this obligation is taken care of by national
> regulators, but other commercial OAuth deployments often employ some form of
> vetting of clients before allowing them to request sensitive data. In
> addition certain sensitive actions can always require step-up authentication
> - this is also the case in OpenBanking, a payment to a new payee or over a
> certain amount will always require multi-factor authentication even if the
> user has a valid logged in session.
Putting aside the question of whether regulation is an adequate substitute for
user consent, RAR is being proposed as a general specification, not within the
context of any specific regulatory framework. It’s not ok to just assume this
will all be handled by deployments.
>
> An AS is always free to implement the 2 step solution that you proposed and
> indeed it could be easier to implement with RAR in the manner you described,
> but I don't think it should be the prescribed approach.
How can an AS implement this with RAR? This is my point - there is no mechanism
at all in RAR to link a transaction to any kind of prior consent. It’s not
about mandating such an approach, it’s about *supporting* it at all. Every
transaction in RAR is a blank slate at the moment.
— Neil
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
