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?)
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
I have ideas for how this could be achieved, but I’d prefer to see what others
think of this general idea rather than getting bogged down in specific details.
[1]: https://www.dropbox.com/developers/chooser
<https://www.dropbox.com/developers/chooser>
[2]: https://www.dropbox.com/developers/saver
<https://www.dropbox.com/developers/saver>
— Neil
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
