Re: [OAUTH-WG] Possible alternative resolution to issue 26

[Julian Reschke <[e-mail]>]

On 2011-10-07 16:15, Manger, James H wrote:
>> Option 3 has a serious flaw in that it requires escaping the "\" in
>> "\uNNNN", because it is the escape character in quoted-string. I think
>> it's certain that people will be confused by that, and interop problems
>> will happen (unless you have a strong test suite).
>
> No, the "\" in "\uNNNN" would not be escaped.
> The intention with adopting json-string would be to *replace* quoted-string.

You can't "replace" quoted-string.

A recipient will have to be able to parse multiple challenges in a 
single header field value. To do so, it has to understand the syntax of 
params using double quotes. It can't special-case the parsing based on 
what part of the set of challenges it currently is looking at (because 
to do so, it needs to have parsed them first).

> I suggested this was ok as json-string is backward compatible
> with quoted-string. That is not strictly true.
> While json-string decodes "\u00E8" to a single char "è",
> quoted-string decodes it to the 5 chars "u00E8".

Indeed.

> This clash, however, may only be theoretical.
> It is totally pointless to escape "u" as "\u" in a
> quoted-string. I can confidently say it will never
> have been done legitimately. If it does occurs in the wild,
> 99% of cases will be because the sender forgot to escape
> the slash; and 99% of the remaining 1% will be because
> a malicious sender is trying to bypass a security check by
> escaping a char that the software never anticipated would
> be escaped.

But that's how quoted-string is defined, and what a conforming parser 
will do.

If your suggestion is to change that, you will have to bring that up in 
the HTTPbis WG, not here.

> Quoted-string allows 93 ASCII chars to be used as themselves,
> and defines an escaping mechanism to add 2 more chars:
> double-quote and backslash (the escape char itself).
> An escape mechanism to support the last ASCII visible char
> might have been useful in an ASCII world, but it is pointless
> today if it doesn't allow the other 100,000 Unicode chars.

But that argument doesn't change the fact how it is defined.

If we were free to change things, we'd simply state that everything is 
UTF-8.

> If we specify json-string for a field specified elsewhere as
> quoted-string I suspect we will get lucky and solve our Unicode
> issue without causing any actual problems. That is partly
> because I don't think most/many OAuth HTTP clients use
> frameworks that automatically decode quoted-string values
> in their bowels. Do others who write HTTP clients have
> experience to the contrary?

As I said above: a recipient needs to parse header field values that 
contain multiple challenges, and changing the syntax for "quoted-string" 
based on where the param appears is simply a non-starter.

> I prefer option 3 (of the 3), perhaps with a note in the
> spec saying: "Specifying json-string is a wilful violation
> of RFC 2617 that uses quoted-string. It is done to
> add support for Unicode values while supporting all valid
> quoted-string values that occur in practise."

Yes, it would be a willful intentional violation, without - IMHO - a 
strong technical argument to do so. I sure hope the IESG wouldn't accept 
that.

Best regards, Julian