[OAUTH-WG] access/refresh token scope ambiguity

[Andrew Arnott <[e-mail]>]

I was looking at the scenario of using a refresh token to obtain a new
access token, and noticed that in draft 16, Section 5.1 "Successful
Response" describes the scope parameter in a confusing way that suggests a
copy and paste error.  Included below, with [[emphasis added]].

   scope
         OPTIONAL.  The scope of the [[access request]] expressed as a list
         of space-delimited, case sensitive strings.  The value is
         defined by the authorization server.  If the value contains
         multiple space-delimited strings, their order does not matter,
         and each string adds an additional access range to the
         requested scope.  The authorization server SHOULD include the
         parameter [[if the requested scope is different from the one
         requested by the client.]]

Why would the scope parameter in a response includes the scope of the
[[request]]? Particularly in light of what comes [[later]].  Also, how could
the requested scope be different from the one requested from the client.
 The client is the one making the request in the first place.


I'm also wondering if while using a refresh_token to obtain a new access
token, when the auth server has the opportunity to issue a new refresh_token
at the same time that the scope of the refresh token might change.  I would
hope not, but perhaps it may.  Considering the scenario where a client has a
powerful refresh token and wishes to obtain a limited access token (smaller
scope), would the scope parameter in the section 5.1 response match the
scope of the newly issued refresh token or the newly issued access token?
 I'm hoping the spec can be beefed up to remove any ambiguity here.
--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death
your right to say it." - S. G. Tallentyre