Proposal for an XRI (i-name) profile for OpenID

Lukas Rosenstock inbox at
Mon Apr 3 07:21:14 UTC 2006

Am 03.04.2006, 08:47 Uhr, schrieb Martin Atkins <mart at>:

> Hmm. If this is the case, why not have the Consumer do the XRI
> resolution and leave the Server unchanged? The Consumer's going to have
> to do XRI resolution to fetch the Yadis document anyway, but I'd much
> rather a protocol that acts as a layer *atop* OpenID than one that gets
> inside and changes it.

The consumer has to be changed and does XRI resolution. Now we have two  

a) The i-name and the OpenID service providers are two different parties.
b) The i-name and the OpenID service is offered by the same provider.

In case a) the OpenID server needs no change. When the user modifiies his  
i-name so that he can use it with OpenID he will use delegation anyway.  
For example xri://=username resolves to something like  
then the consumer (relying party) will only present to MyOpenID and MyOpenID doesn't have to  
know anything about XRI.

In case b) there will be no openid:delegate. The server doesn't change  
much. The only change is that when it looks up whether the given  
openid.identity is in is database the user identifier will begin with xri:  
instead of http:. So why enforce one delegation if only this minor change  
in the URI is necessary?

>> Yes, except I think the type would be  
>> <Type>xri://*(+authenticationService)</Type>

So why this? OpenID remains OpenID. Of course, you may assign a permanent  
XRI as a Type identifier for OpenID (now idea how this would look like)  
but not something generic as you've posted - I thought XRI was working on  
their own SSO scheme (which then would have 'that' type).

More information about the yadis mailing list