Jun	JUL	Aug
	03
2004	2005	2006

success

fail

About this capture

COLLECTED BY

Organization: Alexa Crawls

Starting in 1996, Alexa Internet has been donating their crawl data to the Internet Archive. Flowing in every day, these data are added to the Wayback Machine after an embargo period.

Collection: alexa_ed

this data is currently not publicly accessible.

TIMESTAMPS

[About] [Specs] — [Status] [Mailing List] [Wiki]

What

This is a decentralized identity system, but one that's actually decentralized and doesn't entirely crumble if one company turns evil or goes out of business.

An OpenID identity is just a URL. You can have multiple identities in the same way you can have multiple URLs. All OpenID does is provide a way to prove that you own a URL (identity). And it does this without passing around your password, your email address, or anything you don't want it to. There's no profile exchange component at all: your profiile is your identity URL, but recipients of your identity can then learn more about you from any public, semantically interesting documents linked thereunder (FOAF, RSS, Atom, vCARD, etc.).

Anybody can run their own site using OpenID, and anybody can be an OpenID server, and they all work with each other without having to register with or pay anybody to "get started". An owner of a URL can pick which OpenID server to use.

While nothing in the protocol requires JavaScript or modern browsers, the authentication scheme plays nicely with "AJAX"-style setups, so you can prove your identity to a site without bouncing between pages.

Why?

• A lot of other distributed identity systems aren't actually distributed, having one or more parts centrally controlled.
• Logging in to a dozen websites every day is lame.
• Sites that let you enter your name/URL/email/etc and show it without verifying you're you are lame.
• You should be able to keep one (or more) identities over time that stay fixed, regardless of what services are still in existence and you still use a few years down the road.

How's it work?

Here's the big picture: (for details see the specs)

• You maintain a blog at, say, livejournal.com (but this can be anything) and you stay logged in there usually.
• You go to leave a comment at someblog.com (perhaps it's Movable Type, or Wordpress, or DeadJournal, ...) and you don't have an account there, so there's otherwise no way to leave an authenticated comment. But if their blog-system has OpenID support, you see something like: (but hopefully prettier)
• You type "brad.livejournal.com", click login, and then without leaving the page and destroying the comment you were working on typing, the someblog.com server does some work:
  • Looks at your blog, and finds your OpenID server. You don't even know what OpenID is, but your publishing software did it all for you.
  • The someblog.com server returns to your browser and tells it the OpenID identity server it found.
• Then your browser contacts the identity server (see the details) and one of two things happen....
  1. If you've never told your homesite (LiveJournal in this case) that you trust this someblog.com site to know your identity, your homesite tells the page that (without revealing who you are) and the UI changes to something like this: (the UI is left entirely to the sites wanting to confirm an OpenID identity)
  2. Once you've told your homesite (your identity server, LiveJournal) that you trust this site you're visiting, everybody communicates behind the scenes to validate your identity, and you see perhaps:
     Hello, Brad! You're now logged in to someblog.com as Brad from LiveJournal.
• Then you finish your comment, submit it, and the someblog.com server validates your identity behind the scenes, doing some mild crypto stuff explained in specs. If someblog.com is playing by the rules, nobody else can fake your identity. Of course any site can lie, but what fun is a thousand people all saying they're Bill Gates, and message boards allowing it? So respectable sites (where you'd hang out) would play by the rules.

Why not _______?

• Passport -- Centralized registry. Not everybody trusts Microsoft to control their identity.
• TypeKey -- Centralized registry. Not everybody trusts SixApart to control their identity. (But if you already use TypeKey, there's a good chance a future version of TypeKey will also be an OpenID server... I'm pushing for it at least, and volunteered to do the work.)
• Sxip -- kinda distributed, but homesites have to register, and SPOF is the sxip.net DNS staying in existence.
• SAML -- We'd like to use the parts of SAML (from the Liberty Alliance) that are appropriate, but the spec as a whole isn't an answer. Part of our OpenID requirements is that there's an AJAX version, which means the only type of RPC request we can do from the client to a remote host is a javascript or iframe'd request, and not everybody chooses to require SSL, which means the SAML bindings as-is won't work in that case, and we'll have to use our own JavaScript SAML wrapper at least in that case.
• LID -- Assumes that identity URLs are dynamic documents that can handle fancy URL parameters. Not true in real life, which is key for adoption. Also combines too much functionality (authentication + profile exchange) into one spec, which in turn increases the number of dependencies required for a site to implement LID (XPath, etc.) I believe profile exchange should be a separate component/step built on top of authentication, not coupled with it. (yes, the LID people are now working on decoupling this, but it wasn't done when I looked at it.) It's possible we might use LID as one of our recommended profile exchange mechanisms in the future, but the spec as a whole was too heavy.

What about trust?

This is not a trust system. Trust requires identity first.

What about spam?

Again, this is not a trust system.

Somebody could run their own identity server that says they're http://spammer.example.com/000001/ all the way to http://spammer.example.com/999999/ and that's not a goal of this system to prevent. It's another layer's job to say the identities with URL spammer.example.com/* is a spammer, or some ID server is a known spammer, or some particular identity is a known spammer.

What this does prevent is anybody but that spammer from using that identity URL. While somebody else could make their ID server say that they're that http://spammer.example.com/000001/ URL, a) why would they?, and b) unless they also controlled the host spammer.example.com, they couldn't change the <link rel=..> tag to point to their rogue identity server.

What about signing comments?

This system doesn't sign comments. If a rogue site says it's OpenID-enabled but actually isn't and claims to have posts from your identity, that doesn't mean anything. This system isn't designed to prevent that. The goal of this is for sites that do care about preventing spoofed comments/identities to be able to do so, if they play along.

After all, anybody could put up a geocities page right now that says anybody said anything. Do you trust it just because you read it?

There are, however, some pretty obvious spots to insert comment signing into this scheme, so it's likely a future version of this spec will include that, with the identity server providing back a permalink/signature to the comment posted, so readers on some random site can go back to the origin to verify it.

Who owns this?

Nobody should own this. Nobody's planning on making any money from this. My goal is to release every part of this under the most liberal licenses possible, so there's no money or licensing or registering required to play. It benefits the community as a whole if something like this exists, and we're all a part of the community. If something like this already exists and I don't know about it, do let me know. My goal isn't to reinvent the wheel... just find something that everybody can easily use. Update: Thanks for the pointers! We've got at least two other people from similar projects on the mailing list, one of which was nearly identical to this system (mIDm) and had a similar outlook: he wanted something to just work, regardless of who made it, so he'll be helping us out.