Using email as an online identity is a bad idea. Not as stupid as using a phone number, but still bad.
Why? Because you can't own an email address forever.
Either you pay for the domain, or pay someone who has the domain, or get it for free from someone who has the domain.
If you get it for free from someone, that someone can delete your account at any time.
If you pay for it, you may one month/year forget or be unable to pay, and then you lose it. Most likely forever.
All identity is transient. Online the thing we care about is whether or not an identity maps to an individual. I only need to know that Wolf480pl is Wold480pl.
Even things like name will change as people live their life.
The only way to avoid changing identifiers is to force people to be on a central database, ala China's system, where we lose any sense of privacy or anonymity.
@Wolf480pl I see several distinct discussions here. First is that you should be free to change identifiers. Yes, I agree. Is there something stopping you that you're reacting to?
Proving you're the same... Well isn't that the idea of having both an identifier and a secret? I guess you're saying that on a social network or email that these are the same? So then we'd need some kind of secondary authentication? Cryptographically signed email or posts?
>is there something stopping you from changing identifiers?
No. There is something stopping me from _keeping_ the same identifier.
The fact that domains expire if not renewed. The fact that my email provider can decide to shut down and I won't be able to do anything about it.
As for proving that I'm the same:
Assuming passive attackers, it may be enough if I prove to you that I control certain email address / domain name / ip address / etc.
That's how password reset works.
And, with the assumption that we both trust my email provider or my domain registrar and my ISP, this will work... until I lose the domain and/or email.
Because I can't guarantee that I will control them forever.
@Wolf480pl There's implementation and there's theory. For implementation, what are the takehome lessons? I see a few:
1. Don't use external identifiers as user IDs
2. Allow for migration of identifiers (email, etc.)
3. Request secondary or tertiary authentication schemes when possible.
Do you agree? Is there more?
I'd say 1 for sure, assuming we define external as "outside our administrative domain".
Ofc there are exceptions (eg. if your service is just an addon to a 3rd party service).
2. is tricky, because if you're not careful when implementing it, you'll make it easier for attackers to hijack the account without making it any more secure for the user.
Both 2 and 3 really depend on your authorization policies, i.e. what level of authentication is needed to perform certain actions.
Actually, I think we should amend 1 to allow external identifiers that are fully under user's control. So that smartcards, etc. are allowed.
4. don't use identifiers which can be revoked by 3rd parties.
emacsen.net is one server in the network