Two possible notable changes

[Randy Reddig]

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"
        href="http://www.livejournal.com/misc/yadis.bml">

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?

y


-----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:

         http://www.livejournal.com/users/bob/
         http://www.livejournal.com/~bob/
         http://bob.livejournal.com/

    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:

        http://bradfitz.com/

    And bradfitz.com links as its FOAF:

        http://bradfitz.com/foaf.xml

    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
    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 '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,
    preferrably.

- Brad