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

[Drummond Reed]

Martin's right here except one detail -- when the Relying Party resolves the
XRI using standard or proxy XRI resolution, it will get back the Yadis XRDS
document. No need to "resolve it to URL, then do Yadis discovery on it". The
standard response to XRI resolution *is* an XRDS document.

In addition, in case it wasn't clear in earlier messages, starting with XRI
Resolution 2.0 Working Draft 10
(http://www.oasis-open.org/committees/download.php/17293/xri-resolution-v2.0
-wd-10.pdf), any Relying Party that wants to do the minimum work to accept
an XRI and get back the Yadis XRDS document can request XRI proxy resolution
from any public XRI proxy resolver, such as the http://xri.net resolver
offered by XDI.org.

To use this option, the Relying Party just checks to see if the Yadis ID is
an XRI by seeing if it starts with an "=", "@", "!", or "xri://" If so, the
Relying Party just appends the Yadis ID to the proxy resolver URL (in this
case, "http://xri.net/") and does an HTTP GET with an Accept header value of
"application/xrds+xml".

For example, to do proxy resolution of my i-name "=drummond.reed", the URL
would be:

	http://xri.net/=drummond.reed 

If the proxy resolver supports it, the Relying Party can have the proxy
resolver do more work and locate a specific type of service endpoint type.
This is done using query parameters as defined in section 7.3 of the spec.
For example, the following proxy resolution URL...

	http://xri.net/=drummond.reed?_xrd_t=http://openid.net/signon/1.0

...will either return an XRDS document with an OpenID 1.0 service endpoint
or an error if one can't be found.

=Drummond 

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

Lukas Rosenstock wrote:
> 
> 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?
> 

So are you going to modify LID, and SXIP, and every other URL-based
authentication system as well? Surely it's better just to build
something new *on top* of all this stuff and then your changes apply to
everyone. As I see it, it works something like this:

* User enters XRI URI
* Relying Party resolves the XRI URI to a URL and does Yadis discovery
on it. Since Yadis uses the same format as is used for XRI resolution,
this might not even be a separate step.
* Relying Party, as normal, takes a look at the available services and
selects the most appropriate for signon.
* Relying Party does auth as normal with that protocol using the Yadis
URL or the delegation URL. It tracks the URI the user originally entered
using either a mechanism exposed by the protocol (in the case of OpenID)
or with some internal state.
* On success, Relying Party says "Hey, xri://whatever!"

This can be applied equally to both OpenID and LID (and probably also
SXIP, but I don't actually know how that operates) without modifying
either. The Relying Party can implement XRI resolution as a layer on top
of whatever other protocol it wants, much like IPv4 and IPv6 nothing
about DNS.