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:[email protected]]
Sent: Tuesday, June 12, 2012 1:40 PM
To: The IESG
Cc: [email protected]; [email protected]
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).
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
