The OAuth 2.0 Authorization Framework: Bearer Token Usage
Note: This ballot was opened for revision 17 and is now closed.
(Stephen Farrell) Yes
Barry Leiba Yes
(Ron Bonica) No Objection
(Stewart Bryant) No Objection
(Gonzalo Camarillo) No Objection
(Benoît Claise) No Objection
(Ralph Droms) No Objection
(Wesley Eddy) No Objection
Comment (2012-04-03 for -18)
In Section 1, I suggest changing: "for use with other transport protocols" to something more like: "for use over other protocols". HTTP is not a transport protocol.
(Adrian Farrel) No Objection
(Brian Haberman) No Objection
Comment (2012-04-02 for -18)
Section 2.1 states : Clients SHOULD make authenticated requests with a bearer token using the "Authorization" request header field with the "Bearer" HTTP authorization scheme. Is the SHOULD simply to show a preference for the Authorization request approach over the methods defined in Sections 2.2 and 2.3? If so, in what type of situation would the Authorization request approach not be used?
(Russ Housley) (was Discuss, No Objection, Discuss) No Objection
(Pete Resnick) (was Discuss, No Objection) No Objection
Comment (2012-06-28 for -21)
(I understand that the W3C has review use of the access_token as a general query parameter. Thanks for taking care of that.) In section 2.3, the new last paragraph starts: This method is included to document current use; its use is NOT RECOMMENDED... NOT RECOMMENDED is not defined by 2119, and the language is redundant with the previous paragraph and potentially confusing. I suggest replacing it with simply: This method is included to document current use; as indicated in the previous paragraph, the use of this method is not recommended... BTW: The "SHOULD NOT unless..." in the previous paragraph is itself redundant. I think you mean "MUST NOT unless...". SHOULD NOT *means* MUST NOT unless you understand what you're doing. Mark Nottingham's Applications Area review <http://www.ietf.org/mail-archive/web/apps-discuss/current/msg03805.html> has a couple of comments that I think deserve further reply: * Section 1: Introduction The introduction explains oauth, but it doesn't fully explain the relationship of this specification to OAuth 2.0. E.g., can it be used independently from the rest of OAuth? Likewise, the overview (section 1.3) seems more specific to the OAuth specification than this document. As I read it, this mechanism could be used for ANY bearer token, not just one generated through OAuth flows. If it is indeed more general, I'd recommend minimising the discussion of OAuth, perhaps even removing it from the document title. I agree that the title would be better simply as "HTTP Bearer Tokens", and then explain in the Abstract and Intro that the motivation and intended use of these Bearer Tokens is the OAuth 2.0 specification. A possibly useful side effect of this change might be that you can make OAuth 2.0 an informative (as against a normative) reference, and that these things could be reused for other purposes in the future. Not a huge deal, but I (like Mark) was unconvinced that the reference to OAuth in the title was necessary. * Section 3 The WWW-Authenticate Response Header Field The difference between a realm and a scope is not explained. Are the functionally equivalent, just a single value vs. a list? Some text, and probably an example, might help explain this a bit better. One of his comments asked for some additional review. I don't have a personal opinion whether this is needed, but perhaps you should pursue this: * General The draft currently doesn't mention whether Bearer is suitable for use as a proxy authentication scheme. I suspect it *may*; it would be worth discussing this with some proxy implementers to gauge their interest (e.g., Squid).
(Robert Sparks) No Objection
(Martin Stiemerling) No Objection
(Sean Turner) (was Discuss) No Objection
Comment (2012-06-13 for -20)
Thank you for addressing my discusses. spt