The OAuth 2.0 Authorization Framework
draft-ietf-oauth-v2-31

I've cleared my Discuss. Thanks for email conversations and changes to address my Discuss

I read: 
   This specification replaces and obsoletes the OAuth 1.0 protocol described
   in RFC 5849.

I've not been familiar with OAuth, and one question that bothered me: Why should I implement/upgrade to OAuth 2.0, compared to 1.0? It's not mentioned in the draft. I had to search somewhere to find the answer: in the current charter, which says:

  In April 2010 the OAuth 1.0 specification, documenting pre-IETF work,
  was published as an informational document (RFC 5849). The working
  group has since been developing OAuth 2.0, a standards-track version
  that will reflect IETF consensus.  Version 2.0 will consider the
  implementation experience with version 1.0, a discovered security
  vulnerability (session fixation attack), the use cases and
  functionality proposed with OAuth WRAP [draft-hardt-oauth-01] and will
  * improve the terminology used,
  * consider broader use cases,
  * embody good security practices,
  * improve interoperability, and
  * provide guidelines for extensibility.


Adding at least the first two sentences (or something similar) + one about the "discovered security vulnerability" would make sense, at least to me... Unless this specified in a different document (maybe I-D.ietf-oauth-v2-threatmodel?)

4.3.2 says that the authorization server MUST "validate the resource owner password credentials", but it doesn't say exactly how one might do that. For example, it doesn't say whether to compare things case-sensitively or (and this is the reason it even occurred to me) whether one should be normalizing the UTF-8. I'm fine with that being left as an exercise to the reader if this is the common practice in security protocols. And UTF-8 doesn't make this special; even comparing US-ASCII has it's quirks. The UTF-8 just made it noticable to me.

8: Just confirming that you are OK with the following legal ABNF productions:

type-name and param-name could each be "...---..."
response-name could be "_____"
error-code could be "z...---..."

Those all OK productions?

I came to a similar conclusion as Benoit: readers of this
document would benefit from a one-paragraph summary
of the reasons for the development of Oauth 2.0.  A summary
or overview of technical differences would be helpful,
as well, if it's not too lengthy.

I also agree with Stewart's DISCUSS regarding the adoption
of modified RFC 5226 review processes rather than reusing
existing processes.

Please consider the following substitutions for the websites and email lists pointed to in section 11.1:

http://www.iesg.org -> http://www.ietf.org/iesg

iesg@iesg.org -> iesg@ietf.org

Thank you for addressing my discusses.

spt

In section 1, right before 1.1 begins, HTTP is called a transport protocol.  While this tends to happen, it still isn't correct.  It would be better to reword the sentence replacing:
"with any other transport protocol"
to something more like:
"over any other protocol"