Thanks for asking, Martin. That's effectively what the spec does already. It restricts the input values of these parameters to be quoted strings containing no backslashes. As long as that syntax restriction remains in place, it wouldn't actually matter whether the BNF for "scope", "error", "error_description", and "error_uri" continues to be defined as "quoted-string", is defined as "token / quoted-string", per HTTPbis, or defined by referencing the HTTPbis "auth-param" definition and containing no parameter-specific BNF declarations. The meaning of the spec would remain the same. It's written the way it is, at present, because it would seem to be clearer to implementers what the restrictions are by using the "quoted-string" BNF production, rather than by imposing the restriction only in prose. But if deleting the BNF definitions and leaving the syntax restrictions in the prose would resolve this issue for people, I'm pretty sure the working group would be fine with that, as it would be a non-normative change. Best wishes, -- Mike -----Original Message----- From: Martin Rex [mailto:mrex@xxxxxxx] Sent: Tuesday, January 24, 2012 4:29 PM To: Mike Jones Cc: ietf@xxxxxxxx; iesg@xxxxxxxx; oauth@xxxxxxxx Subject: Re: [OAUTH-WG] Last Call: <draft-ietf-oauth-v2-bearer-15.txt> (The Mike Jones wrote: > > 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 [...] I'm slightly confused... Instead of inappropriately re-specifying the WWW-Authenticate:, how about referencing the original specification an rules, and then add your desired requirements for *creation* of the contents on top of that, so that oauth-bearer can permit recipients to reject stuff that doesn't fit the additional "send-requirements" when processing the request. I would assume that pretty much all authentication schemes will effectively require subsetting of what can be conveyed to what they can parse, and further subset this to what they can successfully verify, and reject everything else -- without having to rewrite the WWW-Authenticate syntax. -Martin _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf