I'm also happy to answer questions in-thread or via email.
I'm a developer on a e-commerce site, when we started out we assumed what Persona assumes, that email is a unique and stable identity. We found out the first day of production mode that this assumption is flawed. People changes email address all the time, it's at least as unstable as their home address, most peoples phone number is more stable.
As software developers we assumed that pretty much no one would ever change their email address, or that at least they wouldn't discard their old one. Regular people however do that. They do not care about their email address.
Is this something that the Persona team that given any thought. If so, what did you come up with?
"Within Persona, your identity is your email address. You can use as many email addresses as you want, but you still only need one password.". - https://login.persona.org/about
However I think it might still confuse customers. A normal user expect to be able to change their email address on the site where they do business and the "MAGIC". I think we would have been better of requiring a username, email and password, rather than using the email as the username. For a large number of people needing to have both username and email seems redundant and stupid, for real life customer... not so much.
My issue is, a customer has X number of orders on our site. Then he/she changes email and expect that using the new email address the old orders are magically available. This seems naive but that is what you have to deal with.
Again I should check to see if Persona indeed maps multiple emails to the same identity. It didn't seem like it when I tested it last, but I would not rule out that I did something wrong.
You can let users change email addresses, and nothing bad will happen. They'll just have to log in with the other address next time.
On the other hand people do change identifiers. They change usernames (jsmith gets married and now wants to be jadams) and they change emails (for the same reason, or because they change ISPs or mobile carriers or whatever). ANY authentication process you use should allow the user to change his identifier (or any other personal attribute even gender) at will.
Internally you deal with this by connecting the identifier to an other token that is the real "permanent" identity for the user in your system. But it's one that's never exposed to the actual user. It sounds like your system was using the email address in the order records to identify the customer. That is what your real problem is, not that people change email addresses.
Why not expose it to the user? Because then they'll want to change it? Are you talking about browser fingerprinting?
We already expose this on the user/email level, where users can link and log in with as many email addresses as they like, under one account (identifier).
People do not believe that their email and identity is in any way linked. You and I might believe that, but don't count on your customers sharing your beliefs.
I think that you might have to explain that a bit.
I think that others try to argue that people use email at least as temporary identity, in the sense that at time t, they identify themselves with at least one of their email addresses. In practice this is enough for many web sites to use the email address as login. Perhaps you are talking about some longer sort of permanence, or uniqueness?
The main exceptions to this are:
1. People who share an email address for convenience, like my grandparents.
2. Group-facade email addresses, like support@whatever.com, which may be routed to several people.
3. Email addresses that don't belong to anyone, like "noreply@whatever.com", or "autogenerated-4b243efa37e5b013a1d90b694c3bcaa3@hell.com"
Even Facebook uses email for login, as does google and just about every other website I use.
It's an interesting and bold statement that needs some supporting eveidence and explanation.
Yes, it does: it means that you cannot count on it as a canonical form of identity for any long period of time, as people expect to be able to change it; in fact, many people go through "the great purge" every couple years, deleting their e-mail address and selecting a new one, in order to purposely reboot the people who have their address: to them, it is a way to purposely restart their identity.
You thereby have to think of e-mail addresses as more akin to your home address. If you ask me to log in with my home address, yes, that works: it doesn't work for everyone, as not everyone in the world has a home address, but the same thing can be said for e-mail addresses. Sometimes people will share a home address, but surprise surprise: sometimes people share e-mail addresses as well.
When I am asked to log in to that form with my home address, and it works, you now might claim I've accepted it as part of my identity. Well, I haven't: I'm going to change my home address at some point, and someone else is then going to start living here, which is exactly what happens to many people who use ISP or University -provided e-mail. Hell, it also happens to people with vanity e-mail addresses if they let their domain registration expire (as happened to one of my friends, who otherwise was using the same e-mail address for a very very long period of time).
Yes: it works temporarily, but it isn't my identity, and eventually it will fail, and unless you are really really weird (like, you are the kind of technology person who would probably consider it digital suicide to allow their domain name to expire, and has had the same e-mail address now for well over a decade), it will fail sooner than later, and may even fail on purpose when users invalidate it.
Of course you should be able to change the email on an account. Usernames can also be changed and are far from canonical. Your point about emails is not invalid, it's just not addressed by usernames, and usernames are actually inferior in that respect.
So, I did not use the word "username" in that comment you are replying to. I thereby will assume you mean "stable and opaque identifier assigned and chosen by the authentication provider", which is what I would argue for (as opposed to attempting to rely on an e-mail address as a stable identifier).
I did use the word "username" in a response to someone else, but that was a very different (and much more abrasive :() argument path.
> Regardless email addresses are more stable and unique than usernames.
E-mail addresses are not more stable that usernames, because e-mail addresses have an external purpose: they receive e-mail. Many people actively go and change their email addresses periodically in order to stop receiving e-mail from people they previously were receiving e-mails from.
A "username" (your word here), especially (and maybe specifically) the "good" kind that is never shown to another user and is just used for account canonicalization, which conceptually could be a random number assigned by the system, is something that the user has no reason to change unless they actually want to never log in to the account again.
E-mail addresses also are tied to the DNS system, which other forms of identification need not be: you can instead tie them to a private key kept by the authentication provider. That would make "me" be A@B where A is a number and B is a key pair. In this way, even if the way you continue to contact my authentication provider lapses (such as attempting to use a hostname) only if the new owner has the same key are they able to claim the identities there (unlike e-mail) and as the user specifier is opaque (not a string that I'm going to care about and want to make pretty, or something I'd ever want to change unless I actively want to lose access to my account) it will not run afoul of the problem with e-mail where people feel compelled to reuse them after some time of abandonment.
The problem then with Persona is that it is the websites consuming it who have the onerous job of dealing with every possible e-mail address change a user may request. With more classic attempts at federated login, users may end up with multiple authentication providers that can become somewhat confusing, but they demand to change authentication providers and especially lose access entirely to authentication providers sufficiently rarely that it is a non-issue to handle the support load of helping users remap their accounts (something that is difficult to automate, of course, in the case where the user already lost access to their old identity). With Persona, this is now something that the user has to do when they change e-mail addresses at every site they may ever have logged in to using their account, ever. :(
"Why Does Amazon.com Allow Multiple Accounts With the Same Email Address?"
http://www.experimentgarden.com/2009/11/why-does-amazoncom-a...
"Note: If you change the e-mail address on your account to an e-mail address that is already associated with another Amazon account, we will ask that you first verify your e-mail address."
-- http://www.amazon.com/gp/help/customer/display.html/?nodeId=...
- Many people never abandon their primary identity email.
- But many other people often abandon their email identity.
- You don't want to use a social network as the gatekeeper to *your* site.
- You don't want to have human support for password resets.
Also, to the extent to which this becomes important, it only becomes important too late, as in after you've already used an address or two. I have had the same address now since 1997 when I registered saurik.com, but I did that because I had in the two years prior "learned the hard lesson" that my ISP-provided e-mail address was doomed to be something I'd end up having to move off of, potentially fairly often.
"Everyone else is doing is doing it that way" isn't a reason to do it that way, especially for a product, like Persona, that is supposedly about fixing what is wrong in what everyone else is doing.
No, it doesn't.
> At any given time, an email account is probably linked to only one person.
Lots of people have shared email accounts. And even without that the "at any one time" is one reason why it doesn't work as an individual identifier, its not stable. (Since cell phones and number portability have become ubiquitous, phone numbers are probably better than email addresses at this, but share the same sorts of problems.)
> 2. No alternative exists, in real world use, that really looks better
Sure alternatives exist. While its often important to have a contact email address connected to an identity, there is no reason to have an externally-meaningful value that is inextricably tied to the online identity, particularly if that value doesn't have an intrinsic, unique, and stable link to a particular person.
You're justifying choosing a bad natural key with the argument that its the least-bad natural key, when not only is the proposition that the proposed key is the least-bad natural key somewhat dubious, more importantly, the use case calls for a key, but there is no reason for it to be a natural key.
Of course it has to be a natural key! Are you expecting that users will learn your theoretically perfect surrogate key? Do you understand that you will be competing for space in people's brain? For what reason? Because shared email accounts break the many to one relationship on mail <-> person?
I'm not sure why users should ever need to know the key.
> Because shared email accounts break the many to one relationship on mail <-> person?
No, I probably wouldn't even both with addressing the problem of shared email accounts (which would require some discriminator), but with one person having multiple email accounts and email accounts changing over time. These things indicate that accounts should have transitory, one-to-many relationships to email addresses, rather than email addresses serving as a key.
The only requirement for the email to be a key to the account is the association of one email to one person. A person can have more than one email, at different times or at the same time. The only thing that can't happen is one email mapping to two individuals. Full circle: the majority of emails do map to one individual and the cases where they do not map, are not enough to preclude the use of emails as keys.
Perhaps the confusion occurs because you think I'm defending email as a primary key for the account. I'm not. It's one key, not the primary key.
It's a hard problem because anything real world like a identifying number is flawed for anonymity. There needs to be a unique identifier for a web entity.
It's always annoyed me that solutions like persona etc are approaching this by simply replacing email, when shouldn't they be abstracting my online identity? I hold several "personas" throughout various sites, email addresses, and applications. However, I don't want a product that simply merges them, I want a product that is more of a "meta-persona", that lets me easily track, manage, and expand them.
"It maps multiple emails to the same identity, in that you use the same password to log in with all of them. The end site gets the email you log in to the site with (I can log in to Persona with email A but let all sites know email B every time."
So based on that, if you want to expose three different identities to 3 different sites, you can set up Persona to do that automatically, without having to remember the separate emails and passwords you used for each one. I guess the only problem would be if you needed multiple separate logins to the same site, but unless it's your own site, presumably that should be rare.
If a user does change their email they can log in as their old email and simply update their account to their new one.
Email is a much better system than username because people constantly forget the unique username they created for that specific site. You don't really forget your email very often.
If you're stupidly using your email as your username then your email becomes public should the site you're on show, at any point, your username.
Which is why sites correctly done use the email for login but display a username and never your email. Correctly done sites also forbid username from containing '@', so that you can be sure that people don't do anything retardedly stupid like using their email as username, which would be displayed publicly on the site...
The proliferation of sites that only or primarily accept social logins seem to suggest that it's not a sound premise. However, I'd be interested to know if you guys have some data that's not shared in the article that suggests it is.
> The proliferation of sites that only or primarily accept social logins seem to suggest that it's not a sound premise.
I'm not sure that necessarily follows. Google's own advertising for G+ authentication touts its privacy features, which suggests that Google also believes that users are uncomfortable with social auth as it exists today.
(Anecdotes aren't data, but they're what I have on hand at the moment. Sorry! Still at PyCon.)
And again, autocorrect makes someone look the fool.