Two possible notable changes
brad at danga.com
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 "http://bradfitz.com" as an
LiveJournal user "attacker" goes to http://ydnar.com/ to leave a comment.
ydnar.com fetches bradfitz.com, sees the OpenIDServer is
http://www.livejournal.com/misc/yadis.bml says "This is user attacker, and
attacker lists http://bradfitz.com as an assertable URL.
Dear attacker, says LJ, do you want to trust ydnar.com? Why yes I do,
LJ tells ydnar.com that attacker is http://bradfitz.com.
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 (bradfitz.com) must reference
the identity server with extra arguments to settle the dispute about who
the owner of bradfitz.com is --- bradfitz or attacker.
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 "http://bradfitz.com" as an assertable URL.
> - http://bradfitz.com has the following link:
> <link rel="OpenIDServer"
> Technically, any user could list "http://bradfitz.com" as an assertable URL, but unless they /control/ "http://bradfitz.com", 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?
> -----Original Message-----
> From: Brad Fitzpatrick [mailto:brad at danga.com]
> Sent: Tuesday, 17 May, 2005 16:37
> To: yadis at lists.danga.com
> 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 OpenID.net 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="http://www.livejournal.com/misc/yadis.bml?ljuser_sha1=9233b6f5388d6867a2a7be14d8b4ba53c86cfde2" />
> 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 bradfitz.com links as its FOAF:
> That FOAF can be trusted based on it being under that original URL. But
> if the bradfitz.com 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
> 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 'bradfitz.com' 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,
> - Brad
More information about the yadis