[Openid-specs-fapi] Issue #139: treatment of returned scopes divergent from RFC 6749 (openid/fapi)

Brian Campbell issues-reply at bitbucket.org
Tue Apr 24 19:45:44 UTC 2018

New issue 139: treatment of returned scopes divergent from RFC 6749

Brian Campbell:

Item 15 in Section 5.2.2 of FAPI part 1 currently says that the authorization server "shall return the list of granted scopes with the issued access token" and FAPI part 2 inherits this in its own section 5.2.2 saying the AS "shall support the provisions specified in clause 5.2.2 of Financial API - Part 1".

While §5.1 of RFC 6749 allows for the scope parameter to be omitted when the scope granted is the same as the scope requested by the client. 

         OPTIONAL, if identical to the scope requested by the client;
         otherwise, REQUIRED.  The scope of the access token as
         described by Section 3.3.

Requiring specific behavior that differs from RFC6749 is probably something that FAPI should avoid unless there's some compelling reason for the difference. And in this case, I'm struggling to see the reason. 

All that I can come up with is that the requested scope could be altered by a bad actor in the user agent before the request is delivered to the AS. Then if all those altered scopes are approved, the AS would consider that identical to the scope requested by the client and omit the scope parameter in the response. In that case the client wouldn't be aware that the scope associated with the token(s) were different than what was requested. 

That seems kinda far fetched though. The user of the user-agent is the resource owner so has no real need or motivation to alter the scope. And CSRF protection (required by FAPI and strongly encouraged by OAuth) should prevent or catch other attempts to alter the scope.

Also JWT/JWS signed requests, which are required by FAPI part 2, prevent the scope in the request from being altered.   

I guess where I'm going with this is suggesting the removal of Item 15 in Section 5.2.2 of FAPI part 1. Or, if there's really good reason to have it there, I'd like to better understand what that is.

More information about the Openid-specs-fapi mailing list