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

[Lukas Rosenstock]

Am 03.04.2006, 08:47 Uhr, schrieb Martin Atkins <mart at degeneration.co.uk>:

> 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  
scenarios:

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  
<XRDS>...<Service><Type>http://openid.net/signon/1.0</Type><URL>http://myopenid.com/server</URL><openid:delegate>http://username.myopenid.com/</openid.delegate></Service>...  
then the consumer (relying party) will only present  
http://username.myopenid.com/ 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://@xdi.org*(+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).