The OAuth 2.0 Authorization Framework: Bearer Token Usage
RFC 6750
Yes
No Objection
Note: This ballot was opened for revision 17 and is now closed.
(Barry Leiba; former steering group member) Yes
(Stephen Farrell; former steering group member) Yes
(Adrian Farrel; former steering group member) No Objection
(Benoît Claise; former steering group member) No Objection
(Brian Haberman; former steering group member) No Objection
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?
(Gonzalo Camarillo; former steering group member) No Objection
(Martin Stiemerling; former steering group member) No Objection
(Pete Resnick; former steering group member) (was Discuss, No Objection) No Objection
(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).
(Ralph Droms; former steering group member) No Objection
(Robert Sparks; former steering group member) No Objection
(Ron Bonica; former steering group member) No Objection
(Russ Housley; former steering group member) (was Discuss, No Objection, Discuss) 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) No Objection
(Wesley Eddy; former steering group member) No Objection
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.