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

[Neil Madden <[e-mail]>]

> On 9 Jul 2020, at 09:53, Vladimir Dzhuvinov <[e-mail]> wrote:
> On 09/07/2020 11:07, Neil Madden wrote:
>> 
>>> 
>>> 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. 
> The ability to reference an existing grant is a general problem with OAuth.
> 
> The grant management draft has a "grant_id" parameter which can be used to reference prior consent. I suppose to reference prior consent as context only a new grant_management_mode may be needed.
> 
> https://bitbucket.org/openid/fapi/src/master/Financial_API_Grant_Management.md <https://bitbucket.org/openid/fapi/src/master/Financial_API_Grant_Management.md>
> We also have OAuth Incremental Authorization, which references a refresh token:
> 
> https://tools.ietf.org/html/draft-ietf-oauth-incremental-authz-04 <https://tools.ietf.org/html/draft-ietf-oauth-incremental-authz-04>
> 
Thanks, these are useful references. The grant_id approach could work. Incremental authZ is an interesting comparison, but in that case the new grant replaces the old one, whereas in transactional auth each grant is separate. Another potential issue is that the proof of the existing grant is only presented at the token endpoint, after the flow has completed. Although this does stop the kind of attacks I was worried about, it would be better to check this up front if possible. That’s certainly an interesting reference though, and one I hadn’t considered before in this context, so thanks for mentioning it.

I think I prefer an approach using PAR, with the following additions/modifications:

1. Ability to make PAR mandatory for approval of some scopes and/or for particular clients (determined by AS policy).
2. Ability to authorize the call to the PAR endpoint using an access token instead of client authentication.
  - AS policy can decide what type of authorization is required for a particular request: user-approved access token, client_credentials access token (i.e., current OB UK), or direct client authentication.
3. If a user-approved AT is used in step 2, then the AS MUST ensure that the same user is involved in the subsequent authorization flow.

There is precedent for step 2 - e.g., token introspection currently allows an access token instead of client authentication.

If RAR was then updated to discuss this issue in the security considerations (or elsewhere) with a reference to these features of PAR then I think I would be pretty happy with that.

— Neil