All in all, I like the new structure of the document.  Below are a few
editorial nits and questions.

http://tools.ietf.org/html/draft-ietf-oauth-v2-12#section-1.4 > The
diagram has "Access Grant" but it seems like the rest of the draft is
now using "authorization grant" as per section 1.3?

http://tools.ietf.org/html/draft-ietf-oauth-v2-12#section-2 > Should
"credentials include a client identified" read "credentials include a
client identifier"?

http://tools.ietf.org/html/draft-ietf-oauth-v2-12#section-3.2 > "The
token endpoint requires client authentication as described in Section
2 ." no space before the period?

A more general question is that while section 2 clearly allows for
unauthenticated client requests to the token endpoint, the text above,
if read without consulting section 2, sounds like client
authentication is strictly required.  There are a few other places in
the spec that are similar too.  I honestly don't know if that's a
problem or not.  But I do know from experience that implementers,
vendors, customers, etc. will sometimes focus in on a single line like
that and not consider the larger context (even if it's directly
referenced like it is there).

http://tools.ietf.org/html/draft-ietf-oauth-v2-12#section-4.1.2.1 >
maybe it's just me but some more white-space between parameter
definitions would make this section easier on the eyes.  Same for
4.2.2.1 & 5.2

http://tools.ietf.org/html/draft-ietf-oauth-v2-12#section-4.1.3 > I
think someone might have said this already but the language about
redirect_uri here doesn't seem to match up exactly with what is in
other sections.   I.e. if a redirect_uri wasn't sent in the initial
authorization request, what should be sent here?  Nothing? The
preregistered value?  Something else?
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Reply via email to