Non-HTML Links

Brad Fitzpatrick brad at
Wed May 18 09:23:12 PDT 2005

I like the idea of multiple authoritive identity servers.  The convention
in the 'rel' and 'profile' attributes seems to be to space separate the
values, but that seems wrong in an 'href' attribute.  I'd say multiple
link tags.  In that case:

   - simple implementations will just use the first, and not be
     confused by hrefs with multiple values

I guess that's essentially it.  And we tell client authors:  you MAY check
against any that they have specified.  It's most definitely not a _must_

- Brad

On Wed, 18 May 2005, Martin Atkins wrote:

> As I understand it, currently the way to bind to an identity server is
> through an HTML link element:
> <link rel="openid.server" href="" />
> It seems a shame to bind Yadis to HTML, though. It would be nice (in my
> opinion, at least) to provide a mechanism which binds any URL, whatever
> media type it may point at, to an identity server.
> The best I've come up with so far is the Link HTTP header, which
> performs a similar purpose to the HTML LINK element. I don't think it
> was ever formally standardised, but there exists a draft describing it:
>      <>
> While I'm hesitant to recommend implementing an un-standardized draft,
> the description there essentially mimics the HTML LINK element so I
> can't see how it could be used any differently.
> This would of course be *in addition* to supporting the LINK element in
> HTML and XHTML documents, as indicated by the Content-type of the
> response. Some users are unfortunate enough to have inflicted on
> themselves hosting servers where they cannot control the HTTP headers
> returned.
> Some thought should also be given to what happens in the case where
> there are multiple identity server links (HTTP or HTML), especially
> where both the HTTP header and the HTML document specify different
> servers. A given document could potentially have serveral identity
> servers vouching for it, with the intention that the consumer will trust
> one or more of them.
> Better ideas than this unstandardized HTTP header are welcomed, of course.
> _______________________________________________
> yadis mailing list
> yadis at

More information about the yadis mailing list