Comments on Auth 2.0 - Pre-Draft 11
Johannes Ernst
jernst+openid.net at netmesh.us
Sat Dec 16 06:19:57 UTC 2006
Well, I would think it depends on the underlying data type.
For example, for plain-text strings, there's really no need to define
more than one escaping mechanism.
If somebody wants to encode a GIF picture, this may be different, and
I agree we can't hope to enumerate all possibilities. But that might
not be needed.
I just would hate it if we all had to "guess" whether somebody's "abc
\ndef" was supposed to be rendered as that, or in two lines.
On Dec 15, 2006, at 16:08, Josh Hoyt wrote:
> On 12/11/06, Johannes Ernst <jernst+openid.net at netmesh.us> wrote:
>> >> Section 4.1.1 - Key-Value Form Encoding
>> >>
>> >> If in the key-value form, I wish to transmit a value that includes
>> >> a '\n', what am I supposed to do?
>> >
>> > Encode it such that it doesn't have a '\n' in it, e.g using base64.
>> > If '\n' was allowed, the protocol would permit the kind of attack
>> > described in this thread:
>> > http://openid.net/pipermail/specs/2006-November/000901.html
>>
>> I understand that is one possible fix. What about we define one of
>> the possible fixes as the "canonical" fix for text data, otherwise
>> different implementors will implement different fixes (base64, C-
>> style \n, URL-style %0D%0a, ... ) and interop will suffer.
>
> I'm uncomfortable defining an escaping mechanism when there are
> different possibilities that are appropriate for different contexts. I
> think that extension authors will define an appropriate scheme for the
> problem that they are solving (e.g. if it's binary data, use base64),
> and everyone who is using that extension will use that same encoding,
> so there will not be interoperability issues.
>
> If there were multiple extensions defining escaping mechanisms today,
> and they agreed, then I might agree to specify one, but there are not,
> so I'd rather leave it open.
>
> Josh
More information about the specs
mailing list