3 ms·

What is the alternative, then? That's the million dollar question. Even phone numbers, which have a large personal switching cost are ephemeral for many people.

What is the alternative, then? That's the million dollar question. Even phone numbers, which have a large personal switching cost are ephemeral for many people. SSNs or other government mandated IDs are not acceptable. I see no better alternative.

saurik 14y ago
First, you seem to have immediately disciunted standard usernames, which have flaws, but are not "fundentally flawed". Second, you seem to assume that the primary key has to be something the user even knows; I do not. My Facebook account has a number: that number will never change, no matter what I do to my email addresses or even if my Facebook username changes; that number, and that number alone, defines my account. I will be honest and say I actually did have that number memorized a long time ago, but for years now I have not known it, nor would 99.999% of Facebook users. The same is true of Google's account infrastructure (which even has much much longer numbers). When you use OpenID, you get back an opaque string, which can be arbitrarily complex and encode whatever is required by the federated identity provider. There simply are not fixed identity nodes for people: you have to make them.
- sergiosgc 14y ago
  Sorry, usernames are not identity providers, they do not cross system boundaries. Perhaps we are discussing different problems. Facebook is one identity provider. I'm not comfortable having all of the Internet, to use a reduction to the absurd, dependent on Facebook. Persona is distributed, which is, for me, a primary requirement for an identity system.
  - saurik 14y ago
    "Sorry", but you just moved the centralized identity to a different location, you aren't magically removing it: in fact, you can't magically remove it, because there is no such thing as a universal canonical form of identity. If there was, we would just use that instead of all of these more complex forms of identity we build up. In the case of the e-mail address, you are moving it to the person providing the domain name the e-mail address is on; this is thereby explicitly why I brought up OpenID--which you seem to have totally ignored--as it is also a distributed system but yet it doesn't force the incorrect assumption that Persona does (specifically, that e-mail addresses are canonical identification mechanisms for users, and so nigh-unto encourages opaque tokens to be returned). Let's put this another way: you seem to believe that there is a way to assign a token to a user in a way that works for them no matter where they are. I believe that that entire concept is a fantasy. In particular, I believe the one that Persona chose, which you seem to want to defend, only works for a very weird subset of users that are technical enough to understand that others make this incorrect assumption, and then organize their lives around it. In comparison, once you assume that there is no such identifier, you start asking how you federate the choice, and you end up with the idea of "identity providers". However, you now have no stable way of holding on to identity as you change providers. I maintain that is an unsolvable problem, and it should be treated as an unsolvable problem: the concept of an identifier that can cross multiple identity providers is, again, a fantasy. So the result is that you now have to ask the question of what identifier is used within an identity provider. I maintain that e-mail addresses are a horrible horrible choice, as they are known to be something that the people who provide them are known to reuse, and they are things many users want to be able to change often. Instead, it should be encouraged to make the token entirely opaque, with a requirement in the spec that "this token will never get reused by any other user using your identification provider ever in the future". AFAIK, OpenID states exactly this. And yet, when I go to log in to a website using OpenID, I can select Google as my authentication provider, and then log in with my e-mail address. Later, when my e-mail address changes, I'll be able to log in with a different e-mail address, and Google will assign me the same OpenID identifier for my federated login with other websites. You end up in a similar boat if you use the various OAuth flows that other companies use, such as with Facebook, then using an API to get the stable identifier (which for Facebook is a number). Look: I maintain a website with tens of millions of worldwide users, and I only have federated login. I deal with the issues of federated login day in and day out. I deal with users from very diverse user communities, and I see how they treat their e-mail addresses (as sadly, Google will not let you change your Gmail address without getting a new account, so a lot of users are forced into situations where their identification changes when there was no real reason why it should have been required). When I look at Persona, all I see is a support nightmare due to a fundamentally invalid assumption.
    - sergiosgc 14y ago
      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.

saurik 14y ago

First, you seem to have immediately disciunted standard usernames, which have flaws, but are not "fundentally flawed". Second, you seem to assume that the primary key has to be something the user even knows; I do not. My Facebook account has a number: that number will never change, no matter what I do to my email addresses or even if my Facebook username changes; that number, and that number alone, defines my account. I will be honest and say I actually did have that number memorized a long time ago, but for years now I have not known it, nor would 99.999% of Facebook users. The same is true of Google's account infrastructure (which even has much much longer numbers). When you use OpenID, you get back an opaque string, which can be arbitrarily complex and encode whatever is required by the federated identity provider. There simply are not fixed identity nodes for people: you have to make them.

sergiosgc 14y ago
Sorry, usernames are not identity providers, they do not cross system boundaries. Perhaps we are discussing different problems. Facebook is one identity provider. I'm not comfortable having all of the Internet, to use a reduction to the absurd, dependent on Facebook. Persona is distributed, which is, for me, a primary requirement for an identity system.
- saurik 14y ago
  "Sorry", but you just moved the centralized identity to a different location, you aren't magically removing it: in fact, you can't magically remove it, because there is no such thing as a universal canonical form of identity. If there was, we would just use that instead of all of these more complex forms of identity we build up. In the case of the e-mail address, you are moving it to the person providing the domain name the e-mail address is on; this is thereby explicitly why I brought up OpenID--which you seem to have totally ignored--as it is also a distributed system but yet it doesn't force the incorrect assumption that Persona does (specifically, that e-mail addresses are canonical identification mechanisms for users, and so nigh-unto encourages opaque tokens to be returned). Let's put this another way: you seem to believe that there is a way to assign a token to a user in a way that works for them no matter where they are. I believe that that entire concept is a fantasy. In particular, I believe the one that Persona chose, which you seem to want to defend, only works for a very weird subset of users that are technical enough to understand that others make this incorrect assumption, and then organize their lives around it. In comparison, once you assume that there is no such identifier, you start asking how you federate the choice, and you end up with the idea of "identity providers". However, you now have no stable way of holding on to identity as you change providers. I maintain that is an unsolvable problem, and it should be treated as an unsolvable problem: the concept of an identifier that can cross multiple identity providers is, again, a fantasy. So the result is that you now have to ask the question of what identifier is used within an identity provider. I maintain that e-mail addresses are a horrible horrible choice, as they are known to be something that the people who provide them are known to reuse, and they are things many users want to be able to change often. Instead, it should be encouraged to make the token entirely opaque, with a requirement in the spec that "this token will never get reused by any other user using your identification provider ever in the future". AFAIK, OpenID states exactly this. And yet, when I go to log in to a website using OpenID, I can select Google as my authentication provider, and then log in with my e-mail address. Later, when my e-mail address changes, I'll be able to log in with a different e-mail address, and Google will assign me the same OpenID identifier for my federated login with other websites. You end up in a similar boat if you use the various OAuth flows that other companies use, such as with Facebook, then using an API to get the stable identifier (which for Facebook is a number). Look: I maintain a website with tens of millions of worldwide users, and I only have federated login. I deal with the issues of federated login day in and day out. I deal with users from very diverse user communities, and I see how they treat their e-mail addresses (as sadly, Google will not let you change your Gmail address without getting a new account, so a lot of users are forced into situations where their identification changes when there was no real reason why it should have been required). When I look at Persona, all I see is a support nightmare due to a fundamentally invalid assumption.
  - sergiosgc 14y ago
    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.