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