Question: Yadis Service URIs in the OpenID Auth case

Gabe Wachob gabe.wachob at
Wed Aug 30 23:48:14 UTC 2006

I agree there's a fuzzy line here between what should be
application-specific and what should be XRI-specific. 

Internally (in the XRI TC), I argued that this should all be
application-specific. I lost that argument, but in this case, my concerns
are reraised. I think we have algorithmically defined a practical set of
functionality (service selection) and I don't want to force applications to
jump through hoops to use the algorithm because of arbitrary assumptions we
have about all services. Service definitions should be able to use that
algorithm to the best way that suits them (or ignore it altogether to the
extent they can). 

The service selection algorithm that is in place supports multiple models of
trust between endpoints and doesn't define those trust semantics (or in
fact, any relationship between service endpoints identified by URI elements
-- except that the metadata in the enclosing Service element applies to all
the service endpoints identified by URI elements). Its very basic
functionality meant to enable a bunch of different applications and uses of
service blocks. 

In short, I tend to agree with the approach you are talking about in this
email as one possible approach. 

The URI element was defined because the Service is/was defined to refer to a
network endpoint identified by a URI -- and service selection went on to
define URI-construction rules based on the contents of that URI & the
context of the XRI resolution. 

I don't think openid *has* to use the URI element, but it really seems like
at least <openid:Server/> is exactly the same as <URI/> for the openid
service type. 


> -----Original Message-----
> From: yadis-bounces at [mailto:yadis-bounces at]
> On Behalf Of Martin Atkins
> Sent: Tuesday, August 29, 2006 3:00 AM
> To: yadis at
> Subject: Re: Question: Yadis Service URIs in the OpenID Auth case
> Gabe Wachob wrote:
> >
> > An OpenID component will be the one
> > interpreting the service blocks anyway... so shouldn't OpenID define the
> > interpretation of these service blocks?
> >
> On the other hand, it's nice to be able to have a generic parser library
> for XRDS where callers can just say:
>   getServiceEndpoints("")
> ...and get back an ordered list (ordered by priority) of all matching
> services.
> Not that I'm entirely convinced that this is opposing your suggestion.
> If the library avoids too much interpretation of the innards of the
> "Service" element then the "caller decides" approach can still work:
> interface IYadisServiceEndpoint {
>      double getPriority();
>      string[] getURLs(); // A list of URLs ordered by priority
>      XMLDOMElement[] getElements(string xmlns, string elemname);
> }
> Ignore the specifics for now; I know that that getElements method is
> ugly. The general principle is the important thing: the Yadis library
> (which might really be an XRI library; I've lost track of who owns what
> here) deals specifically with the XRI elements and exposes the non-XRI
> elements to a higher layer.
> Then, if OpenID wants to define special handling for URLs in its service
> elements it should add its own property element instead of using the XRD
> one:
> <Service xmlns:openid="">
>    <Type></Type>
>    <openid:Server></openid:Server>
>    <openid:Delegate></openid:Delegate>
> </Service>
> It can then define whatever semantics it wants on that element,
> regardless of what XRI resolution might have to say about its "URI"
> field. OpenID implementations using the above Yadis library will then
> just ignore the getURLs() method completely.
> Of course, once I start down this road I start to wonder why XRI defines
> a global "URI" element at all, since the meaning of it will obviously be
> different for different service types. What was the thinking behind that?

More information about the yadis mailing list