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