[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xri] OpenID 2.1
I'm wondering if the core reasoning of moving XRI resolution to an extension spec is:
1. XRI resolution requires Library implementors to jump through hoops for Canonical ID verification
2. Library implementors have not jumped through these hoops very well, so XRI is resolution has spotty results
3. XRI does not currently have a large user base, so why put Library implementors through the hoops, and make the OpenID Spec look bad based on their implementations of the process.
4. During the CanonicalID verification process the identity which the user used is not displayed back to the user, so there could be some confusion on the users part, as to if they are correctly authenticating, "their" identity.
Any to add?
Whereas XRI Resolution "Built-in" to the OpenID Spec would allow the following, "Built-in":
1. Support of a truly abstract identifier, as http:// schemed urls are currently not purely abstract (and there are hoops made to allow them to appear this way)
2. CanonicalID verification of multiple identities owned by the same individual, which frees up the user to freely associate identities not tied to an RP.
3. Enforces HTTPS security without the user needing to type in https://
4. Is a concept that can be easily transfered outside of the http:// namespace.
Any to add?
XRI's were designed as pure abstract identifiers from the start, URIs have done a great job locating and serving resources, however used as just identifying resources they don't have as many built-in features to deal with that role. Such as the use of metadata around resources, change of authority or loss of an identifier.
I believe building in the base technological theories provided by XRI was a great, forward thinking act by the spec authors. Which unfortunately has not been implemented correctly by Library creators, thus putting pressure to move XRI technologies to an extension. By moving XRI identifiers to an extension spec the use of XRI would be optional to implement. I wonder if this would be a step in the wrong direction.
There might be an example in what the XRDS-Simple folks are experiencing with discovery on top of HTTP and URIs, HTTP is a protocol which was not "fundamentally" designed to support metadata retrieval. There are great "optional" methods of doing discovery of metadata over HTTP, however the fear is that the discovery protocol chosen could not *rely* on something which could be optional. So now there is incredible effort to agree on the best solution, none of which seems to really stand above another, on how to implement metadata discovery.
However, I feel OpenID, "did the right thing," by including some of the core resolution, discovery, canonical, ideas from XRI based abstract identifiers in the latest spec. After all OpenID could be looked at as an decentralized, abstract identity authentication layer, correct. This seems to be a "fundamentally" sound idea in which future identity based products using OpenID as an underlining technology. I would suggest keeping XRI as part of the core, even as Library creators struggle to implement abstract identifier based concepts. As they say, "No Pain, No Gain."
Note: We're struggling too (witness the struggle at: http://sourceforge.net/projects/ouno-xri/) *smile*
Because the XRDS specification may go through much more radical changes in the upcoming months/years. Would OpenID think about breaking out discovery as part of the OpenID 2.1 Spec? (I know John eluded to this in his questions... but I didn't see a clear answer)
Is there a consensus among RPs/Library creators that XRI is just, "too hard"? or is it just, "unnecessary"?
One of problems with https:// identifiers is the potential loss of a domain name, thus loss of an identifier. XRI at its core attempts to include solutions this problem. Are XRIs attempts to solve the "loss" factor inadequate or unneeded?
I'll try to word this a politically correct as possible. If a user education effort must be made to think of themselves as a URL (ie: https://me.yahoo.com/example.nika) then could the same efforts be made in the direction of users thinking of themselves as an abstract identifier (ie: @yahoo*example.nika) -- https:// seems to have too much history of a "web" based scheme to make it truly abstract in my opinion? It seems those efforts if pushed as part of the core spec would benefit Library creators, users and the OpenID Spec, now and in the future.
I must acknowledge the success and efforts that have gone into OpenID, the spec and surrounding community, up until this point. OpenID is a cool, and needed technology, and I plan on using it regardless of the outcome of this discussion.
On Sep 18, 2008, at 8:04 AM, John Bradley wrote: