Per the discussion at http://www.ietf.org/mail-archive/web/oauth/current/msg08040.html, the working group's rationale for supporting quoted-string but not token syntax for these parameters, and for requiring that backslash ('\') quoting not be used when producing them is as follows: "Once again, the current text reflects a consensus decision of the working group. It was viewed that requiring support for multiple ways of doing the same thing unnecessarily complicated implementations without any compensating benefit; better to support one syntax for each semantic operation and require all implementations to use it." Despite Julian's remarks below, the syntax in the Bearer spec *is* compatible with standard parameter parsers, and so no interoperability problems are created by restricting the parameter syntax to a subset of the syntax allowed by HTTPbis. No non-standard code is needed to use parameters in the manner described in the Bearer spec. The current text is the result of thorough and informed discussion among the working group, and reflects the best consensus available as I understand it in my role as editor, attempting to accurately represent the working group's decisions and rationale. Best wishes, -- Mike -----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