Redirecting an XRI to a URI (was Proposal for an XRI (i-name) profile for OpenID)

Fri Apr 7 21:54:00 UTC 2006

>Martin wrote:
>I still haven't figured out what XRDS stands for. :)

Extensible Resource Descriptor Sequence.

>>Drummond wrote:
>> So -- I'm guessing here -- is the question, "Can an XRI author create an 
>> XRI that points to an XRDS document that the XRI author does not 
>> control?" In other words, could you as an individual create an XRI 
>> that points to LiveJournal's XRDS document?
>
>Yes, that is my question in a nutshell.

>> In which case the answer is yes, there's an easy way to do that. 
>> But before I go into that, I want to make sure I'm answering the 
>> right question. 
>
>I'd be interested to hear about it, since my understanding about how XRI
>resolution works is still practically nonexistant.

Understood. One way to think about XRI resolution is simply as an
Internet-scale redirection service. In other words, if you just want create
a very stable identifier and over its lifetime control its redirection to
one or more URIs, XRIs and XRI resolution were made to do that.

The way it works is very much like DNS. If you want to get the IP address
for wiki.yadis.org, you start with the IP address for the TLD .org (which
must be configured in the resolver), then you ask .org for the IP address of
yadis.org, then you ask yadis.org for the IP address of wiki.yadis.org. 

With XRIs, instead of DNS resource records, you're asking for XRDS documents
(Yadis documents). So if you want to resolve xri://=drummond.reed*wiki, you
start with the URI for =, then you append "*drummond.reed" to it (the
leading * a is implied after the leading = character) and do an HTTP GET
with a Accept header content type of "application/xrds+xml". You get back
the XRDS document for xri://=drummond.reed. You then look in that document
for the next XRI authority resolution service endpoint
(<Type>xri://$res*auth*($v*2.0)</Type>) and take THAT URI and append "*wiki"
to it and do an HTTP GET for that XRDS document.

At that point you've fully resolved "xri://=drummond.reed*wiki". So what
happens then? It depends on what service you want. You could look in that
XRDS document for any service type I want (such as OpenID SSO or LID SSO),
but if you don't specify one, the default service is just redirection to a
URI. Such a service endpoint looks like this:

<Service>
	<URI>http://example.com/address-I-want-to-redirect-to</URI>
</Service>

There's no Type, no MediaType, and no Path element, just a URI. So if you
just want to redirect an XRI to a URI, you just put one service element in
the final XRDS document that contains that URI. If you requested proxy
resolution of this XRI, i.e., prefixed the XRI with the address of an XRI
proxy resolver like this...

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

...and then clicked on this link in an ordinary browser, the final XRDS
document retreived by the proxy resolver at http://xri.net might look like
this:

<?xml version="1.0" encoding="UTF-8" ?> 
<XRDS xmlns="xri://$xrds">
  <XRD xmlns="xri://$xrd*($v*2.0)">
    <Query>*wiki</Query> 
    <Status code="100">SUCCESS</Status> 
    <Expires>2006-04-08T21:21:28Z</Expires> 
    <ProviderID>xri://!!1002!1234</ProviderID> 
    <CanonicalID priority="1">=!1001.1000.1000.1008!1234</CanonicalID> 
    <Service>
	<URI>http://example.com/address-I-want-to-redirect-to</URI>
    </Service>
  </XRD>
</XRDS>

If this was the case, the proxy resolver would simply return a 3xx redirect
to http://example.com/address-I-want-to-redirect-to.

You can get one more level of redirection granularity out of XRI resolution
by using the Path subelement of the Service element. The Path element can be
used to instruct an XRI resolver to select a specific service endpoint on
the basis of a matching XRI path. For example, if I wanted...

	http://xri.net/xri://=drummond.reed*wiki/yadis

...to automatically redirect to the Yadis wiki and...

	http://xri.net/xri://=drummond.reed*wiki/oasis-xri

...to automatically redirect to the OASIS XRI TC wiki, then the XRDS
document for xri://=drummond.reed*wiki could look like the following:

<?xml version="1.0" encoding="UTF-8" ?> 
<XRDS xmlns="xri://$xrds">
  <XRD xmlns="xri://$xrd*($v*2.0)">
    <Query>*wiki</Query> 
    <Status code="100">SUCCESS</Status> 
    <Expires>2006-04-08T21:21:28Z</Expires> 
    <ProviderID>xri://!!1002!1234</ProviderID> 
    <CanonicalID priority="1">=!1001.1000.1000.1008!1234</CanonicalID> 
    <Service>
	<URI>http://example.com/address-I-want-to-redirect-to</URI>
    </Service>
    <Service>
      <Path select="true">yadis</Path>
	<URI>http://wiki.yadis.org</URI>
    </Service>
    <Service>
      <Path select="true">oasis-xri</Path>
	<URI>http://wiki.oasis-open.org/xri</URI>
    </Service>
  </XRD>
</XRDS>

The select="true" attribute of Path tells the resolver that if the XRI path
matches the contents of the Path element, this service endpoint must be
selected.

The ultimate way to tap the power of XRI as a URI redirection service is to
publish a service endpoint specifically designed for URL forwarding.
Although this requires two redirects (the first from an XRI proxy resolver
to the forwarding service and the second from the forwarding service to the
final URI), it's infinitely configurable and extensible by the end-user,
i.e., you don't have to list all the paths in an XRDS document.

Here's XRDS document that illustrates a forwarding service endpoint:

<?xml version="1.0" encoding="UTF-8" ?> 
<XRDS xmlns="xri://$xrds">
  <XRD xmlns="xri://$xrd*($v*2.0)">
    <Query>*wiki</Query> 
    <Status code="100">SUCCESS</Status> 
    <Expires>2006-04-08T21:21:28Z</Expires> 
    <ProviderID>xri://!!1002!1234</ProviderID> 
    <CanonicalID priority="1">=!1001.1000.1000.1008!1234</CanonicalID> 
    <Service>
	<URI append="local">
         http://forward.2idi.com/forwarding/=!1001.1000.1000.1008!1234?xri=
      </URI>
    </Service>
  </XRD>
</XRDS>

Notice that it's still just one URI, but it uses the append="qxri" attribute
value to specify that the XRI resolver should append the original query XRI
to the URI. So if the original proxy resolver XRI is...

	http://xri.net/xri://=drummond.reed*wiki/yadis

...of which the query XRI is the entire path portion
(xri://=drummond.reed*wiki/yadis), then the http://xri.net resolver would
return a redirect to...

      http://forward.2idi.com/forwarding/=!1001.1000.1000.1008!1234?xri=
xri://=drummond.reed*wiki/yadis

Assuming the forwarding service was configured as per the previous example
above, it would just return a redirect to...

	http://wiki.yadis.org

Anyway, that's a short tutorial on XRI resolution and how you can use it as
as a smart a URI redirection service.

=Drummond 