Subject: [OAUTH-WG] OAuth2 queries

From: Toby White <[email-masked]>
Date: Sun, 20 Feb 2011 16:12:10 +0000

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?

* 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?

* 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?
 - is it true of any other workflows that a client requesting one
scope can actually be granted another scope?

Thanks,
Toby

-- 
http://timetric.com
2nd Floor, White Bear Yard, 144a Clerkenwell Road, London EC1R 5DF
phone: +44 20 3286 0677 (office), +44 7747 603618 (mobile)
twitter: @timetric, @tow21 | skype: tobyohwhite

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Sun, 20 Feb 2011 09:38:40 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Toby White
> Sent: Sunday, February 20, 2011 8:12 AM
> To: OAuth Mailing List
> Subject: [OAUTH-WG] OAuth2 queries
> 
> * 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."

> 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.
> 

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

---

From: Toby White <[email-masked]>
Date: Sun, 20 Feb 2011 16:53:59 +0000

Thanks - that all makes sense.

Toby