[email protected] wrote:
> > 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?
>
> 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
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
