A touch and flee commentary roughly touching many important aspects of identity management, with lots of assumptions with which I disagree. It'd take me a while to deconstruct all of them correctly, so I'll try to aim just for the most important points.

Your central point is that, for a given identity, there is a set of emails that map to that identity (N-1 relationship). Moreover, this set is itself volatile, as people add and remove emails to the set that maps to their identity.

There is no relation of one person to one email (it is one to many). This was approached during the discussion, and I believe you agree that this is not an issue.

There are cases where the relation of email to person is one email to many people. This was approached during the discussion, and it just invalidates the usage of group emails as identity identifiers (stuff like info@example.com). It does not preclude the concept of email as identity identifier. I believe you agree.

Where you have a specific point against the usage of email as an identifier is on the fact that the email is volatile. Volatility is a flaw, which must be worked around, but it's not a showstopper. Further, there's absolutely no evidence that a pure identity provider, such as OpenID, wouldn't be as volatile as email. It does not have the scale needed to prove non-volatility yet.

I think we agreed on the point about natural/surrogate keys.

We then briefly touched the question of identity provider (up to here the discussion was about the identity identifier). I think we agree that the provider must be distributed, hence your reference to OpenID (albeit the reference to FB, which I think was related to the point about natural/surrogate keys).

Briefly, in summary:

- The identity identifier must map one identifier to one identity. (ok for emails, ok for OpenID, ok for most auth providers such as Google or FB)

- The identity provider must be distributed. (ok for email and OpenID, ko for Google, FB and other social networks). Social networks are not acceptable because they are not distributed enough. Were there as many social network providers as there are email providers, on a on open ecosystem, where users could run their own social network on their own domain, social networks would be acceptable.

- Identity identifiers must be memorizable by users.

And here, on this last point, is the crux of our disagreement. You are of the opinion that, since emails are volatile, users will forget their previous email, or discontinue its service, and will be locked out of access to their indentity on services tied to the email. I am of the opinion that users will never remember (or include in their daily routine) yet another identity identifier (the OpenID URL, or any other identity specific service).

The fact of the matter is that space in consumer minds is limited (heck, marketing is a whole field of study on grabbing a share of consumer mind). Being limited, you have two options:

a. Aim for the ideal scenario, go for OpenID or other pure identity provider, aim for theoretical perfection, and risk no adoption because users can't be bothered to use it; or

b. Use the one identity that already exists, that users already remember, that almost fits the bill, and work around volatility, the only big hurdle, by having the ability for users to change/add/remove emails (identity identifiers) associated with each account. This is the approach of Amazon or Linkedin, for example.

Aiming for a), while theoretically optimal, introduces the failure scenario of users going for the other identity that already exists in their daily routine: Facebook/google accounts. This is a catastrophic scenario.

Optimum is often the enemy of good.

Look: You brought a smile to my face with the reference to a tens millions of users site. It's a vain appeal to authority. I also manage a tens of millions of users site, with both federated and native authentication.