>>36 You're confusing identity with authentication. The OpenID spec-writers did the same thing.

Here's a trick: What is the value of knowing that person can authenticate as Mike Linksvayer? Versus the value of knowing that person is Mike Linksvayer?

It proves that the user has control of (or can read) Mike's email, can send DNS packets, works for AT&T, PAIR, or any of a dozen other single-points-of-failure. It doesn't prove that this person wrote other blog entries, or that they used another service previously. Only that they have (access to) the same authenticators. Mike retains plausable deniability- if he eats your babies, you probably won't be able to sue him because you won't be able to prove that he actually did it.

An Identification protocol necessarily prevents the user from disavowing their own identity (or without some well-understood cost). That means that if Mike identifies himself, and does wrong, you can prove it was him.

SSL is supposed to be an identification protocol, but nobody actually goes through the work of checking the identity of SSL subscribers, and QuickSSL is cheap. As a result, if you get scammed by a website, there isn't a lot you can do- even if they got an SSL key.

OpenID is an authentication framework. It theoretically could be used in combination with some use-policy and an identification protocol, but OpenID punts on these things in an effort to get deployment/popularity.

An anonymous system avoids these things: You don't know who I am, and you don't have any expectation to know who I am.