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

Drummond Reed drummond.reed at
Mon Apr 3 20:35:13 UTC 2006

Grant, great question, I should have clarified that. If you click the naked
link you will get the default resource that I
(the i-name owner) have assigned to be returned, which is my contact page.
However if you do a GET on that URL with an Accept header value of
"application/xrds+xml", you should get the XRDS document. This will work as
soon as the proxy resolver is upgraded to support that

Since hosting of the proxy resolver is in transition from 2idi
(where it has been hosted during the beta program) to NeuStar (where
it will be hosted when's XRI global registry services open in Q2), I
don't know exactly what the schedule is for this functionality to go online.
But I'm cc'ing the two gentlemen who should be able to shed more light on
precise dates: Victor Grey, President of 2idi, and Les Chasen, Director of
Registry Development at NeuStar.

Victor, Les?

=Drummond (  

-----Original Message-----
From: grant.monroe at [mailto:grant.monroe at] On Behalf Of
Grant Monroe
Sent: Monday, April 03, 2006 1:17 PM
To: Drummond Reed
Cc: Martin Atkins; yadis at
Subject: Re: Proposal for an XRI (i-name) profile for OpenID

Is the example you gave ( supposed to
return an XRDS or is this just hypothetical?

Grant Monroe
JanRain, Inc.

On 4/3/06, Drummond Reed <drummond.reed at> wrote:
> Martin's right here except one detail -- when the Relying Party resolves
> XRI using standard or proxy XRI resolution, it will get back the Yadis
> document. No need to "resolve it to URL, then do Yadis discovery on it".
> standard response to XRI resolution *is* an XRDS document.
> In addition, in case it wasn't clear in earlier messages, starting with
> Resolution 2.0 Working Draft 10
> -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
> from any public XRI proxy resolver, such as the resolver
> offered by
> To use this option, the Relying Party just checks to see if the Yadis ID
> an XRI by seeing if it starts with an "=", "@", "!", or "xri://" If so,
> Relying Party just appends the Yadis ID to the proxy resolver URL (in this
> case, "") and does an HTTP GET with an Accept header value
> "application/xrds+xml".
> For example, to do proxy resolution of my i-name "=drummond.reed", the URL
> would be:
> 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...
> ...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 [mailto:yadis-bounces at]
> On Behalf Of Martin Atkins
> Sent: Monday, April 03, 2006 11:39 AM
> To: yadis at
> 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.

More information about the yadis mailing list