5 ms·

I love the concept of Persona and hopes it catches on. One question I can't seem to find the answer to, though. Users are allowed to have multiple emails tied

I love the concept of Persona and hopes it catches on. One question I can't seem to find the answer to, though. Users are allowed to have multiple emails tied to one Persona account. If they login to my site with one email I will see that email address and can bind their account data to it. If they sign in with their other email address, will I be able to identify them as the same person?

saurik 14y ago
Alternatively, what happens when someone graduates, changes ISPs, a domain name expires, or they get a new job, and someone later takes control of their email address? As concrete example, if you attend UCSB, you can easily get them to give you saurik@ right now on various of their servers I used to use for vaguely-official UCSB uses. The problem with Persona is that they simply don't seem to understand that for real people, email addresses are just a convenience, not a canonical way to maintain identity. They also fail to see that even people like myself, who have carefully tended an email address for well over a decade, are not immune to this problem. I have previously commented on this here: https://news.ycombinator.com/item?id=4233391 https://news.ycombinator.com/item?id=4233391
- sergiosgc 14y ago
  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.
kijin 14y ago
IMO, the whole point of tying multiple email addresses to one Persona account is to prevent websites from figuring out that both addresses are tied to the same person. This is very important when you're trying to build an identity system that you want every website to adopt. Users want to split up their lives into distinct identities (e.g. one for professional settings, one for friends, one for family, one for a secret hobby...). A viable identity system should allow people to manage such identities with ease and switch between them at a moment's notice, without letting anybody else find out that @lubujackson on HN is the same person as @blowjobs on a porn site or a member of an unpopular political movement. Even if somebody carefully compared HN databases with the porn site databases. Having said that, people do change their email addresses a lot more frequently than web devs assume. When this happens, they need to update their profiles in every single website where they used the old address. It would be better if my identity were linked to some sort of key that doesn't change, rather than an email address. Likewise, if there is a proliferation of Persona identity providers, some of them will inevitably go out of business after a while. It should be very easy to migrate one Persona account to another.
- sergiosgc 14y ago
  Persona identity providers should be the email providers. If the email provider goes bust, then that identity is lost. If they only stop supporting Persona, then Mozilla steps in and supports Persona on that domain. I think it's quite an interesting approach.

saurik 14y ago

Alternatively, what happens when someone graduates, changes ISPs, a domain name expires, or they get a new job, and someone later takes control of their email address? As concrete example, if you attend UCSB, you can easily get them to give you saurik@ right now on various of their servers I used to use for vaguely-official UCSB uses. The problem with Persona is that they simply don't seem to understand that for real people, email addresses are just a convenience, not a canonical way to maintain identity. They also fail to see that even people like myself, who have carefully tended an email address for well over a decade, are not immune to this problem. I have previously commented on this here: https://news.ycombinator.com/item?id=4233391 https://news.ycombinator.com/item?id=4233391

sergiosgc 14y ago
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.

kijin 14y ago

IMO, the whole point of tying multiple email addresses to one Persona account is to prevent websites from figuring out that both addresses are tied to the same person. This is very important when you're trying to build an identity system that you want every website to adopt. Users want to split up their lives into distinct identities (e.g. one for professional settings, one for friends, one for family, one for a secret hobby...). A viable identity system should allow people to manage such identities with ease and switch between them at a moment's notice, without letting anybody else find out that @lubujackson on HN is the same person as @blowjobs on a porn site or a member of an unpopular political movement. Even if somebody carefully compared HN databases with the porn site databases. Having said that, people do change their email addresses a lot more frequently than web devs assume. When this happens, they need to update their profiles in every single website where they used the old address. It would be better if my identity were linked to some sort of key that doesn't change, rather than an email address. Likewise, if there is a proliferation of Persona identity providers, some of them will inevitably go out of business after a while. It should be very easy to migrate one Persona account to another.

sergiosgc 14y ago
Persona identity providers should be the email providers. If the email provider goes bust, then that identity is lost. If they only stop supporting Persona, then Mozilla steps in and supports Persona on that domain. I think it's quite an interesting approach.