[OpenID] XRI TC - An Outsiders perspective

[Peter Williams]

XRI is (was) a distributed name-resolver framework, and had to have its own internal security enforcement mechanisms for delegation of authority for namespaces and segments. SO, it has to have the mechanism for its own interal protocol (auth-res), and these were then made available for "XRDS applications" - uses of  XRD by non XRI client (ie. openid in http URL mode).

The trouble is those XRDS applicaions (now XRD apps) don't have anything like the rigor of the security model used in native XRI land. You end up with openid auth v2 does, with openid claimed identifiers and OP local identifiers during openid-delegation. 4 people recently had a discussion the topic, and each said something different about the technical process (in openid land)!

So we are stuck. Folks will not adopt the rigorous model (XRI), and when they use the framework (XRD), they get it wrong. (Just like the average programmer's use of crypto when given the math, vs a secure type library)

If we get Signed XRD of any signing-variant (I'm just playing devil's advocate to see where marketing folks are rigging their "new" programming libraries into the infrastructure), we have made a big step forward. It doesnt solve the problem, but provides access to known (non-XRI/XRD) delegated-authorization management tools that do. They are those that are powering the web, today!



________________________________________
From: general-bounces at openid.net [general-bounces at openid.net] On Behalf Of Santosh Rajan [santrajan at gmail.com]
Sent: Sunday, July 12, 2009 9:30 AM
To: general at openid.net
Subject: Re: [OpenID] XRI TC - An Outsiders perspective

Hey, this makes sense. Now I realize why it is complicated.
Come to think of it why is XRI TC even concerned with OpenID delegation. As
far as they are concerned this should be an application specific problem.
And by definition XRD is extensible. Really they should stick to the
framework and leave it to the OpenID folks to extend it to tackle delegation
and trust.
So what we need from them is a basic framework which is more or less covered
by the original work done at hueniverse + site-meta + signature(only for
transport security in case of non availability of ssl).


Peter Williams wrote:
>
>
> Anything produced by OASIS will tend to be complicated in its spec: its
> why it exists .. to do engineered solutions.
>
> OASIS methods contrast with W3C design approaches -- which use science
> rather than engineering methods. The nature of science is that it
> inherently leaves lots of open questions, allowing the space needed
> solving crypto-political issues facing non-computers. It thus tends to be
> good for highly-scalable, civilian systems. The nature of engineering is
> that it necessarily must be complete, and thus its long and tedious to
> read. It tends to be good for military/safety systems.
>
> Id love OpenID to continue being what it is: itself - neither W3C nor
> OASIS dominated. So far, David and co have done a good job on that - which
> speaks to their political savvy. There is no point being in the middle of
> a W3C/OASIS (science vs engineering) culture war. Neither W3C nor OASIS
> are particularly user-centric design cultures (despite all their marketing
> to the contrary). Openid set out to be user centric, and  found synergy
> with the best UCI bits of OASIS (XRI/XRD) with the best UCI bits of W3C
> (URLs). Despite the many pressures of crypto/corporate/standards politics,
> its retained its own identity.
>
>


-----

Santosh Rajan
http://santrajan.blogspot.com http://santrajan.blogspot.com
--
View this message in context: http://www.nabble.com/XRI-TC---An-Outsiders-perspective-tp24446729p24450106.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