First, nothing in this description/recap touches on my original complaint--the one that started my involvement in this thread and which was your first reply to me--that e-mail addresses get reused, and thereby are dangerous to use as your canonical identification identifier; you mention that they are volatile, but you fail to take into consideration that they are sufficiently volatile as to be lost and reassigned to others. I cannot tell if this was simply ignored or actively dismissed.
This is for two reasons: first, because they are tied to the DNS system, a system that is subject to political and economic issues. Tying the namespace of users eventually to the DNS system means that if a domain name is lost and then owned by someone else, that they are now in control of the identities of everyone associated with the domain name.
There is no reason this needs to be the case: a sane federated identity system, in my book, would solve this by tying identities instead to a private key that is stored by the authentication provider. Thereby, if the authentication provider goes out of business, their key would be lost, and would not be reassigned to anyone willing to pay $12.
Secondly, your fundamental disagreement is about the ramifications of a bullet point I never agreed with (as opposed to, seemingly, about whether we see eye-to-eye on that bullet point): I do not believe that identity identifiers must be memorizable by users, I believe that only the presentation identity must be memorizable by users.
To demonstrate the difference, I am 116098411511850876544@google and 3614794@facebook. However, despite the fact that I log in to numerous external websites using these authentication providers, I have only at occasional times remembered the shorter Facebook number, and I have never remembered (nor do I believe I would ever remember) that Google number.
Yet, all I need to log in is my e-mail address. Yes: I end up using my e-mail address to log in. However, the concept of my identity is not stored via that e-mail address: that's just one of the many things associated with my account at the authentication provider, and it will change over time. I could use any other identifier, including crazy ones like "what were the last three things you did on this website, and give us a list of at least five of your friends" (which is similar to something Skype once used to verify that I was the owner of my account when they thought it had been hacked by someone trying to steal my credits).
In fact, despite being one of those weird tech people who have actively avoided changing my e-mail address in nearly ever, I actually have changed my Facebook e-mail, as originally Facebook was for students only. Therefore, my account was originally connected with saurik@umail.ucsb.edu.
However, I later changed my account to be attached to saurik@saurik.com, which I consider to be "mine". Then, at some point later, long after I graduated, UCSB removed my access to my old student accounts, and I'm pretty certain will happily give them to others. Of course, this means that for any website that considers e-mail addresses to be related to security or where it can be considered a canonical store of identity (although I maintain that this second category is actually very rare: only Persona seems to make this mistake) that I may have forgotten to go find and update, I'm now screwed: someone else can access my account.
Now, when I log in to Facebook to third-parties that I previously logged in to, they still work. They still work, because Facebook, unlike Persona, did not ever use my e-mail address as the canonical definition of my identity. None of the tons of websites out there that I've ever used Facebook with ever even saw saurik@umail.ucsb.edu, and if they did it was metadata associated with my account: it wasn't "my account".
This is a critical detail. The different is enormous, and is especially noticeable due to the way Persona is designed, where you don't even really need an active third-party to manage your identity, and are instead supposed to be able to just magically use any e-mail address: some e-mail addresses would suck even worse than others (example being my UCSB address), but any e-mail address is something that is volatile.
You need that middle-man, even when you are federated such as with OpenID (or via OAuth with random APIs for identifiers), in order to isolate the volatility of e-mail addresses from the people handling federated login. Otherwise, you end up in federated hell, where every time a user changes their e-mail address instead of contacting one party, they have to contact every party, defeating the entire point of single sign-on.
To take a concrete example of this, I received a support e-mail from someone saying that they are changing their e-mail address redacted12323@gmail.com (yes, with a random 5 digit number at the end) to redactedqredacted93@gmail.com. As Google internally does not understand this very argument that e-mails are something people want to be volatile refuses to let you attach or move around Gmail accounts to Google account identities, this means that their identity on my site changed, and I had to reassign them. I did this, and seriously two days later (today) I received an e-mail saying that they have lost access to redactedqredacted93@gmail.com and now want it to be redactedqredacted94@gmail.com.
In contrast, when a user changes their Facebook username (which is equivalent to changing their Google username, and changes their @facebook.com e-mail address similarly to their @gmail.com e-mail address), they don't need to even think about how this affects other websites, as Facebook doesn't map e-mail addresses back to the identifiers that they return: they return an opaque number. This is glorious: they get it; they make the value of federated login actually be a benefit for users and for websites. Some entities in the system (and not just one: hence how Facebook, Yahoo, and Google can all provide this service) can thereby specialize in maintaining and controlling identity, and other entities in the system can spend all of their time consuming identity.
This means that the user has to do less work, and the website has to do less work: win/win. In your scenario, where the e-mail address is canonical, the user has to go to every single website and update their identity, and the websites have to provide systems to let users do this (which isn't even something that cleanly automates given that almost every time people bring this kind of issue up to me, it is because they no longer have access to the old account, and thereby can't use it to authenticate at my site anymore).
At this point, you might now argue that "well, that's OpenID, and OpenID failed". First, it isn't clear why it failed: Yahoo claims from user studies that it failed because the UI for it was so horrible, and that made a lot of sense to me. They even recommended a potential solution to that problem, and its a solution that I don't think is inherently worse for anyone than Persona. It certainly isn't clear, however, that Persona makes any sense. I in fact just tried to use Persona, and I found it horribly confusing; and in the end actually haven't succeeded in logging in to the website in question (at some point in the flow I seem to have caused a persistent error that now won't clear). It certainly was more complex than using "classic" federated authentication, and it seemed like that complexity was directly related to the website in question having to go further out of their way than they did with previous solutions to abstract the identification tokens (my e-mail address) from my account.
Finally, my point about the tens of millions of users was not in regards to an appeal to authority: it was a defense to the actively condescending tone of your "sorry", which I found to be downright belittling and inappropriately unrelated to my arguments (hence the "look" at the beginning of that clause). That "sorry" you added is a rhetorical construct that does nothing other than to annoy your opponent (hence my repeating it back to you in quotation marks for emphasis to demonstrate that "I noticed"). Think of it more like you patting my head and going "kid, I don't think you understand" in an attempt to turn my youth into an argument point, and me feeling the need to say "look, I'm over 30, I'm not a kid anymore". I found that "sorry" so bothersome that I will be honest: I was downright shocked when you were willing to even go down a point-by-point argument rather than just turning more rhetoric back at me; I was absolutely certain you were just going to flip me off again in your reply to my further-argued comments, although I guess I sort of feel you did anyway by calling me "vain"... :( I am not certain why you feel like belittling and insulting me directly (as opposed to my arguments) is a logical argument path :(.
The "Sorry" had no ill Intention. My apologies if I conveyed the wrong meaning.
Anyhow, I now fully understand your position. I still maintain my point, and further discussion would only be useful if accompanied by beer. All in all, it's the ever present tug between theoretic perfection and real world constraints. It's doubtful this back and forth would ever reach an acceptable compromise.
This is for two reasons: first, because they are tied to the DNS system, a system that is subject to political and economic issues. Tying the namespace of users eventually to the DNS system means that if a domain name is lost and then owned by someone else, that they are now in control of the identities of everyone associated with the domain name.
There is no reason this needs to be the case: a sane federated identity system, in my book, would solve this by tying identities instead to a private key that is stored by the authentication provider. Thereby, if the authentication provider goes out of business, their key would be lost, and would not be reassigned to anyone willing to pay $12.
Secondly, your fundamental disagreement is about the ramifications of a bullet point I never agreed with (as opposed to, seemingly, about whether we see eye-to-eye on that bullet point): I do not believe that identity identifiers must be memorizable by users, I believe that only the presentation identity must be memorizable by users.
To demonstrate the difference, I am 116098411511850876544@google and 3614794@facebook. However, despite the fact that I log in to numerous external websites using these authentication providers, I have only at occasional times remembered the shorter Facebook number, and I have never remembered (nor do I believe I would ever remember) that Google number.
Yet, all I need to log in is my e-mail address. Yes: I end up using my e-mail address to log in. However, the concept of my identity is not stored via that e-mail address: that's just one of the many things associated with my account at the authentication provider, and it will change over time. I could use any other identifier, including crazy ones like "what were the last three things you did on this website, and give us a list of at least five of your friends" (which is similar to something Skype once used to verify that I was the owner of my account when they thought it had been hacked by someone trying to steal my credits).
In fact, despite being one of those weird tech people who have actively avoided changing my e-mail address in nearly ever, I actually have changed my Facebook e-mail, as originally Facebook was for students only. Therefore, my account was originally connected with saurik@umail.ucsb.edu.
However, I later changed my account to be attached to saurik@saurik.com, which I consider to be "mine". Then, at some point later, long after I graduated, UCSB removed my access to my old student accounts, and I'm pretty certain will happily give them to others. Of course, this means that for any website that considers e-mail addresses to be related to security or where it can be considered a canonical store of identity (although I maintain that this second category is actually very rare: only Persona seems to make this mistake) that I may have forgotten to go find and update, I'm now screwed: someone else can access my account.
Now, when I log in to Facebook to third-parties that I previously logged in to, they still work. They still work, because Facebook, unlike Persona, did not ever use my e-mail address as the canonical definition of my identity. None of the tons of websites out there that I've ever used Facebook with ever even saw saurik@umail.ucsb.edu, and if they did it was metadata associated with my account: it wasn't "my account".
This is a critical detail. The different is enormous, and is especially noticeable due to the way Persona is designed, where you don't even really need an active third-party to manage your identity, and are instead supposed to be able to just magically use any e-mail address: some e-mail addresses would suck even worse than others (example being my UCSB address), but any e-mail address is something that is volatile.
You need that middle-man, even when you are federated such as with OpenID (or via OAuth with random APIs for identifiers), in order to isolate the volatility of e-mail addresses from the people handling federated login. Otherwise, you end up in federated hell, where every time a user changes their e-mail address instead of contacting one party, they have to contact every party, defeating the entire point of single sign-on.
To take a concrete example of this, I received a support e-mail from someone saying that they are changing their e-mail address redacted12323@gmail.com (yes, with a random 5 digit number at the end) to redactedqredacted93@gmail.com. As Google internally does not understand this very argument that e-mails are something people want to be volatile refuses to let you attach or move around Gmail accounts to Google account identities, this means that their identity on my site changed, and I had to reassign them. I did this, and seriously two days later (today) I received an e-mail saying that they have lost access to redactedqredacted93@gmail.com and now want it to be redactedqredacted94@gmail.com.
In contrast, when a user changes their Facebook username (which is equivalent to changing their Google username, and changes their @facebook.com e-mail address similarly to their @gmail.com e-mail address), they don't need to even think about how this affects other websites, as Facebook doesn't map e-mail addresses back to the identifiers that they return: they return an opaque number. This is glorious: they get it; they make the value of federated login actually be a benefit for users and for websites. Some entities in the system (and not just one: hence how Facebook, Yahoo, and Google can all provide this service) can thereby specialize in maintaining and controlling identity, and other entities in the system can spend all of their time consuming identity.
This means that the user has to do less work, and the website has to do less work: win/win. In your scenario, where the e-mail address is canonical, the user has to go to every single website and update their identity, and the websites have to provide systems to let users do this (which isn't even something that cleanly automates given that almost every time people bring this kind of issue up to me, it is because they no longer have access to the old account, and thereby can't use it to authenticate at my site anymore).
At this point, you might now argue that "well, that's OpenID, and OpenID failed". First, it isn't clear why it failed: Yahoo claims from user studies that it failed because the UI for it was so horrible, and that made a lot of sense to me. They even recommended a potential solution to that problem, and its a solution that I don't think is inherently worse for anyone than Persona. It certainly isn't clear, however, that Persona makes any sense. I in fact just tried to use Persona, and I found it horribly confusing; and in the end actually haven't succeeded in logging in to the website in question (at some point in the flow I seem to have caused a persistent error that now won't clear). It certainly was more complex than using "classic" federated authentication, and it seemed like that complexity was directly related to the website in question having to go further out of their way than they did with previous solutions to abstract the identification tokens (my e-mail address) from my account.
Finally, my point about the tens of millions of users was not in regards to an appeal to authority: it was a defense to the actively condescending tone of your "sorry", which I found to be downright belittling and inappropriately unrelated to my arguments (hence the "look" at the beginning of that clause). That "sorry" you added is a rhetorical construct that does nothing other than to annoy your opponent (hence my repeating it back to you in quotation marks for emphasis to demonstrate that "I noticed"). Think of it more like you patting my head and going "kid, I don't think you understand" in an attempt to turn my youth into an argument point, and me feeling the need to say "look, I'm over 30, I'm not a kid anymore". I found that "sorry" so bothersome that I will be honest: I was downright shocked when you were willing to even go down a point-by-point argument rather than just turning more rhetoric back at me; I was absolutely certain you were just going to flip me off again in your reply to my further-argued comments, although I guess I sort of feel you did anyway by calling me "vain"... :( I am not certain why you feel like belittling and insulting me directly (as opposed to my arguments) is a logical argument path :(.