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

Martin Atkins mart at degeneration.co.uk
Mon Jun 11 11:20:54 UTC 2007


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

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





More information about the general mailing list