The OAuth 2.0 Authorization Framework
draft-ietf-oauth-v2-31
Yes
No Objection
Note: This ballot was opened for revision 24 and is now closed.
(Barry Leiba; former steering group member) Yes
(Stephen Farrell; former steering group member) Yes
(Adrian Farrel; former steering group member) (was Discuss) No Objection
I've cleared my Discuss. Thanks for email conversations and changes to address my Discuss
(Benoît Claise; former steering group member) No Objection
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
(Gonzalo Camarillo; former steering group member) No Objection
(Martin Stiemerling; former steering group member) No Objection
(Pete Resnick; former steering group member) No Objection
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
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
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
(Russ Housley; former steering group member) No Objection
(Sean Turner; former steering group member) (was Discuss) No Objection
Thank you for addressing my discusses. spt
(Stewart Bryant; former steering group member) (was Discuss) No Objection
(Wesley Eddy; former steering group member) No Objection
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"