[OpenID] XRI TC - An Outsiders perspective

Sun Jul 12 11:34:11 UTC 2009

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.

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

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

=nat

>
>
> So why dont we come out with a simple XRD that will elicit a response like
> (1) above from people?
>
> -----
>
> Santosh Rajan
> http://santrajan.blogspot.com http://santrajan.blogspot.com
> --
> View this message in context:
> http://www.nabble.com/XRI-TC---An-Outsiders-perspective-tp24446729p24446729.html
> Sent from the OpenID - General mailing list archive at Nabble.com.
>
> _______________________________________________
> general mailing list
> general at openid.net
> http://openid.net/mailman/listinfo/general
>

-- 
Nat Sakimura (=nat)
http://www.sakimura.org/en/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20090712/68048adf/attachment.htm>