XRID proposal for YADIS

Drummond Reed drummond.reed at cordance.net
Sat Nov 5 21:05:43 PST 2005 

>Johannes Ernst wrote:
>So for me to understand this ... If we take the example from the wiki:
>     http://yadis.org/wiki/Formats
>
>then using the format you are proposing it would look like this?
>
><XRIDS version="$v*2.0" xmlns:Foo="http://some.foo/place">
>    <XRID version="$v*2.0">
>       <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 version="1.0, 2.0">http://lid.netmesh.org/ 
>traversal<Type>
>       </Service>
>       <Service>
>           <Type version="1.0beta2,1.0,2.3,9.0-12">http://example.com/ 
>new/innovative/capability<Type>
>           <Foo:Foo value="bar"/>
>       </Service>
>    ...
>
>    </XRID>
></XRIDS>
>
>My questions:
>1) Did I get this right?

Yes.

>2) Is there a master document somewhere which defines the entire  
>format, not just the subset that we are discussing?

Yes, the XRI TC is currently preparing XRI Resolution 2.0 Committee Draft
02, which will have the entire spec, including all the elements I mentioned.
An example of the entire document is Committee Draft 01
(http://www.oasis-open.org/committees/download.php/11852/xri-resolution-v2.0
-cd-01.pdf), however Committee Draft 02 is being refactored because of the
shift to a new XRID format and the incorporation of full HTTP proxy
resolution (both based on the feedback we received from the public review
period of CD01 last spring.) I expect the first draft of CD02 within the
next week (which will be called XRI Resolution Working Draft 09, since CD01
was based on Working Draft 08 - at OASIS you switch back into Working Drafts
until you reach the point at which you promote a spec to a Committee Draft.)

>3) It appears this is some version 2.0 ... is there a 1.x? How big  
>are the differences? Well, what I'm really asking is: will there be a  
>version 3 of the format, and how big are the differences likely going  
>to be in which time period?

XRI Resolution 1.x was published in January 2004. See the XRI TC home page
at http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xri for the
full history. 

XRI Resolution 2.0 is based on XRI Syntax 2.0 (which underwent some
important revisions due to the underlying IETF URI and IRI specs upon which
XRI is based being revised by IETF last February -- see the links on the XRI
TC home page). XRI Resolution 2.0 also added lookahead resolution and
trusted resolution based on SAML 2.0. 

There are no plans for a version 3.0. The goal of XRI is to keep it as
simple and stable as possible because that's what's required of
infrastructure that lots of other applications come to depend on (like IP,
DNS, HTTP, and URLs/URIs).

>4) I'm a little queasy about the term "Service" -- for example, a  
>YADIS implementor might want to advertise that it understands  
>credentials of type A, B and C -- and use the capabilities  
>advertisement to do so. Credential types aren't really services ...  
>which is why we called it "capability" in the first place. This isn't  
>major, I just wanted to point it out.

I don't think the XRI TC is wedded to "Service". It's a legacy of a similar
element in XRI Resolution 1.0. One version we discussed this week introduced
the word "Capability", so I can check and see what people think.

>5) If we break all of this information into nice little DOM nodes  
>already, what about breaking the version tag into version elements,  
>so we don't have to do parsing of comma-separated lists ... So  
>instead of
>
><Service>
>   <Type version="1.0,1.1,2.0">http://example.com/new/innovative/ 
>capability</Type>
></Service>
>
>we could say:
>
><Service>
>   <Version name="1.0"/>
>   <Version name="1.1"/>
>   <Version name="2.0"/>
>   <Type>http://example.com/new/innovative/capability</Type>
></Service>
>
>Something like this also might make it very easy to do XPath-based  
>node selection, for example...

Ironically that was closer to what others on the XRI TC were thinking too;
the reason I showed it as a "version" attribute was because that's what
David and I discussed during the whiteboard session at IIW.

I personally would be happy to have it as a Version element.

>Just first thoughts ...

And good ones. The whole idea is to cross-pollinate quickly and see if we
can get to a common view of the overall description format, then nail down
the details, publish it, and get on down the adoption road as quickly as we
can.

So please send any other questions/feedback/suggestions as soon as you can
and we'll boil them down into the XRID format that will go in XRI Resolution
Working Draft 09 that should be out no later than by this Friday. I'll send
a link to the list as soon as it appears.

=Drummond 

>
>On Nov 4, 2005, at 21:09, Drummond Reed wrote:
>
>> 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
>

More information about the yadis mailing list