[OpenID] XRI TC - An Outsiders perspective

[John Bradley]

Shade,

This is the key reason the XRI-TC backed off trying to come up with a  
way to sign the raw octets and pass the signature out of band.

By the time we had three different formats of detached signatures to  
support all the identified use cases,  a xmldsig based approach  
started looking much more attractive.

We had:
1: Detached file (binds the XRD to a particular transport that may not  
be available and doubles traffic)
2: Send signature in http headers (http specific and not available to  
all RPs )
3: Crate new wrapper element and base64 encode the XRD. (not human  
readable and complicates the non signed option)
4: Form encode the XRD and the signature as a single response.   
(Complicates the non-signed case)

XRD need to independent of transport.   One example is sending a XRD  
that contains private discovery information as the value of a AX  
attribute,  or as part of an XMPP flow.n

Trying to avoid XML c14n ultimately crates more interop and other  
complexities in other parts of the spec.

At the same time for XRD full XML c14n is not required.  Most of the  
complicated stuff is not required.

This is separate from the discussion about how to process the  
signature itself and surrounding trust issues.

It seems reasonable that if XRD c14n can be supported natively in  
scripting languages and by existing XML libraries,  and that the  
resulting format can be used both by signature aware and unaware  
applications that is a better overall solution.

The problem is that no other method we identified could meet all of  
the use cases.

Even when we narrowed it down to just the openID use case we couldn't  
get it down to just one format to support everyones requirements.

John B.

On 13-Jul-09, at 9:10 AM, general-request at openid.net wrote:

> Date: Sun, 12 Jul 2009 14:07:28 -0700
> From: SitG Admin <sysadmin at shadowsinthegarden.com>
> Subject: Re: [OpenID] XRI TC - An Outsiders perspective
> To: Santosh Rajan <santrajan at gmail.com>
> Cc: general at openid.net
> Message-ID: <f06110400c67ffdde2946@[192.168.0.2]>
> Content-Type: text/plain; charset="us-ascii" ; format="flowed"
>
>> Whenever a new technology is released people react in one of two  
>> ways.
>> 1) Awesome! This is so simple. How come we never thought of this?
>> 2) Jeez! This is so complicated! Do I need this?
>
> Or the oft-hushed "1.5) Finally, was wondering when someone would put
> this into production." ;)
>
>> I was suggesting we dont use XMLDSig at all. Maybe we should look  
>> at PKCS7
>> which is available everywhere. Also transporting a signed document  
>> is not a
>> problem if we were to select a proper Content Type.
>
> And then translate "on the spot" every time we need to parse the
> file? In the past, I have had to port a document between multiple
> computers, operating systems, and applications, to get it into a
> readable form, because the final (preferred) reader was not directly
> compatible with the original format. XMLDSig provides a way for each
> layer to translate it to "native" format as needed, without affecting
> the ability of any layer (even the last) to verify its signature
> later on.
>
> -Shade
>