Re: [OAUTH-WG] A few comments on draft-ietf-oauth-rar-01

[Neil Madden <[e-mail]>]

On 7 Jul 2020, at 21:09, Vladimir Dzhuvinov <[e-mail]> wrote:
> 
> 
>> On 06/07/2020 19:32, Neil Madden wrote:
>> I’m reading draft-ietf-oauth-rar-01 in a bit more detail now I have
>> some time, and I have a few comments.
>> 
>> An assumption in the draft appears to be that the client knows ahead
>> of time what it wants to gain access to and can describe it in detail.
>> For example, the last example in section 2.1 is a client requesting
>> access to particular files, which assumes that the client already
>> knows the paths of the files it wants to access. This in turn seems to
>> imply that the client already has some level of access to be able to
>> determine this, e.g. to list directories, which may not be desirable.
>> In many cases like this I think it’s more natural for the client to
>> not know exactly what it is asking for but instead to want access to
>> *some* file, chosen by the user. An example of this is the Dropbox
>> Chooser [1] and Saver [2] APIs, which notably are not built on top of
>> OAuth. In these cases it would be more natural for the client to send
>> a more generic request and for the details to be filled in by the user
>> as part of the consent process.
>> 
>> Another issue is that as far as I can see in the current draft, any
>> client can initiate a rich authorization request at any time without
>> any kind of prior approval. This seems problematic for the main
>> example in the draft, i.e. payment initiation. As an attacker, if I
>> can get a consent screen up on a user’s device requesting to move
>> money around then it seems like half my job is already done - some
>> fraction of users will probably approve such a transaction without
>> properly checking it. It feels like the ability to ask for transaction
>> approval should already be a privileged operation that should require
>> consent and approval.
>> 
>> A related issue is that each approval is in effect a completely
>> isolated incident. In a normal OAuth2 interaction I would grant an app
>> some longish-term access to data and it would get an access token and
>> optionally a refresh token. At some later point I can go to the AS and
>> see that I have granted this access and revoke it if I choose. With
>> RAR there is no representation of a long-term relationship between the
>> RO and the client and each transaction starts from fresh. Again, this
>> seems potentially problematic and not quite in keeping with how OAuth
>> currently operates. Each grant of access is ephemeral. (Do refresh
>> tokens make sense in the context of RAR?)
> 
> The original motivation for RAR was indeed transactions, which require
> parameters, and this class of use cases do typically imply "ephemeral"
> access (single-use token).
> 
> But nothing precludes RAR from being used for long term access (with a
> refresh token) and there are one or two simple examples in the spec
> which can be interpreted as such.
> 
>> 
>> I think a better approach would be a two-phase authorization process:
>> 
>> 1. In step 1 an app gets a normal long-lived access and/or refresh
>> token that grants it permissions to ask to initial transactions (RARs)
>> - e.g. with scope initiate_payments
>> 2. In step 2 the app requests authorization for individual
>> RARs/transactions using some proof of its grant from step 1
> 
> Such a two-phase authorisation can make good sense in cases when user
> trust needs to be built up.
> 
> Mentioning this and / or some other pattern can be useful, but I don't
> think we should make this normative for RAR, because there can well be
> use cases which won't need this.
> 

Do you have any examples? 

I think this is something the draft needs to address. 

Neil