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:[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
