[OpenID] Recycling OpenIDs (Was: What's broken in OpenID 2.0? (IIW session))

[Drummond Reed]

>> Peter Williams wrote:
>>  
>>  Only control of the unique inumber (which could 
>>> be based on Freenet DHTs as easily as on DNS) offers the 
>>> non-subvertible persistent identity desired by anyone seeking 
>>> complete freedom from authority.
>> 
>> This is what I just cannot get my head around - on what the mainline
>> OpenId community is actually doing! XRI can mean so many things,
>> depending on the management model one applies to its generic framework.
>> The above is one extreme, whose existance is important (if rarely
>> actually leveraged) when seeking mass adoption.
>
>Martin Atkins wrote:
>
>I'm gravely concerned by several recent messages that have said things 
>along the lines of "Problem X is not a problem because XRI 
>infrastructure can *theoretically* do Y."
>
>I can only get behind XRI being in the OpenID 2.0 spec if:
>  * A particular, interoperable protocol or set of protocols is called 
>out and described completely.
>  * The whole end-to-end resolution process mapping a defined set of 
>XRIs that are allowed when using OpenID to a particular XRDs document is 
>written down clearly somewhere in a manner that is suitable for OpenID 
>developers that have no interest in the rest of the XRI infrastructure.
>  * The implementation of the above does not place an excessive burden 
>on RP developers above and beyond what they have to include to support 
>HTTP URLs.
>
>I was starting to warm to the idea of supporting i-names on the basis 
>that they are well defined, reasonably well-understood and they can be 
>supported with minimal burden through the use of a proxy resolver. 
>However, if that same mechanism cannot be applied to these 
>"peer-to-peer" XRIs or XRIs from alternative roots then I don't believe 
>that they can reasonably be included in the OpenID 2.0 specification. 
>OpenID developers should not have to jump through hoops to implement a 
>protocol that has little adoption thus far and has yet to prove itself.
>
>(As usual, I'm speaking only for myself here.)

Martin: your concerns are well stated. Let me add some perspective from the
"XRI side" (for those new to the list, I'm co-chair along with Gabe Wachob
of the OASIS XRI TC, and also a board member of the OpenID Foundation, so I
care very much about the interrelationship of the two technologies).

First, I agree that recent discussions of all the things XRI architecture
"could do" haven't helped clarify what problems it can and can't help OpenID
with today. From my perspective, here's what XRI 2.0 can do for OpenID 2.0
today:

* XRI has a solution that works today for binding simple, human-friendly
identifiers (i-names) to persistent identifiers (i-numbers) to prevent
OpenID recycling. This particular approach has been live operationally for a
year now and is being further hardened by Canonical ID verification rules
being added to the final draft of the XRI Resolution 2.0 spec (and the
OpenXRI resolver code). This same solution can be extended to URLs (binding
reassignable URLs to either persistent URLs or persistent XRIs) per the
discussions on the OpenID Specs list last week. The XRI TC held a special
telecon on this subject today and I have the action item to write up the
proposal on the XRI TC wiki w/in the next 24 hours. I'll post the link as
soon as it is ready.

* The XRI = and @ global registry spaces operated by XDI.org have an
operating registry infrastructure that automatically supports mapping of
reassignable i-names to persistent i-numbers, UTF-8 internationalized
identifiers, anti-phishing protection, strong privacy protection, etc. This
gives end-users another choice for registering a portable OpenID identifier
similar to registering their own top-level domain name, at a roughly similar
cost.

* XDI.org also operates an XRI proxy resolution service at xri.net that
makes XRI resolution very lightweight and easy for developers to support.
This service should be updated to support Canonical ID verification within a
few weeks of finalizing the XRI Resolution 2.0 spec.

Now, here's a list of capabilities XRI architecture/infrastructure *could*
support, but which I classify as "future" because they are either not yet
widely implemented or will be part of the XRI 3.0 specs:

* Direct resolution of URLs cast as XRIs. Simple example: the URL
"http://example.com/user" becomes the XRI "$(http://example.com/user)" that
can can now be fed to an XRI 3.0 resolver (either local or proxy) to do XRDS
resolution, Canonical ID verification, and OpenID service endpoint
selection.

* Other p2p roots. URLs-cast-as-XRIs is actually an example of a p2p root --
one that's fairly easy for XRI architecture to support. As Fen pointed out,
XRI 2.0 syntax already allows other types of p2p roots, but I don't know of
resolvers implement this yet. I do know that other persistent identifier
architectures like the Handle system (http://www.handle.net) that can return
an XRDS document are now talking with the XRI TC about being included in XRI
3.0 

* Simplified XRI delegation syntax. This XRI 3.0 proposal, call direct
concatenation, would allow simplified construction of delegated XRIS by
enabling you to use the XRI global context symbols =, @, +, and $ as
delimiters in addition to * and !. More about that in a future post.

I hope it is helpful to draw this line between present and future (I invite
other XRI folks to add anything I may have missed.)

With regards to your suggestion that all this be clearly documented so it's
easy for OpenID developers to understand the relationship of XRI and OpenID,
I agree completely, and have volunteered to assist the OpenID spec editors
in doing so. Any additional suggestions you have as to how to best
accomplish this would be appreciated.

=Drummond