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

[Grant Monroe]

Drummond,
Is the example you gave (http://xri.net/=drummond.reed) supposed to
return an XRDS or is this just hypothetical?

--
Grant Monroe
JanRain, Inc.

On 4/3/06, Drummond Reed <drummond.reed at cordance.net> wrote:
> 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.
>
>
>
>