XRID proposal for YADIS

[Drummond Reed]

It's late Friday and I promised that I'd post this by the end of the day
(the OASIS XRI TC actually met this morning but I've been tied up in another
meeting all day), so I'm quickly going to send this email and then take the
time to add this to the wiki later this weekend (or anyone else is welcome
to).

Brief background for anyone new to this subject: when YADIS was previewed
with some of the XRI folks prior to the Internet Identity Workshop last week
(https://www.socialtext.net/iiw2005/index.cgi), we realized its description
format had a lot in common with XRIDs (XRI Descriptors, the lightweight
resource description format used in XRI resolution). At the YADIS breakout
at IIW, it became clear that if we could all use the same discovery document
format, regardless of whether the discovery document was retreived using an
URL or an XRI (which in the resolution process is converted to a URL
anyway), then we could take another huge step forward in interoperability.

The XRI folks agreed to take this back to the XRI TC this week because it is
just in the process of finishing the XRI Syntax 2.0 Committee Draft 02
specification which defines the XRID format. The TC agreed to schedule an
extra call this week to make sure we could get a proposal back by the end of
the week.

In the end, it was as simple as we thought it might be at our whiteboard
session at IIW last week. Except for the fact that an XRID can include a few
other XML elements that are used by XRI resolution, the basic structure of
an XRID is very similar to the YADIS capabilities format
(http://yadis.org/wiki/Formats). This isn't surprising since XRI resolution
is really the same basic process as YADIS: simple, lightweight HTTP-based
discovery of the capabilities of a network endpoint (of which XRI resolution
capabilities, which are really just URL construction operations, are just
one type of capability).

Below is a prototype example of what a v2.0 XRID would look like. A few
notes:

1) The reason there are two enclosing elements (<XRIDS> and <XRID>) is
because in XRI resolution, a client or a server can do "lookahead"
resolution and compile multiple XRIDs retreived from other XRI resolution
servers (HTTP(S) servers that serve up XRIDs). Thus the outer <XRIDS>
element can contain multiple XRID elements corresponding to the different
parts of the XRI being resolved. I don't know whether YADIS needs this or
not.

2) All child elements of <XRID> and <Service> are optional, so you can
use/not use whatever you want.

3) The <Query>, <Expires>, <ProviderID>, <Synonym>, and <XSynonym> elements
are all specific to XRI resolution, so other YADIS uses can ignore them
(although <Expires>, which takes an XML datetime value, might be very handy
for YADIS document caching).

4) The workhorse is the <Service> element. This element contains a <Type>
element that contains a URI identifing the service (identical to the YADIS
"capability" line). This element takes a "version" attribute which appears
identical to the YADIS "version" line. Note that in this sample XRID, there
are services (capabilities) defined for OpenID, LID, and XRI resolution.

5) Some of the XRI resolution services use a few additional child elements
of <Service>:

 * The <URI> element is to specify the concrete endpoint at which this
service can be obtained (if different than the calling URL). I think YADIS
has the same concept by another name.
 * The <MediaType> element takes a MIME type identifier to advertise the
media types that might be available at a service endpoint.
 * The <ProviderID> element is for use with other service interaction trust
mechanisms like SAML that need a persistent service provider ID.
 * The <dsig:keyInfo> element is used with service interaction trust
mechanisms that use XML dsig.

6) The XML schema for XRID allows all the container elements to be extended,
so you can add anything you want from any XML namespace you want.


<XRIDS version="$v*2.0">
   <XRID version="$v*2.0">
      <Query>query-xri</Query>
      <Expires>expiry in XML date time</Expires>
      <ProviderID>persistent ID for XRID provider</ProviderID>
      <Synonym>synonymous XRI assigned by same ProviderID</Synonym>
      <XSynonym>synonymous XRI assigned by different ProviderID</XSynonym>
      <Service>
          <Type version="1.0, 2.0">http://lid.netmesh.org/sso<Type>
      </Service>
      <Service>
          <Type version="1.0">http://openid.net/<Type>
      </Service>
      <Service>
         <Type>xri://$resolution*authority*generic*($v*2.0)<Type>
         <URI priority="10">http://xri.generic.authority.tld/path</URI>
         <URI priority="15">http://xri2.generic.authority.tld/path</URI>
      </Service>
      <Service>
         <Type>xri://$resolution*authority*trusted*($v*2.0)<Type>
         <URI>http://xri.trusted.authority.tld/path</URI>
         <ProviderID>persistent ID for service provider</ProviderID>
         <dsig:keyInfo>key info</dsig:keyinfo>
      </Service>
      <Service>
         <Type>xri://$resolution*local*($v*2.0)<Type>
         <URI>http://xri.local.authority.tld/path</URI>
      </Service>
      <Service>
         <Type>xri://$resolution*uri*($v*2.0)<Type>
         <MediaType>application/html</MediaType>
         <MediaType>application/xml+rdf</MediaType>
         <URI>http://example.com/some/path</URI>
      </Service>
   </XRID>
</XRIDS>

I hope this proves valuable & that we can realize this potential synergy.
BTW, my sister is visiting this weekend so I may not be back online until
Monday; hopefully others from the XRI crowd can participate in any
discussion this weekend.

=Drummond 
http://public.xdi.org/=Drummond.Reed