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 IESG member
Yes
Yes (for -25) Unknown

                            
Stephen Farrell Former IESG member
Yes
Yes (for -24) Unknown

                            
Adrian Farrel Former IESG member
(was Discuss) No Objection
No Objection (2012-05-03 for -26) Unknown
I've cleared my Discuss. Thanks for email conversations and changes to address my Discuss
Benoît Claise Former IESG member
No Objection
No Objection (2012-04-10 for -25) Unknown
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 IESG member
No Objection
No Objection (for -25) Unknown

                            
Gonzalo Camarillo Former IESG member
No Objection
No Objection (for -25) Unknown

                            
Martin Stiemerling Former IESG member
No Objection
No Objection (for -25) Unknown

                            
Pete Resnick Former IESG member
No Objection
No Objection (2012-04-11 for -25) Unknown
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 IESG member
No Objection
No Objection (2012-04-10 for -25) Unknown
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 IESG member
No Objection
No Objection (2012-04-11 for -25) Unknown
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 IESG member
No Objection
No Objection (for -25) Unknown

                            
Russ Housley Former IESG member
No Objection
No Objection (for -25) Unknown

                            
Sean Turner Former IESG member
(was Discuss) No Objection
No Objection (2012-06-13 for -27) Unknown
Thank you for addressing my discusses.

spt
Stewart Bryant Former IESG member
(was Discuss) No Objection
No Objection (for -27) Unknown

                            
Wesley Eddy Former IESG member
No Objection
No Objection (2012-04-03 for -25) Unknown
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"