Subject: [OAUTH-WG] determine scope for Auth Code Grant

From: Lee Coltrane <[email-masked]>
Date: Tue, 4 Sep 2012 23:09:57 -0400

(looking at v31 of the draft [1])

In "Authorization Code Grant" (section 4.1), when the ResourceOwner
authorizes a `scope` that differs from the `scope` the Client requested, 
how does the Client find out the modified scope value?

"Implicit Grant" addresses this by including a `scope` parameter in the 
Authorization Token Response (4.2.2).  So this is not a problem for the 
Implicit grant type.

But "Authorization Code Grant" defines no such parameter for its 
Authorization Response (4.1.2).  Also, nothing equivalent in the 
subsequent Access Token Response (4.1.4). 

I'm new to the list, so if this has been discussed previously, or if 
I'm missing something obvious, please just point me in the right 
direction.

Otherwise, I would propose the addition of `scope` as a response 
parameter in 4.1.2 (Authorization Response), for the purpose of 
communicating, to the Client, the actual granted scope value, which 
could be different from the requested scope value.  It should behave 
the same as the `scope` response parameter defined for the Implicit 
Grant's "Access Token Response" in section 4.2.2.

-Lee

[1]: http://tools.ietf.org/html/draft-ietf-oauth-v2-31

---

From: [email-masked]
Date: Wed, 5 Sep 2012 13:37:02 +0800

> how does the Client find out the modified scope value?
The scope is sent in the access token. 

> Authorization Token Response (4.2.2).  So this is not a problem for the 

Implicit grant is different from authorization request in "authorization 
code grant",
the former is for access token, the latter is for authorization code which 
is exchanged further for access token
> subsequent Access Token Response (4.1.4). 
There is scope included in seciotn 5.1. 
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: Lee Coltrane <[email-masked]>
Date: Wed, 5 Sep 2012 21:41:50 -0400

> The scope is sent in the access token. 
...
> There is scope included in seciotn 5.1.   

Ah, I see. Thanks for the reply.

I think it would add clarity if there were a section that explicitly 
defined the token as an abstract entity, separate from the various 
serializations, encodings, and transports used to send it.  

  token := { access_token, token_type, expires_in, refresh_token, scope }

Section 5.1 is close, but the definition of the token attributes is all 
tangled up with discussion of JSON encoding and the HTTP response headers. 
It defines an abstraction at the message level, but not at the data 
structure level.

Section 5.1 accurately communicates that several different grant-types use
a similar messaging mechanism based on JSON+HTTP.  But it fails to 
communicate the fact that *all* grant-types (even the "implicit grant")
will ultimately return the same basic set of token attributes -- even if
the message encodings and transports may differ from type-to-type.

IMHO, both points are important to understanding the spec, and the spec
can benefit by making each point clearly and unambiguously. 

-Lee

---

From: Justin Richer <[email-masked]>
Date: Fri, 7 Sep 2012 10:01:39 -0400

> can benefit by making each point clearly and unambiguously.
I rather like this idea, especially since the alternate-encodings draft 
that I've put out could really make use of an abstract data structure 
instead of relying on a from-json transformation:

   http://tools.ietf.org/html/draft-richer-oauth-xml-01

Obviously, it's far too late in the process to make that deep of an 
editorial change to the OAuth2 core. However, if OAuth 2.1 ever turns 
into a thing (or if there's some other process for a deeper revision), 
then I think this is a prime candidate for improving the clarity of the 
spec.

  -- Justin