Two possible notable changes

Brad Fitzpatrick brad at
Tue May 17 17:12:14 PDT 2005

C'mon Randy, we've had this discussion three times in the past two days:

LiveJournal user "attacker" also lists "" as an
assertable URL.

LiveJournal user "attacker" goes to to leave a comment. fetches, sees the OpenIDServer is says "This is user attacker, and
attacker lists as an assertable URL.

Dear attacker, says LJ, do you want to trust  Why yes I do,
says attacker.

LJ tells that attacker is


So the point of the "Randy bug" (good name!) is that if an identity
authority is asserting to a URL that it doesn't directly also
control/own/create, then the external URL ( must reference
the identity server with extra arguments to settle the dispute about who
the owner of is --- bradfitz or attacker.

- Brad

On Tue, 17 May 2005, Randy Reddig wrote:

> I like simplification. This simplifies Yadis/OpenID down to a single <link> tag plus some implementation work on the ID server side.
> I'm not sure, however, that having the ID server link have a built-in unique identifier is necessary, simply because a user listing a root URL as "me" implements the bidirectional linking necessary:
> - LiveJournal user "brad" lists "" as an assertable URL.
> - has the following link:
>     <link rel="OpenIDServer"
>         href="">
> Technically, any user could list "" as an assertable URL, but unless they /control/ "", the user can't implement the bidirectional link.
> Besides, since the protocol says "add these args to the query string", it's nicer to have an ID server URL that doesn't have a query string on it already. Less stuff to implement and/or break.
> Does this make sense?
> y
> -----Original Message-----
> From: Brad Fitzpatrick [mailto:brad at]
> Sent: Tuesday, 17 May, 2005 16:37
> To: yadis at
> Cc: Randy Reddig
> Subject: Two possible notable changes
> Couple things that may or may not happen soon here:
> 1)  We're probably going to rename to OpenID, since the people
>     are offering their domain name.  Thanks!  Much love.
>     We all hate the yadis name anyway.  Yet Another?  So blah.
> And after fighting it initially, I think one of my co-workers and some
> of the Technorati folk are convincing me:
> 2)  We may drop the FOAF bit altogether, and just assert root URLs.
>     This makes sure we don't bind Yadis/OpenID to the "semantic web
>     XML flavor of the day" and get only 33% of the semantic web
>     posse behind us, and 25% next month, and 10% next month, as they
>     slowly move to the next format... FOAF, vCard, hCard, XFN, etc.
>     I don't really want to choose my gang colors, ya know?  I don't
>     much care.
>     People writing a trust system on top of this can work
>     from the ugly HTML (or maybe it's XHTML by then, hah) and use
>     some or all of FOAF, hCard, XFN, etc.
>     So LiveJournal for user "bob" would positively assert the follow
>     root URLs as being owned by bob:
>     And for those geeks out there with their own domain names (yes, I'm
>     one, and you're one, but we're not the common case), you either run
>     your own identity server, or you use somebody else's that's paranoid.
>     For example, LiveJournal's would only assert off-site URLs which
>     come to us with a rel="me" type of deal (not using XFN) as we currently do,
>     with ljuser_sha1=9233b6f5388d6867a2a7be14d8b4ba53c86cfde2
>     Meaning that site, however it referred to us, referred to us saying
>     that it's user "brad" at LiveJournal, and LiveJournal as its identity
>     authority should only assert it if brad is the one logged in.  That
>     way user "attacker" on LiveJournal can't also add the same offsite
>     URL to his external list, because he doesn't control that URL's content.
>     The embedding method may be:
>       <link rel='identity_server' href="" />
>     Somebody tell me the right way.  I don't much care.
>     FOAF's advantage was that its URL resolved to machine-readable content,
>     but any client using it would've had to parse the FOAF and find the URL
>     to show to an end user, because FOAF won't even render in a browser
>     with its recommended mime-type, and looking at a DHTML XML tree in a browser
>     sucks anyway from a user-experience standpoint.
>     A root URL's advantage is that it's probably more stable, if FOAF becomes
>     less hip, and that users can just click it, and trust graph crawlers can
>     use everything in the HTML to do their metrics.  Notable, if an assertion
>     was made that a user is:
>     And links as its FOAF:
>     That FOAF can be trusted based on it being under that original URL.  But
>     if the link rel points to a FOAF on another domain, that
>     FOAF can't be trusted unless it contains, say, an XFN rel="me" pointer
>     back to the asserted domain.
>     But end-users don't care about that.  We'll leave that to the trust metric
>     crew.  We'll build a list of best practices and name each security gotcha
>     so when we see a tool doing something stupid we say, "Yo, Graph-o-matic,
>     you're victim to the That-FOAF-was-never-asserted bug!" and have a link for
>     them.
>     Best practice for end users (and tool vendors) is that FOAF files are under
>     the asserted root, and linked from the root as well, so when the client app
>     is crawling the HTML for that identity server rel tag, it can come back at
>     the same time and give the FOAF URL at the same time (only if it was under!)
>     and say, "yo, here's the identity server, and if this '' URL is
>     asserted, you might want to know this FOAF file would therefore also be
>     asserted, so you can safely link/parse it for some good info."
>     Did I lose you all?
>     The point is to make Yadis/OpenID generic and future-proof.
>     Can I get some +1 and -1 from the audience?  -1 with comments,
>     preferrably.
> - Brad

More information about the yadis mailing list