On 2011-10-20 17:33, Mike Jones wrote:
By design, implementations can use existing quoted-string parsers, as these
accept and correctly process all legal scope values.
The spec is silent on what to do with illegal values, such as those containing \ or
those not surrounded by ". Conforming implementations will not produce such
values, and so there's no actual problem in practice, whether you use an
off-the-shelf parameter parser or one specific to the Bearer scheme.
...
Conforming implementations can produce WWW-Authenticate header fields
containing quoted-strings containing escapes. This is under the
jurisdiction of the HTTP spec, not the OAuth spec.
OAuth can profile the legal values *just* for the OAuth scheme, but
consumers will still need to be able to process a header field that
contains multiple challenges from schemes != OAuth, and to do so, they
*have* to use a proper parser.
Consider the following challenge:
WWW-Authenticate: foo realm="x", title="my \"test\" site", oauth
realm="y"
A component that handles WWW-Authenticate absolutely has to rely on
predictable syntax for quoted strings. It doesn't make any sense to
special-case OAuth params just because escaping isn't needed. This makes
things harder and more likely to fail, not simpler.
Best regards, Julian
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
