XRID proposal for YADIS

Ernst Johannes jernst+lists.danga.com at netmesh.us
Sat Nov 5 19:53:02 PST 2005 

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?
2) Is there a master document somewhere which defines the entire  
format, not just the subset that we are discussing?
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?
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.
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...

Just first thoughts ...



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
>

Johannes Ernst
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lid.gif
Type: image/gif
Size: 973 bytes
Desc: not available
Url : http://lists.danga.com/pipermail/yadis/attachments/20051105/8859fbc4/lid.gif
-------------- next part --------------
  http://netmesh.info/jernst




Johannes Ernst
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lid.gif
Type: image/gif
Size: 973 bytes
Desc: not available
Url : http://lists.danga.com/pipermail/yadis/attachments/20051105/8859fbc4/lid-0001.gif
-------------- next part --------------
  http://netmesh.info/jernst

More information about the yadis mailing list