[OpenID] XRI TC - An Outsiders perspective

[Santosh Rajan]

My comments inline


Nat Sakimura wrote:
> 
> Hi. I am one of the members in XRI TC, who was pressing for more
> simplicity. Having said that, here are my comments inline:
> 
> On Sun, Jul 12, 2009 at 5:24 PM, Santosh Rajan <santrajan at gmail.com>
> wrote:
> 
>>
>> What better way than to spend a rainy sunday morning reading up on the
>> XRI
>> TC
>> mailing list. (This is monsoon/rainy season in my part of the world, have
>> a
>> lot of free time at home this month).
>> I am posting this here because whatever they end up with has a bearing on
>> OpenID if we were to adopt it. Also I think I cannot join that list, its
>> members only. You can read the list here.(June and July).
>> http://lists.oasis-open.org/archives/xri/200906/maillist.html
>> http://lists.oasis-open.org/archives/xri/200906/maillist.html
>> http://lists.oasis-open.org/archives/xri/200907/maillist.html
>> http://lists.oasis-open.org/archives/xri/200907/maillist.html
>>
>>
>> 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?
>>
>> My hope was that we would get (1) as a reaction when XRD is released.
>> After
>> all the very reason for adopting XRD vis a vis XRDS was that XRD was
>> going
>> to be simple. But that is not the impression you will get after reading
>> what
>> is going on there. Looks like we are headed for (2) as the reaction from
>> folks when this is released. Looks to me this is going to be more
>> complicated than XRDS!
>>
>> Now this is not to suggest that the arguments posed in those lists are
>> not
>> valid. On the contrary indeed all those arguments are valid. But the
>> question is, if XRD was supposed to be something simple, do we need to
>> make
>> those arguments at all?
>>
>> I will elaborate on three cases here.
>>
>> First is the argument of XMLDSig. If XMLDsig has had interop problems for
>> 11
>> years, and you still need to test it before you adopt it, it is about
>> time
>> you dumped it!
> 
> 
> I was pushing for a very simple Signing
> method but people did not want to invent yet another signing method
> for XML. Thus, I and my colleague Tatsuki made some research on the
> implementation issues there. What we have found out was that, if we
> stick to the Exclusive c14n, it works OK for Java, Python, PHP. It
> does not for Ruby, so we need to make a decent library for it. The
> same is probably true for Perl. For
> Python, there was a pure Python library, so it will probably work for GAE
> as
> well.
> 
> The reason why TC decided to use this constrained form of XML DSig was
> that
> we have fairly good library support now and we do not need to redefine a
> lot
> of thing if we do this. That is going to be a simpler spec to read. You
> know, most of the implementors will not write code to support these
> security
> features but relies on the libraries.
> 
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.


>>
>>
>> <TargetAuthority>. Looks like everyone one is convinced that it is
>> required.
>> Now this seems to be required only if you want to address the "trust
>> issue".
>> The trust issue as far as I can see is not an issue that has come to a
>> consensus. In any case it wasnt addressed in OpenID 1 and 2. And I dont
>> think we need to address it in the next minor release. In any case XRD
>> was
>> supposed to be simple. In which case this is an issue to be addressed
>> outside of/over and above XRD. So <TargerAuthoruty> is not required here.
>> Atleast not in the first roll out of XRD.
> 
> 
> <TargetAuthority> was dropped. It is now <Subject> within <Link>.
> 
> By the way, you absolutely need this in OpenID. If you do not, you will
> not
> be able to do the delegation. Of course, if you do not want the delegation
> in OpenID, that is another matter...
> 

Whatever you call it, the problem I described is the same. Delegation in
OpenID 1 and 2 has worked fine without an equivalent. By adding this here
you are enforcing XRD to handle the trust issue. So what I was suggesting
here is to leave it out of the current XRD, and not to tie the trust issue
with the signing of the XRD



>>
>>
>> <Subject>Subject of the host meta. This looks like a howler to me. I mean
>> why are we even getting into this? If you want to keep XRD simple then
>> all
>> you need is the english language definition of the word "Subject". So the
>> subject of the host meta is "domain xrd".
> 
> 
> It is not the Subject of the host meta. Subject is the
> thing/person/whatever
> this XRD is describing.Thus, I think <Subject> is simple enough.
> In OpenID use case, it would be the claimed identifier (canonical id) of
> the
> person.
> It used to be called <CanonicalID>.
> 
> I do not understand what you mean by "domain xrd".
> 
> 

I was talking about this discussion.
http://lists.oasis-open.org/archives/xri/200907/msg00001.html
http://lists.oasis-open.org/archives/xri/200907/msg00001.html 


-----

Santosh Rajan
http://santrajan.blogspot.com http://santrajan.blogspot.com 
-- 
View this message in context: http://www.nabble.com/XRI-TC---An-Outsiders-perspective-tp24446729p24448284.html
Sent from the OpenID - General mailing list archive at Nabble.com.