On 7 Jul 2020, at 21:09, Vladimir Dzhuvinov <[email protected]> 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 _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
