Skip to main content

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

Yes

(Barry Leiba)
(Stephen Farrell)

No Objection

(Brian Haberman)
(Gonzalo Camarillo)
(Martin Stiemerling)
(Ron Bonica)
(Russ Housley)
(Stewart Bryant)

Note: This ballot was opened for revision 24 and is now closed.

(Barry Leiba; former steering group member) Yes

Yes (for -25)

                            

(Stephen Farrell; former steering group member) Yes

Yes (for -24)

                            

(Adrian Farrel; former steering group member) (was Discuss) No Objection

No Objection (2012-05-03 for -26)
I've cleared my Discuss. Thanks for email conversations and changes to address my Discuss

(Benoît Claise; former steering group member) No Objection

No Objection (2012-04-10 for -25)
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?)

(Brian Haberman; former steering group member) No Objection

No Objection (for -25)

                            

(Gonzalo Camarillo; former steering group member) No Objection

No Objection (for -25)

                            

(Martin Stiemerling; former steering group member) No Objection

No Objection (for -25)

                            

(Pete Resnick; former steering group member) No Objection

No Objection (2012-04-11 for -25)
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?

(Ralph Droms; former steering group member) No Objection

No Objection (2012-04-10 for -25)
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.

(Robert Sparks; former steering group member) No Objection

No Objection (2012-04-11 for -25)
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

(Ron Bonica; former steering group member) No Objection

No Objection (for -25)

                            

(Russ Housley; former steering group member) No Objection

No Objection (for -25)

                            

(Sean Turner; former steering group member) (was Discuss) No Objection

No Objection (2012-06-13 for -27)
Thank you for addressing my discusses.

spt

(Stewart Bryant; former steering group member) (was Discuss) No Objection

No Objection (for -27)

                            

(Wesley Eddy; former steering group member) No Objection

No Objection (2012-04-03 for -25)
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"