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