> -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf > Of Toby White > Sent: Sunday, February 20, 2011 8:12 AM > To: OAuth Mailing List > Subject: [OAUTH-WG] OAuth2 queries > > Some more OAuth2 queries (based on reading -13) > > * There's no direct indication of expected behaviour after a failed attempt to > refresh a token. Since a refresh_token workflow is an example of issuing an > access token, should I read the error behaviour describe in 5.2 as applying to > section 6 as well?
" If the request failed verification or is invalid, the authorization server return an error response as described in Section 5.2." > * Can I read throughout the spec, that wherever scope is an OPTIONAL > parameter, I can read a request with an absent scope parameter as being > equivalent to a request with a scope="" (empty string) parameter? Yes, but an empty string doesn't necessarily means no scope. That's implementation specific. There is no definition of default scope and I would expect most services to define it as something other than nothing. > * In 4.2.2 (implicit grant, response from the auth server), the response > includes an OPTIONAL scope parameter, whose definition includes > > " The authorization server SHOULD include the parameter if the requested > scope is different from the one requested by the client." > > I'm not quite sure I'm reading this correctly, but I think that implies that > if the > client requests scope A, the server can actually grant scope B. > > - is it required/suggested that scope B be a subset of scope A? No. The client can ask for oranges and you give it apples. > - is it true of any other workflows that a client requesting one scope can > actually be granted another scope? Yep. That's implementation specific. EHL _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
