Re: [OAUTH-WG] FW: Pete Resnick's Discuss on draft-ietf-oauth-v2-bearer-20: (with DISCUSS and COMMENT)

[Stephen Farrell <[e-mail]>]

Hi Mike,

As you noted this is under way. When I mailed tlr I
asked for two weeks from the 13th, which co-incides
with the end of the IETF LC caused by the IPR
declaration, so it should be fine.

Cheers,
S.

On 06/18/2012 07:08 PM, Mike Jones wrote:
> Hi Stephen,
> 
> Pete is holding his DISCUSS on Bearer open until the current text on the URI query parameter http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-20#section-2.3 receives W3C review.  Can you try to have that review happen this week, hopefully finishing sometime next week?
> 
> I'm cc:'ing Mark in his role as W3C liaison.
> 
> 				Thanks again,
> 				-- Mike
> 
> -----Original Message-----
> From: Pete Resnick [mailto:[e-mail]] 
> Sent: Tuesday, June 12, 2012 1:40 PM
> To: The IESG
> Cc: [e-mail]; [e-mail]
> Subject: Pete Resnick's Discuss on draft-ietf-oauth-v2-bearer-20: (with DISCUSS and COMMENT)
> 
> Pete Resnick has entered the following ballot position for
> draft-ietf-oauth-v2-bearer-20: Discuss
> 
> When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.)
> 
> 
> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> Mark Nottingham's Applications Area review <http://www.ietf.org/mail-archive/web/apps-discuss/current/msg03805.html>
> identified the issue of URI query parameters in section 2.3: URI query parameters are normally locally scoped. In this document, a query parameter (access_token) is being defined as applying to all URIs. This is (relatively) novel. A few people in the HTTP community (including
> Mark) have expressed concerns. (See also http://www.ietf.org/mail-archive/web/apps-discuss/current/msg04932.html
> and
> http://www.ietf.org/mail-archive/web/apps-discuss/current/msg04933.html
> from the apps-discuss archive.) This issue should probably be further reviewed by W3C folks. I'm holding the DISCUSS as per Stephen to make sure we get that review.
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> 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).
> 
> 
>