Non-HTML Links

Brad Fitzpatrick brad at danga.com
Wed May 18 11:50:24 PDT 2005


WTF was I smoking?  If one fails because the server's down, we don't know
how to fall back to the next, since we never got notified that it was
down.  The user's browser did.

Okay, one identity server!


On Wed, 18 May 2005, Brad Fitzpatrick wrote:

> 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_
> requirement.
>
> - 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="http://www.mydomain.com/openid" />
> >
> > 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:
> >      <http://www.w3.org/Protocols/9707-link-header.html>
> >
> > 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 lists.danga.com
> > http://lists.danga.com/mailman/listinfo/yadis
> >
> >
> _______________________________________________
> yadis mailing list
> yadis at lists.danga.com
> http://lists.danga.com/mailman/listinfo/yadis
>
>


More information about the yadis mailing list