How to handle refresh token requests when the RO revokes specific scopes?

[aaronpk]

from Vittorio:

On the identical scopes requirement. Say that after obtaining RT1, which includes scopes s1 and s2 for client c1, the RO revokes authorization for c1 to use s2. Should the AS fail the RT redemption, or return an AT with only s1 and a scopes parameter informing the client of the change? As developer I would prefer the latter, to preserve the experience: but if we are adamant about the current language, I think it might be useful to explicitly call out that any changes to the grant on the AS side should result in failure of the RT redemption.

[tlodderstedt]

I'm in favor of retaining the RT but reduce its scope. The token response shall return the adjusted scope value.

I don't see a value in revoking the RT in this case. This would force the RO to go through the authorization process again. If that's the intended behaviour, the AS should directly revoke the grant and the RT(s) instead of modifying the scope of the grant, which in turn causes a RT revocation ....

I also suggest to change section 5.1. to require the scope response parameter.

[aaronpk]

The refresh token grant response now more clearly extends the base access token response with the refactoring of the grants into the new structure, so scope is more obviously listed as a possible property in the response to a refresh token grant.

One thing it could be useful to clarify is that if the AS does return an access token with less scopes, then it should return the scope parameter in the response. I believe this is already technically required, but not explicitly spelled out. Currently the AS MUST return the scope in the response if it's different from what the client requests. If the client doesn't include a scope parameter in the request, then the client is implicitly requesting the same scope as the previous refresh token has, so if the AS returns an access token with less scope that would be considered less than the client requested.

[aaronpk]

This also goes in the new scope section (#159), and we can call out several different situations by which the token issued may have different scopes than what was requested: both different from the scopes in the authorization request as well as different from the scopes in a refresh token request. (If the RO revokes a particular scope, then the refresh token previously issued will have different scopes than the new access token returned, so the "scope" parameter will be required in the token response.)