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

[Neil Madden <[e-mail]>]

Hi Torsten,

> On 8 Jul 2020, at 17:20, Torsten Lodderstedt <[e-mail]> wrote:
> 
> Hi Neil, 
> 
>> On 8. Jul 2020, at 16:40, Justin Richer <[e-mail]> 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.
>> 
>> 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.
>> 
>> — Justin
>> 
>>>> On Jul 6, 2020, at 12:32 PM, Neil Madden <[e-mail]> 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.
> 
> That’s a very good point.
> 
> There are scenarios where the client knows the resources it wants to interact with in advance, potentially from another transaction (e.g. first access to account list, payment initiation afterwards). 
> 
> The scenario you are describing is viable as well. In such a case, the request would be fairly generic but the AS (or the RS) would need to make transparent to the client what resources it just obtained access for. Interestingly, this might also happen if the client wants to access accounts. It could just request access to accounts and the user, in the consent, selects the accounts to disclose to the client. In our design at yes, we reflect this in an augmented authorization_details object in the token response (an addition for the spec I have on my list). 

Ok, it sounds like this can be incorporated into the draft. 

>>> 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.
> 
> I think RAR will almost always be used in conjunction with PAR. This means the client is authenticated before the user interaction starts preventing the attack you mentioned. I think we should at least recommend this in the draft. 

See other discussion. Client authentication is not the issue here, it’s about user consent. The underlying assumption appears to be that all legitimate clients registered with a bank are trustworthy because of vetting, reputation etc. Even putting aside that issue, as a user, if an app or service acts in a way that I don’t like then I should be able to stop using that app regardless of whether the app has violated any rules. 

In normal OAuth I can always go and revoke a grant to indicate that I no longer use that app/service. In RAR I don’t have that option because every transaction starts from scratch. I’m not arguing that every use of RAR will require this kind of two-phase user authorization approach, but that the current description of RAR seems to preclude using the normal OAuth mechanisms to manage this relationship in the transactional case. If PAR can bridge that gap, it would be good to explicitly call that out.

>>> 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?)
> 
> Some of the use cases initially causing the development of RAR are transactional (as pointed out by Vladimir) others are not. RAR is about a richer vocabulary for describing the scope of access.
> 
> In the beforementioned account information scenario, the client would, for example, ask for read access to several accounts. Access to balance for one and access to balance & transaction history for another account. This could easily be expressed using RAR and would be a long term grant. If the client for the same user asks for access to another account (and the user approves), the AS should add this to the same underlying grant. This effectively means, the client could use the same token (refresh and access token) to access all accounts. 

I am generally against proposals that encourage accumulating authority in a single token, so I’m not convinced this is a good idea. But for the sake of argument, I’ll assume that there are good non-transactional applications 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
> 
> I agree. This is PAR. PAR + RAR is in the end a generalised version of the UK OB consent pattern. 

PAR currently only allows client credentials to authorize requests to the pushed auth endpoint. But what I’m describing would instead use an access token (authorized by the user). This seems closer to what OB currently does, but using a user-approved access token rather than a client_credentials granted one.

There are other approaches, for example based on macaroon 3rd-party caveats. I’ll try to knock up a decent description or demo of the approach because it has some appealing properties. But whatever the implementation, the important thing is that there is some consideration of these issues. 

— Neil