[OpenID] XRI TC - An Outsiders perspective

[Tatsuki Sakushima]

> 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.

During the discussion about c14n in the XRI-TC, I tested available canonicalizers in scripting languages. We found Python's one and PHP5's one works fine with XMLDsig(requires exclusive canonicalization) of SAML assertions. Python's one is purely written in that language and can be written in other languages. PHP5's one seems to count on libxml2 but the wrapper is included in PHP5 if it is compiled with that option. I think most versions of PHP5 support it. We are missing Ruby's one now. Our team try to export Python's canonicalizer to Ruby and create a libxml2 wrapper for Ruby. For performance, using libxml2 is much faster. Therefore we want to provide both options for Ruby developers.

So, I just want to inform some works are ongoing in the XRI community to ease pain of XMLDSig for the OpenID community.

Tatsuki Sakushima
NRI Pacific - Nomura Research Institute America, Inc.


(7/13/09 7:38 AM), John Bradley wrote:
> 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
>>
> 
> _______________________________________________
> general mailing list
> general at openid.net
> http://openid.net/mailman/listinfo/general
>