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(_at_)sap(_dot_)com]
Sent: Tuesday, January 24, 2012 4:29 PM
To: Mike Jones
Cc: ietf(_at_)ietf(_dot_)org; iesg(_at_)ietf(_dot_)org;
oauth(_at_)ietf(_dot_)org
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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf