> 4.1.2. Authorization Response: Comment "The language around scopes in
> the document is really frustrating. One only finds out much later in the > document that it is perfectly allowable for an authorization server to more or > less ignore what scopes are submitted and instead to just return whatever > the hell they want. This is a fine design choice but it seems like the sort of > thing that should be forcefully repeated anywhere in the spec that we allow > people to submit scopes so nobody forgets." Added new section and changed all duplicate definitions of 'scope' to reference it: 3.3. Access Token Scope The authorization and token endpoints allow the client to specify the scope of the access request using the "scope" request parameter. In turn, the authorization server uses the "scope" response parameter to inform the client of the scope of the access token issued. The value of the scope parameter is expressed as a list of space- delimited, case sensitive strings. The strings are 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 MAY fully or partially ignore the scope requested by the client based on the authorization server policy or the resource owner's instructions. If the issued access token scope is different from the one requested by the client, the authorization server SHOULD include the "scope" response parameter to inform the client of the actual scope granted. EHL
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
