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

[Drummond Reed]

I want to reinforce Luka's last point that to authenticate an XRI using
OpenID, no changes are needed to the Service Type that identifies OpenID
authentication service. The contents of the <Service> element in an XRDS
document would be identical to that used to authenticate an OpenID URL.

It is true that XDI.org has developed a SAML profile to use as an
authentication service for XRIs (starting back in the early days before
there was an OpenID or LID ;-). Tentatively (because the final spec hasn't
been approved by the XDI.org trustees yet - that's expected shortly) the
identifier for this Service Type is:

	xri://+authentication*(+saml)*($v*1.0)

(Note that this XRI uses the XRI "+" space for generic identifiers -- one
for authentication and one for SAML -- and the XRI "$" space for identifier
metadata -- in this case for versioning metadata, "$v".)

So if you add this SAML-based authentication service to OpenID and LID, what
we have now in Yadis is the ability for three different types of identifiers
-- OpenID URLs, LID URLs, and XRIs -- to all be used to authenticate by
three different HTTP authentication protocols -- OpenID, LID, and SAML 2.0.

In all cases, the scenario is the same, i.e.:

1) The relying party uses the identifier to retrieve the Yadis XRDS document
(using the Yadis protocol for URLs, and using XRI resolution or proxy
resolution for XRIs),
2) The relying party selects the desired authentication protocol (if all
three are present) by its Service Type.
3) The relying party follows the selected authentication protocol.

=Drummond 

-----Original Message-----
From: yadis-bounces at lists.danga.com [mailto:yadis-bounces at lists.danga.com]
On Behalf Of Lukas Rosenstock
Sent: Monday, April 03, 2006 12:21 AM
To: yadis at lists.danga.com
Subject: Re: Proposal for an XRI (i-name) profile for OpenID

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://myope
nid.com/server</URL><openid:delegate>http://username.myopenid.com/</openid.d
elegate></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).