I fully agree with Julian's perspective. I believe there is sufficient feedback requiring further review of this issue. If the editor cannot facilitate a path forward, I request the chairs to intervene. I will make sure this feedback is fully applied to the MAC token specification in the next draft. EHL > -----Original Message----- > From: oauth-bounces@xxxxxxxx [mailto:oauth-bounces@xxxxxxxx] On Behalf > Of Julian Reschke > Sent: Tuesday, January 24, 2012 3:24 PM > To: ietf@xxxxxxxx > Cc: The IESG; oauth@xxxxxxxx > Subject: Re: [OAUTH-WG] Last Call: <draft-ietf-oauth-v2-bearer-15.txt> (The > OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard > > On 2012-01-23 16:58, Julian Reschke wrote: > > On 2012-01-23 16:46, The IESG wrote: > >> > >> The IESG has received a request from the Web Authorization Protocol > >> WG > >> (oauth) to consider the following document: > >> - 'The OAuth 2.0 Authorization Protocol: Bearer Tokens' > >> <draft-ietf-oauth-v2-bearer-15.txt> as a Proposed Standard ... > > > > Please see my comments in > > <https://www.ietf.org/mail-archive/web/oauth/current/msg08120.html> > > which I think have not been addressed. > > ... > > In an off-list conversation I heard that what I said before may not be as clear > as it could be. > > So... > > 1) draft-ietf-oauth-v2-bearer-15 defines a new HTTP authentication scheme. > > 2) In the IANA considerations, it references the registration procedure > defined in <http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-17#section- > 2.3> > (now -18, but that doesn't matter here). > > 3) That document recommends in > <http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-17#section-2.3.1>: > > o The parsing of challenges and credentials is defined by this > specification, and cannot be modified by new authentication > schemes. When the auth-param syntax is used, all parameters ought > to support both token and quoted-string syntax, and syntactical > constraints ought to be defined on the field value after parsing > (i.e., quoted-string processing). This is necessary so that > recipients can use a generic parser that applies to all > authentication schemes. > > 4) draft-ietf-oauth-v2-bearer-15 ignores this recommendation. It has been > mentioned that it might not have ignored it if it had UPPERCASE > requirements, but in HTTPbis we try to restrict BCP14 keywords to the actual > protocol, not on recommendations on other specs. > > 5) The registration requirement for a new scheme is "IETF review", which RFC > 5226 defines in <http://tools.ietf.org/html/rfc5226#section-4.1> as: > > IETF Review - (Formerly called "IETF Consensus" in > [IANA-CONSIDERATIONS]) New values are assigned only through > RFCs that have been shepherded through the IESG as AD- > Sponsored or IETF WG Documents [RFC3932] [RFC3978]. The > intention is that the document and proposed assignment will > be reviewed by the IESG and appropriate IETF WGs (or > experts, if suitable working groups no longer exist) to > ensure that the proposed assignment will not negatively > impact interoperability or otherwise extend IETF protocols > in an inappropriate or damaging manner. > > In this case the WG exists (it's HTTPbis), and the OAuth got two reviews from > HTTPbis pointing out the problem -- from Mark Nottingham, the WG chair, > and myself, one of the authors. > > And yes, I believe the way OAuth defines the syntax *will* impact > interoperability. > > Also, I haven't seen any explanation why OAuth can not follow the > recommendation from HTTPbis. > > Hope this clarifies things, > > Julian > _______________________________________________ > OAuth mailing list > OAuth@xxxxxxxx > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf