People dislike usernames, they want to be able to choose non-unique ones rather than end up with user53267 or something inane.
People lose devices, just storing a secret UUID in their cookie, or using a passkey from their device isn't going to work.
There is no ideal solution except to blend a variety of things together, for some people email is pretty stable for long time and they like it as the identity, for others their usernames are stable and they prefer that as the identity... though I know of no-one that has had the same primary device for more than years (not decades) so perhaps that one will never work.
I do think this is important though, where it comes up a lot is a work email account, a [email protected], and how all of the vendor software utilises "Sign in with Google", and it's the email address they then store in the vendor app as the identifier...
People get married, people get divorced, people transition, people move culture and choose new names... names change, and so do email addresses.
Perhaps OIDC and the like needs a new extension: a standard API to change a username, and a standard API to change an email address.
The oldest email that I can connect to is more than 20 years old. I'm not using it anymore but it's older than any of my phone number or physical address. I don't think we can do better, except with official indentifiers like I'd card or social security number
My "favorite" of those email changes is the self-inflicted contractor postfix change. I've worked at places where a conversion to employee forces the creation of a completely new account, and lacking a simple, single permission systems, the act of converting means spending a good 3 weeks trying to get access to systems one had access the day before.
This is extra fun when the company in question does a lot of their business offering complicated accounts to customers, and has an external facing identity solution that deals with all of this easily: just not for their own workers, including those maintaining the external-facing identity system.
I liked Discords old scheme where you had an email and a display name. Everyone had the numbers so they didn't matter. When they switched to unique account IDs I was kind of bummed, but I'm still curious why they switched.
1. Use a guid-like value as your internal identifier. All internal references in your databases to a user should use that.
2. Use a second user friendly identifier for the user to login (i.e. Email). Feel free to rebind this if the user needs to change it. Keep a 1-to-1 relationship between the two.
What about domain names? Emails are bound to a domain name by definition, and indeed domain name IS designed as a good identity and can be used to host an email. See how domain names are owned by large corporations and trusted since day one and never lost, as long as you keep it carefully. It requires WHOIS information as the authoritative information of domain owner. An account based on username and password is what you usually need to access it, but if you are serious you can always choose a domain registar that is serious about keeping your domain name. It’s not free but it costs nuts compared to the cost of losing it, and let’s not forget that there is a cost behind hosting emails even if it’s given for free.
I once had my email change because my ISP was bought out. Absolutely nothing I could do about it. The old email was forwarded for 12 months, then cut off completely.
Passkeys aren’t device-bound. I think they’ll work just fine.
The real problem, though, is that we seem to need digital identity solutions to be perfect as opposed to “good enough”. No solution is perfect and we’ll be stuck on email as long as the enterprise security nuts (who need everything device-bound and vendor attested) and anon-in-the-ether privacy schoolers (who think any stable identifier whatsoever is a heinous crime) are part of the conversation.
Imagine if everyone just used mobile drivers licenses issued to whatever self-sovereign wallet the user chooses. Identity issuing, revocation, and recovery is then handled by all the things society has already built to handle meatspace identity. Account recovery involves a trip to your local gov’t office to re-issue your ID credential. Which means you need some chain of trust to your birth certificate. You’re going to treat your mDL credential wallet with a lot more reverence if that’s the recovery flow, so some of these problems solve themselves if we stop using punk short-names everywhere online.
Relying parties that need human uniqueness, age, and/or nationality guarantees use the mDL verifiable credential. Law probibits relying parties from aggregating and selling/transferring information obtained for purposes of authentication from a VC. Ad-tech privacy problem solved.
Services that don’t need proof of human uniqueness etc. can just skip the VC part of the equation and use basic passkeys and implement short-name reclamation.
I usually dislike the idea of inviting government into this space, but if there's anything that governments have traditionally done decently well and should do (it's usually within their mission statement) its identity. Passports are really the primary identity layer of Earth.
Ideally in a perfect world we'd have governments run OIDC systems similar to the US login.gov and these would delegate from an international master OIDC system at the UN. Everyone would have their citizenship passport ID and their UN ID, and the latter could serve as a "break glass" master key to support immigration and also limit the ability of countries to "digital death penalty" people.
I can think of some dystopian outcomes here, but IMHO they are not worse than the dystopian outcomes that come from corporate monopolist control of digital identity. At least in democracies one has some nominal influence over one's government and the latter is bound by the rule of law, and if you don't live in a democracy you can (or should be able to) leave.
You're right that identity is hard, and I think most of why it's hard is human rather than technical. One could create a decentralized identity layer from a block chain fairly easily but people would lose their keys etc.
Long lasting usernames across websites is the worst for privacy though, unless the username is not public. In general, it's best if the unique identifier is only known to the user.
I've seen quite personal details being leaked because sometimes even smart people don't realise how easy it is to cross-reference given a unique username.
I think email plus a robust protocol for resolving changes works as good as can get.
For important stuff like banks and pensions they also have phone and physical address, so there’s a way to reconcile things like email changes, as rare as they are.
Government has failed to adapt with modern times and technology and has failed to provide modern and secure identification and authentication services for citizens.
I log in with my bank credentials to access my government tax account, talk about a total failure to do your job from the people still using SIN as an important piece of identity for some of the most important aspects of life.
This is a solvable problem. Governments can adapt and use modern technology to provide identity and authentication services, but they do not.
In my opinion this is a failure to be responsible for core government services, and I can only speculate why.
Pretty much everything is moving to UUID of sorts including Google auth.
It's tricky because you often need to let people reference username/emails for mentions and etc, so you just have to index all of em and translate to UUIDs for references behind the scenes.
It gets extra tricky with APIs. Consider AirPlane.dev which let's you specificy approvers via email. Now a user changes their name and their email. Well, that "IaC" suddenly references an invalid email or worse a different user because jane.doe joined after jane.doe-brown got their new email.
Also, it is good to keep concepts of account ID, public username, and login username separate. By using random account ID, can change the other values. Most accounts want email but don’t have to make it user name. Or people have multiple accounts and makes sense to have email reused.
For login, it can help to have multiple methods. Then people can change from OIDC to password, or between providers.
It’s useful to have your own domain with your own email so it stays with you as long as you like, beyond work emails.
Being a tolerated guest who pays little to none in someone’s servers is another issue.
Most large email providers are more like digital identity providers, and being a citizen of one of these big digital countries is neither democratic or setup for your long term preferences.
Have you heard of key event receipt infrastructure (KERI)?
It solves the identity problem with decentralized identifiers though the secret sauce is the fractionally weighted multisig for enabling multi-device signing and account recovery with key rotation.
Spotify let's you add separate login methods. I have my email+pw set up as well as login with Apple and login with Facebook. They all log into the same account and all have the same permissions once logged in.
FaceID and touchID for iOS works pretty seamlessly nowadays for authenticating stuff e.g. mobile payments/banking, etc. and are pretty robust from being spoofed/hacked (uses depth sensor?). Why can’t we create some privacy agnostic universal FaceID to do away with passwords and usernames?
> they want to be able to choose non-unique ones rather than end up with user53267 or something inane.
Disagreed. I'm 39. I've known hundreds of people (HS, college, etc) and many close friends who willingly made email accounts like "brijacks85" (their birth year) or "sammichelson212" even when their actual names were still fully available on yahoo/gmail/hotmail, etc. I used to regularly create email accounts for these people using just their names and then ask "why didn't you just check your own name first?" and they'd usually just shrug with total indifference and never use the account I made for them.
What if every newborn received a chip implant under the skin (cryptographically unbreakable, unauthorized removal punishable by law), linked to a central government database with the chip’s unique identifier and a profile of the newborn’s DNA signature?
What is the best approach to dealing with this problem as an individual?
Gmail? You might randomly get locked by some AI algorithm (or you might get banned!), or something else goes wrong, and there's no recourse.
Yahoo? I recently lost access to mine because they decided to start demanding verification with a deactivated email I haven't had access to for 15 years in order to login. Luckily, I had access in an email client, so I was able to migrate all the important accounts off of it.
Yahoo/AOL/Tutanota/Protonmail/Many others? These ones will auto-delete your account if you don't login frequently enough (not protonmail yet, but they allow it in their TOS)
Self-host? All self-hosting infrastructure requires an email in the first place. Lose access to that email, lose access to payment reminders, potentially your hosting account. I nearly lost my domain since the payment reminders went to an email that I rarely check because it doesn't support IMAP. And there is a greater increase of hacking unless you're a professional sysadmin and have plenty of time for maintenance.
Duo push? Your phone breaks.
SMS verification? Phone breaks, lose access to your plan, compromised employee gives your codes away, etc.
I've settled on using my university gmail address since (1) they promise alumni can keep it and (2) if something goes wrong with it (likely losing 2-factor by losing my phone), there is a good alumni support center. There really needs to be a human I can talk to somewhere. Still not sure if this is the best approach; am I still at risk from Google here?
You are missing the best solution which is your own domain and hosted email like Gmail. If you get locked out like you said, “just” change providers and you lose at most a couple of hours of emails.
What about iCloud? I guess in theory they can ban your account, but at least with apple I feel like you generally have some recourse and can talk to a human.
Agreed that emails aren't a good permanent identifier. Though using phone numbers as any part of identification is even worse. I've had the same email for almost two decades (through my own domain name), but I've gone through nearly a dozen phone numbers in the same time period, and regularly find that a website has opted me in to 2fa with an old number, or I've forgotten they had an old phone number to begin with.
I am currently paying a ~$150 per month "tax" to AT&T to keep my US number while living abroad just so I can get login codes for websites that still have that number, and out of fear that if I dump it I'll lose access to some occasionally vital service that I've forgotten to update, or I can't because you need to have a US number.
This is my experience as well. A random UUID is best IMO. Even a hash of the user's initial email isn't ideal since salting may not be enough, and others may assume they can safely hash any incoming email.
What if: We had support for public key e-mail addresses, something like <[email protected]>. But also <[email protected]>. With online services treating them both as equivalent, so I could login or do account recovery with one after signing up with the other. Google bans me or hotmail goes out of business, and I can go to the other service and authenticate with my private key to open the same account there.
Obviously, we'd want some sort of aliasing process so we can have a convenient name, but we probably want mail clients to map those addresses or at least track them with their public key.
Could even end up being a shoehorn for E2E encrypted e-mail, which never really seems to have caught on in any big way.
This would require some big players to support it to get anywhere, but from a brief thinking about it, it seems solid. Other than that nobody has support for it yet...
One of my previous energy providers (British Gas, owned by Centrica) didn’t allow an email address to be used for more than one physical address.
When I moved and tried to “set up” my online account I kept getting HTTP 500s when trying to view details about my current address. On the phone they told me “sorry, you can’t use the same email address for multiple [postal] addresses”, even with closed energy accounts from previous addresses.
We're actually in the process of changing around our email system to allow for multiple associated email addresses with an account right now.
One of the main reasons for this is that we provide a student discount for people, and the easiest way to apply that to an account is by checking if their email is an educational one (.edu, .ac.uk, etc). However most people don't seem to want to actually signup with that email. So by allowing multiple emails we can have the best of both worlds! Wish we had done it this way in the beginning.
Be aware that at least in the US, many people who graduated from university can get an .edu alumni forwarding address. I have a rather cool one. I got in early on and it’s just my first name. I don’t use it much though. In the early days the forwarding made it sometimes unreliable although I assume it’s better now. And the reality is my gmail address has been stable over a couple decades at this point and I don’t see that changing.
I give out my edu address to very few people in any case.
There is a client-side solution, even if not the most elegant.
I'm paying a domain, this way i have 100% control of my e-mail alias, even if my current provider (google) goes south, i'm still able to host the mail on my own server to retrieve accounts, and maintain ownership or the alias
I think this is a backend issue in that for the user, their id is email, but within the systems’s data the primary key shouldn’t be email.
Is anyone still doing this? It’s like the most basic db design issue to not use things like email as the identifier and instead have a lookup table that maps things to a truly unique id (uuid or maybe auto increment from a sequence).
The article doesn’t really make this distinction so it almost reads like how users should be aware of this abstraction.
Nothing is permanent. Hardly anything is stable even throughout the entire human lifespan. No bio markers that can be easily scanned are reliably unique across a large enough population.
Email addresses are reliably unique (for a reasonably long time), which is why they are chosen for this purpose.
Phone numbers are now more "sticky" than they used to be and are now similar to email addresses at being useful identifiers.
Both emails and phone numbers are frequently lost, often at the same time.
Backup email addresses are the way to go.
Github does a good job at identity, I think, but they still use passwords (which are bad).
There's two separate but related issues that the article and comments here are merging together: identification & authentication
The problem of identification, which is assigning a unique identity to each human being, has pretty much been solved. You have names, emails, id cards, really any unique string or number that's tied to a human being. It's not flawless, but in theory it works.
The real issue is authenticating an identity, how do you know the person is actually who they claim to be? This is one of the biggest issues facing modern technology, and it has not been solved. We generally use a combination of passwords, geolocation, IP addresses, emails, phone numbers, security tokens and certificates to create systems that are "good enough". However, these systems are regularly breached, and tightening their security generally has a negative effect on legitimate users.
The only good identifier is a private one. Email, usernames, etc. They should all be changeable. You don't know what laws come unto function, which events occur, does a person change gender and now need a new social security number, did a person use a business email account for all their private stuff. Usernames change as we fancy, and the whole uniqueness around usernames are a little bit silly as well.
A private id is probably just the best, whether it is a UUID, or another type of sufficiently collision resistant id, kept away from the user for the most part.
Let said person have an email or username, and let other people tag or friend them, but only use said username/email when doing the initial connection. Base said connections off of, the private id
Email addresses suck. All these "identities" that we use are owned by other people and are rented or "given" to us for use. Every single one! Email address, phone number, all social media handles, even IP address, even government identifiers. None of them are owned by you.
As far as I can tell, the only way to have an actually good identifier is for a user to generate a public/private keypair.
Yes, there are challenges with account recovery but we have tools for that like multisig and and n of m schemes and a bunch of other stuff I don't know about.
Email is digital post cards handed off between two dozen untrusted couriers. Why on earth are we overloading this tool for identity, notifications, conversations, subscriptions, etc?
For a long time Amazon’s unique ID for accounts was email + password. So people that forgot their password would end up with two separate accounts using the same login name and which one they got depended on the password.
I think there are _two_ primary issues with email addresses being used as a core part of account definitions. The one emphasized here is that email addresses change, but the other is that the user is giving every service provider they have an account with a _shareable/leakable_ form of contact info, which cannot effectively be revoked.
I wish we would move to a Permissioned Messaging Provider model, where a standardized API allows a user to issue tokens to specific parties to send messages, which is revocable, and where the user can control the destination and medium of those messages. You want your airline to be able to send you status updates about your flight? Great -- you can choose whether those messages arrive as emails, text messages, whatsapp messages, etc, and you can remove those permissions later if you like. Permissioned Messaging Providers will also change sometimes. I think a keybase-like mechanism could be used for asserting that you're the same person across two services, but knowledge that @user1@providerA is the same as @user2@providerB wouldn't allow anyone to send messages to either, since you still need a token (unlike announcing publicly that you're moving from [email protected] to [email protected]).
Some of our customers (school districts) regularly recycle email addresses for students, reassigning an address to a new student after even just one year. That’s fine(ish?), but problematic when they don’t also provide a stable unique identifier that can signal the change. Identity management is a remarkably messy and hard problem — one of those areas where the “corner cases” add up to an order of magnitude more work than the core solution.
Some sites (e.g. Amqzon) allow login with phone number and password. While a phone number isn't a good permanent identier either, I occasionally wonder: does this option exist because there are significant populations of net-using people who commonly have no email address? If there are, are there particular geographic or demographic groups where this is common? E.g. developing nations, millennials.
Anyone who has tried to de-Google their online presence runs into this. Many sites don't let you change your email address so you either create a new account or live with mail forwarding. OAuth is often worse at this, I have too many third party sites using Log in with Google, forces me to keep a Google session open (in a Firefox container).
[+] [-] buro9|2 years ago|reply
Emails change, people lose access to old emails.
People dislike usernames, they want to be able to choose non-unique ones rather than end up with user53267 or something inane.
People lose devices, just storing a secret UUID in their cookie, or using a passkey from their device isn't going to work.
There is no ideal solution except to blend a variety of things together, for some people email is pretty stable for long time and they like it as the identity, for others their usernames are stable and they prefer that as the identity... though I know of no-one that has had the same primary device for more than years (not decades) so perhaps that one will never work.
I do think this is important though, where it comes up a lot is a work email account, a [email protected], and how all of the vendor software utilises "Sign in with Google", and it's the email address they then store in the vendor app as the identifier...
People get married, people get divorced, people transition, people move culture and choose new names... names change, and so do email addresses.
Perhaps OIDC and the like needs a new extension: a standard API to change a username, and a standard API to change an email address.
[+] [-] poulpy123|2 years ago|reply
[+] [-] seydor|2 years ago|reply
[+] [-] brewmarche|2 years ago|reply
Of course this means that an ID token should not contain an e-mail address under `sub`.
[+] [-] hibikir|2 years ago|reply
This is extra fun when the company in question does a lot of their business offering complicated accounts to customers, and has an external facing identity solution that deals with all of this easily: just not for their own workers, including those maintaining the external-facing identity system.
[+] [-] oooyay|2 years ago|reply
[+] [-] laserbeam|2 years ago|reply
1. Use a guid-like value as your internal identifier. All internal references in your databases to a user should use that.
2. Use a second user friendly identifier for the user to login (i.e. Email). Feel free to rebind this if the user needs to change it. Keep a 1-to-1 relationship between the two.
[+] [-] renonce|2 years ago|reply
[+] [-] mark-r|2 years ago|reply
[+] [-] dcow|2 years ago|reply
The real problem, though, is that we seem to need digital identity solutions to be perfect as opposed to “good enough”. No solution is perfect and we’ll be stuck on email as long as the enterprise security nuts (who need everything device-bound and vendor attested) and anon-in-the-ether privacy schoolers (who think any stable identifier whatsoever is a heinous crime) are part of the conversation.
Imagine if everyone just used mobile drivers licenses issued to whatever self-sovereign wallet the user chooses. Identity issuing, revocation, and recovery is then handled by all the things society has already built to handle meatspace identity. Account recovery involves a trip to your local gov’t office to re-issue your ID credential. Which means you need some chain of trust to your birth certificate. You’re going to treat your mDL credential wallet with a lot more reverence if that’s the recovery flow, so some of these problems solve themselves if we stop using punk short-names everywhere online.
Relying parties that need human uniqueness, age, and/or nationality guarantees use the mDL verifiable credential. Law probibits relying parties from aggregating and selling/transferring information obtained for purposes of authentication from a VC. Ad-tech privacy problem solved.
Services that don’t need proof of human uniqueness etc. can just skip the VC part of the equation and use basic passkeys and implement short-name reclamation.
[+] [-] api|2 years ago|reply
Ideally in a perfect world we'd have governments run OIDC systems similar to the US login.gov and these would delegate from an international master OIDC system at the UN. Everyone would have their citizenship passport ID and their UN ID, and the latter could serve as a "break glass" master key to support immigration and also limit the ability of countries to "digital death penalty" people.
I can think of some dystopian outcomes here, but IMHO they are not worse than the dystopian outcomes that come from corporate monopolist control of digital identity. At least in democracies one has some nominal influence over one's government and the latter is bound by the rule of law, and if you don't live in a democracy you can (or should be able to) leave.
You're right that identity is hard, and I think most of why it's hard is human rather than technical. One could create a decentralized identity layer from a block chain fairly easily but people would lose their keys etc.
[+] [-] WhyIsItAlwaysHN|2 years ago|reply
Example: https://instantusername.com
I've seen quite personal details being leaked because sometimes even smart people don't realise how easy it is to cross-reference given a unique username.
[+] [-] zirgs|2 years ago|reply
Google doesn't reuse usernames so if they are still around - in a few decades pretty much all unique usernames will belong to dead people.
[+] [-] prepend|2 years ago|reply
For important stuff like banks and pensions they also have phone and physical address, so there’s a way to reconcile things like email changes, as rare as they are.
[+] [-] newsclues|2 years ago|reply
Government has failed to adapt with modern times and technology and has failed to provide modern and secure identification and authentication services for citizens.
I log in with my bank credentials to access my government tax account, talk about a total failure to do your job from the people still using SIN as an important piece of identity for some of the most important aspects of life.
This is a solvable problem. Governments can adapt and use modern technology to provide identity and authentication services, but they do not.
In my opinion this is a failure to be responsible for core government services, and I can only speculate why.
[+] [-] Rapzid|2 years ago|reply
It's tricky because you often need to let people reference username/emails for mentions and etc, so you just have to index all of em and translate to UUIDs for references behind the scenes.
It gets extra tricky with APIs. Consider AirPlane.dev which let's you specificy approvers via email. Now a user changes their name and their email. Well, that "IaC" suddenly references an invalid email or worse a different user because jane.doe joined after jane.doe-brown got their new email.
[+] [-] ianburrell|2 years ago|reply
For login, it can help to have multiple methods. Then people can change from OIDC to password, or between providers.
[+] [-] j45|2 years ago|reply
Being a tolerated guest who pays little to none in someone’s servers is another issue.
Most large email providers are more like digital identity providers, and being a citizen of one of these big digital countries is neither democratic or setup for your long term preferences.
[+] [-] kentbull|2 years ago|reply
It solves the identity problem with decentralized identifiers though the secret sauce is the fractionally weighted multisig for enabling multi-device signing and account recovery with key rotation.
See the specification for more details: https://www.ietf.org/id/draft-ssmith-keri-00.html
Or the whitepaper: https://github.com/SmithSamuelM/Papers/blob/master/whitepape...
[+] [-] pests|2 years ago|reply
I think it's a good solution.
[+] [-] flir|2 years ago|reply
This is why I think email addresses are "good enough" - you can always spin up a new one for each identity you want to inhabit.
[+] [-] sizzle|2 years ago|reply
[+] [-] unknown|2 years ago|reply
[deleted]
[+] [-] emilfihlman|2 years ago|reply
There absolutely is a good identity, and it's one provided by countries.
[+] [-] esafak|2 years ago|reply
Exactly the analogy I had in mind. email primary keys are "serial monogamy". Or if you want a mathematical analogy, piecewise constant :)
[+] [-] Solvency|2 years ago|reply
Disagreed. I'm 39. I've known hundreds of people (HS, college, etc) and many close friends who willingly made email accounts like "brijacks85" (their birth year) or "sammichelson212" even when their actual names were still fully available on yahoo/gmail/hotmail, etc. I used to regularly create email accounts for these people using just their names and then ask "why didn't you just check your own name first?" and they'd usually just shrug with total indifference and never use the account I made for them.
[+] [-] MasterYoda900|2 years ago|reply
[+] [-] user234683|2 years ago|reply
Gmail? You might randomly get locked by some AI algorithm (or you might get banned!), or something else goes wrong, and there's no recourse.
Yahoo? I recently lost access to mine because they decided to start demanding verification with a deactivated email I haven't had access to for 15 years in order to login. Luckily, I had access in an email client, so I was able to migrate all the important accounts off of it.
Yahoo/AOL/Tutanota/Protonmail/Many others? These ones will auto-delete your account if you don't login frequently enough (not protonmail yet, but they allow it in their TOS)
Self-host? All self-hosting infrastructure requires an email in the first place. Lose access to that email, lose access to payment reminders, potentially your hosting account. I nearly lost my domain since the payment reminders went to an email that I rarely check because it doesn't support IMAP. And there is a greater increase of hacking unless you're a professional sysadmin and have plenty of time for maintenance.
Duo push? Your phone breaks.
SMS verification? Phone breaks, lose access to your plan, compromised employee gives your codes away, etc.
I've settled on using my university gmail address since (1) they promise alumni can keep it and (2) if something goes wrong with it (likely losing 2-factor by losing my phone), there is a good alumni support center. There really needs to be a human I can talk to somewhere. Still not sure if this is the best approach; am I still at risk from Google here?
[+] [-] Horffupolde|2 years ago|reply
[+] [-] bobbylarrybobby|2 years ago|reply
[+] [-] Mattasher|2 years ago|reply
I am currently paying a ~$150 per month "tax" to AT&T to keep my US number while living abroad just so I can get login codes for websites that still have that number, and out of fear that if I dump it I'll lose access to some occasionally vital service that I've forgotten to update, or I can't because you need to have a US number.
[+] [-] paulryanrogers|2 years ago|reply
[+] [-] linsomniac|2 years ago|reply
Obviously, we'd want some sort of aliasing process so we can have a convenient name, but we probably want mail clients to map those addresses or at least track them with their public key.
Could even end up being a shoehorn for E2E encrypted e-mail, which never really seems to have caught on in any big way.
This would require some big players to support it to get anywhere, but from a brief thinking about it, it seems solid. Other than that nobody has support for it yet...
[+] [-] sigwinch28|2 years ago|reply
When I moved and tried to “set up” my online account I kept getting HTTP 500s when trying to view details about my current address. On the phone they told me “sorry, you can’t use the same email address for multiple [postal] addresses”, even with closed energy accounts from previous addresses.
[+] [-] fastball|2 years ago|reply
One of the main reasons for this is that we provide a student discount for people, and the easiest way to apply that to an account is by checking if their email is an educational one (.edu, .ac.uk, etc). However most people don't seem to want to actually signup with that email. So by allowing multiple emails we can have the best of both worlds! Wish we had done it this way in the beginning.
[+] [-] ghaff|2 years ago|reply
I give out my edu address to very few people in any case.
[+] [-] carafizi|2 years ago|reply
I'm paying a domain, this way i have 100% control of my e-mail alias, even if my current provider (google) goes south, i'm still able to host the mail on my own server to retrieve accounts, and maintain ownership or the alias
[+] [-] prepend|2 years ago|reply
Is anyone still doing this? It’s like the most basic db design issue to not use things like email as the identifier and instead have a lookup table that maps things to a truly unique id (uuid or maybe auto increment from a sequence).
The article doesn’t really make this distinction so it almost reads like how users should be aware of this abstraction.
[+] [-] liveoneggs|2 years ago|reply
Email addresses are reliably unique (for a reasonably long time), which is why they are chosen for this purpose.
Phone numbers are now more "sticky" than they used to be and are now similar to email addresses at being useful identifiers.
Both emails and phone numbers are frequently lost, often at the same time.
Backup email addresses are the way to go.
Github does a good job at identity, I think, but they still use passwords (which are bad).
[+] [-] r3trohack3r|2 years ago|reply
There is only social attestation.
Any identity system that fails to recognize this will fail to model societal constructs.
http://www.blankenship.io/essays/2023-09-24/
[+] [-] calibas|2 years ago|reply
The problem of identification, which is assigning a unique identity to each human being, has pretty much been solved. You have names, emails, id cards, really any unique string or number that's tied to a human being. It's not flawless, but in theory it works.
The real issue is authenticating an identity, how do you know the person is actually who they claim to be? This is one of the biggest issues facing modern technology, and it has not been solved. We generally use a combination of passwords, geolocation, IP addresses, emails, phone numbers, security tokens and certificates to create systems that are "good enough". However, these systems are regularly breached, and tightening their security generally has a negative effect on legitimate users.
[+] [-] kjuulh|2 years ago|reply
A private id is probably just the best, whether it is a UUID, or another type of sufficiently collision resistant id, kept away from the user for the most part.
Let said person have an email or username, and let other people tag or friend them, but only use said username/email when doing the initial connection. Base said connections off of, the private id
[+] [-] noman-land|2 years ago|reply
As far as I can tell, the only way to have an actually good identifier is for a user to generate a public/private keypair.
Yes, there are challenges with account recovery but we have tools for that like multisig and and n of m schemes and a bunch of other stuff I don't know about.
Email is digital post cards handed off between two dozen untrusted couriers. Why on earth are we overloading this tool for identity, notifications, conversations, subscriptions, etc?
[+] [-] User23|2 years ago|reply
[+] [-] dastbe|2 years ago|reply
[+] [-] abeppu|2 years ago|reply
I wish we would move to a Permissioned Messaging Provider model, where a standardized API allows a user to issue tokens to specific parties to send messages, which is revocable, and where the user can control the destination and medium of those messages. You want your airline to be able to send you status updates about your flight? Great -- you can choose whether those messages arrive as emails, text messages, whatsapp messages, etc, and you can remove those permissions later if you like. Permissioned Messaging Providers will also change sometimes. I think a keybase-like mechanism could be used for asserting that you're the same person across two services, but knowledge that @user1@providerA is the same as @user2@providerB wouldn't allow anyone to send messages to either, since you still need a token (unlike announcing publicly that you're moving from [email protected] to [email protected]).
[+] [-] aaronharnly|2 years ago|reply
[+] [-] remram|2 years ago|reply
* Person used their real name, got married, changed last name
* Person used their real name, transitioned, changed their first name
* Person used characters that you no longer want to accept in nicknames
* Person used a nickname that you now want to reserve (e.g. "admin", "contact", "help", ...)
* Person used a very silly name and grew up or started using your service at their job
[+] [-] andyjohnson0|2 years ago|reply
[+] [-] 8organicbits|2 years ago|reply