The OAuth 2.0 Authorization Framework: Bearer Token Usage
draft-ietf-oauth-v2-bearer-23

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?

(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).

Thank you for addressing my discusses.

spt

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.