Cool, so if I want to use myname+yourdomainname.here@myemail.com to register on your application I now first have to go to some third party(?*) to verify that myname+yourdomainname.here@myemail.com is valid**. And then, once I've gone through the hassle of that, I have to go back to your website to use the third party service to verify my email. Thanks I guess...
* It's not clear if this service would be provided by a third party (in which case, the problem has merely just been moved) or the email provider. It sounds like the former, but in case it's the latter, then this doesn't have as big an impact I guess.
** While _I_ as the owner of an email address can decisively know that all emails of the form `myname+<whatever>@myemail.com` will go to me, you as the owner of a website attempting to verify my email cannot know that. The standards specify that + is valid in an email user part, but they do not require plus addressing to work.
* It's lowering the friction to the site identifying the user (separate from the identification done now by the more sophisticated third-party tracking by surveillance companies like Google and Meta), even for sites that previously couldn't justify the friction of trying to do that.
* It's putting surveillance companies even more in the loop, building on the recent "log in with [surveillance company]" buttons, while existing login methods are destroyed through dark pattern practices or simply removed.
* It can be a ready-made platform, waiting for the next authoritarian government directives that say, now that everyone is hooked up or can easily be hooked up, turn on oppressive feature X, Y, or Z for all targeted Web sites/people.
I don't know if this is the solution, but we desperately need one. It's to the point where "email bombing" is forcing service providers to add captchas to login and registration because those forms are being abused as mail-flooders.
"There are privacy implications as the email transmission informs the mail service the applications the user is using and when they used them."
Not really, as I can enter any email on a service login page that uses magic links for auth. The owner of that email will receive the login link but that doesn't mean they tried to login on that system.
Not really indeed. You're right that false positive are possible with such a system, but false negatives are not. That means that you're leaking information about when a user didn't use a service, as well as partial information about when the did (which you could combine with other data to tell you something meaningful).
Skimming that I'm thinking yes, sure, why not, but this repo is missing useful context. Who are you, authors? Why should I bother learning this protocol? Is anyone using or going to use this? If it's new, has it been shopped around at conferences? Any related research?
Many applications need a way to contact a user (security breach, password reset). If one only has a username and forgets the password, there’s no way to reverify the user.
> Many applications need a way to contact a user … password reset
At this point the password is pointless, you might as well just use the email address. Or perhaps a distinct username and email address, but then there would probably be a “forgot username” workflow making that as pointless as the separate password.
There are many ways to re-verify the user if one forgets a password. Some may even be more secure than sending a e-mail. Simplest is a set of single-use reset codes that could be generated at signup or later on, like the ones to remove 2FA.
In the case of security procedures, I'd argue that there is some room for tough beans. Reducing security to cater for carelessness seems like a really bad compromise to me, one that I see far too often.
Most people want a way to recover their account if they lose those creds, especially when you ask them once they’ve lost their creds.
It’s also a rudimentary PoW system against bots. And people who don’t want to share their email can use a temp email service, so it’s no skin off their back.
Ultimately this is akin to password requirements. They are a bother but the average user is just much too careless to be trusted with their own security.
* prevent signing up for someone else (validate it is you who owns the email)
* poor man's mfa, although please allow me to use totp instead (probably the three most legitimate reasons from a user perspective, email validation prevent you from making a typo)
* send ads and notifications (legitimate from the provider's perspective, they want campaigns to succeed, email validation makes them sure emails land)
Weird that no one said this yet: To verify users' legitimacy. If you make effort to block 10 minute email services it works kinda well and slows down bots
Without traceability, any app that can be used for abuse will be. (An HN reader used an anonymous mail service to send me some hate speech and tell me to kill myself within the last day. The service they used to do it obviously does not care, but also cannot do anything about it, because they don't know who used their service to do it.)
The onus is on you here… but, I think I know where you’re going with this. In terms of number of email addresses people have and use, vs number of usernames people have and use, you might be right that some people have 1 or 2 email addresses and many usernames.
Email masking has become easier to use, and many people use `+addressing` to uniquely tie their email to the service for spam prevention / tracking, which would make stuffing harder.
In these cases, email would be much more unique and a better protection against stuffing. HOWEVER, it’s not obvious how Email verification protocol would work for these types of things.
Credential stuffing happens when a user signs up on one Website B with account information matching the information they used when setting up their account on Website A, and the operator of either Website A or Website B can use those credentials to access the user's account with the other operator.
If websites authenticate with username and password combo chosen by the user, then credential stuffing is neutralized if the user avoids re-using the same combo, effected by the user selecting at least one of a different password or the selection of a different username.
If instead of a username, an email address is required to register, that generally results in one less degree of freedom; rather than being able to create a username with Website B that differs from the username they created on Website A, absent the use of a wildcard/catch-all mailbox or forwarding service (which are not straightforward to set up, and almost nobody has one), the user is required to disclose an existing email address.
(It also increases the surface area for attacks, since the malicious website, now knowing the user's email address, can attempt credential stuffing with the user's email provider itself.)
You can balk at whether or not these are negligible differences, but it's non-zero. Therefore, all other things held equal, then strictly speaking it is more robust.
>If instead of a username, an email address to register, that generally results in one less degree of freedom [...]
It "generally" doesn't, because the average user isn't randomly generating usernames per-site, just like they're not randomly generating passwords per-site. If they're randomly generating usernames per site, they'll need some sort of system to keep track of it, which is 90% of the way to using a password manager (and therefore randomized passwords, immune to credential stuffing). For it to practically make a difference, you'd need someone who cares about security enough to randomize usernames, but for whatever reason doesn't care enough about security to randomize passwords.
To start with, randomly generated usernames weren't mentioned, and they are not a prerequisite.
> It "generally" doesn't, because the average user isn't randomly generating usernames per-site
What other people do, whether average users or not, doesn't matter. When average user Alice is registering accounts on Websites A and B, the fact that average user Bob doesn't use different usernames for his accounts doesn't change the fact that if Alice would have otherwise registered account agirl on one site and pie_maker26 on the other, but instead has been forced to enter her email address, then that has a non-zero effect on risk.
For the claim as stated to be untrue, the difference in risk would need to be zero.* But it isn't zero. The claim as stated is true.
> For it to practically make a difference, you'd need someone who cares about […]
That's not true. Users who are exposed to lower risk by accident are still exposed to lower risk. It's not a prerequisite for the user to care at all, nor does it require them to understand any of this or to be trying to adhere to any particular scheme to achieve a certain outcome. The only thing that matters is what they're doing—and whether what they're doing increases or decreases risk. Intent doesn't matter.
* or it would need to be somehow less risky when email addresses are required in place of where a username otherwise would be, but that's not the case, either
>To start with, randomly generated usernames weren't mentioned, and they are not a prerequisite.
I've seen sites randomly generate passwords for users as well. Does that mean users reusing their passwords at all is a prerequisite? Moreover if we're really accepting "whether average users or not, doesn't matter", I can also say that using emails doesn't decrease security because you can use randomized emails, as others have mentioned. At some point you have to constrain yourself to realistic threat models, otherwise the conversation gets mired in lawyering over increasingly implausible scenarios. For instance, by asking for emails at registration, you can more easily perform 2fa, whereas you can't do that with only a username/password combination[1].
[1] before you jump to say "but can ask for an email with username/password too!", keep in mind the original claim that username/password is better was in response to a comment asking "Why must apps require email?".
On the rare occasions where I would care about this as a user, I make a throwaway account on an anonymous service. If I don't want my email service to know I have an account with you then I don't trust you to handle my main address either.
Hard to see how this provides substantial benefits over OIDC. Either one requires support from the email provider, but one is already standardized and has widespread support.
This isn’t fundamental to its design, though. It’s a result of providers wanting to gate access to identities for various reasons. The protocol presented here does nothing to address this gating.
This is sorta interesting, but it fails on several levels. First, email verification as it exists currently is fairly simple, there are a lot of different ways to do it, and it works universally for all email addresses (as long as you don't expire codes too fast for servers that use greylisting).
This protocol solves a pretty contrived problem ("By sending the email verification code, the inbox provider knows the user is using that service!") by making email verification exponentially more complex, with only one correct flow, and will only work for domains that have opted in and configured this protocol.
Importantly, the protocol seems to rely on 1st party web cookies, which means you could no longer run a "pure" MTA that offers IMAP; you would need to have some web interface where your users can log in, even if there is no webmail functionality.
The bigger question is: why would the company who is hosting the email have any economic incentive to invest time and money in implementing and maintaining this protocol which currently has zero adoption? It's a chicken-and-egg with no upside.
If my memory serves, this is the same wolf in sheep’s clothing that the attestation based Web Environment API was, from the same kinds of very interested parties. (Edit: I may be misremembering the name of that proposed API.)
It’s not about efficient, effective solutions. It’s about control. Something you have to look at with WICG and W3C is the source of proposals and drafts.
Ha! Thank you, I misunderstood who was behind this proposal but since it's W3C it's something that would directly be implemented by the browser itself.
Cool, so if I want to use myname+yourdomainname.here@myemail.com to register on your application I now first have to go to some third party(?*) to verify that myname+yourdomainname.here@myemail.com is valid**. And then, once I've gone through the hassle of that, I have to go back to your website to use the third party service to verify my email. Thanks I guess...
* It's not clear if this service would be provided by a third party (in which case, the problem has merely just been moved) or the email provider. It sounds like the former, but in case it's the latter, then this doesn't have as big an impact I guess.
** While _I_ as the owner of an email address can decisively know that all emails of the form `myname+<whatever>@myemail.com` will go to me, you as the owner of a website attempting to verify my email cannot know that. The standards specify that + is valid in an email user part, but they do not require plus addressing to work.
* It's lowering the friction to the site identifying the user (separate from the identification done now by the more sophisticated third-party tracking by surveillance companies like Google and Meta), even for sites that previously couldn't justify the friction of trying to do that.
* It's putting surveillance companies even more in the loop, building on the recent "log in with [surveillance company]" buttons, while existing login methods are destroyed through dark pattern practices or simply removed.
* It can be a ready-made platform, waiting for the next authoritarian government directives that say, now that everyone is hooked up or can easily be hooked up, turn on oppressive feature X, Y, or Z for all targeted Web sites/people.
I don't know if this is the solution, but we desperately need one. It's to the point where "email bombing" is forcing service providers to add captchas to login and registration because those forms are being abused as mail-flooders.
They could consider not using email at all
This is what Mozilla Persona did, too. I loved the UX, but it wasn't very successful, unfortunately.
Apparently Persona was even based on some prior work called "VerifiedEmailProtocol", eerily similar to the OP
"There are privacy implications as the email transmission informs the mail service the applications the user is using and when they used them."
Not really, as I can enter any email on a service login page that uses magic links for auth. The owner of that email will receive the login link but that doesn't mean they tried to login on that system.
Not really indeed. You're right that false positive are possible with such a system, but false negatives are not. That means that you're leaking information about when a user didn't use a service, as well as partial information about when the did (which you could combine with other data to tell you something meaningful).
Skimming that I'm thinking yes, sure, why not, but this repo is missing useful context. Who are you, authors? Why should I bother learning this protocol? Is anyone using or going to use this? If it's new, has it been shopped around at conferences? Any related research?
author:
https://www.w3.org/community/wicg/
https://wicg.io/
Might want to take a look at https://github.com/zkemail
Why must apps require email? Why not only username and password?
Many applications need a way to contact a user (security breach, password reset). If one only has a username and forgets the password, there’s no way to reverify the user.
You don't need to validate email for that.
I think if you're not verifying emails, you'll also receive lots of bot signups.
> Many applications need a way to contact a user … password reset
At this point the password is pointless, you might as well just use the email address. Or perhaps a distinct username and email address, but then there would probably be a “forgot username” workflow making that as pointless as the separate password.
There are many ways to re-verify the user if one forgets a password. Some may even be more secure than sending a e-mail. Simplest is a set of single-use reset codes that could be generated at signup or later on, like the ones to remove 2FA.
> If one only has a username and forgets the password, there’s no way to reverify the user.
Tough beans?
A good user experience does its best to avoid tough beans. That's kind of UX 101.
In the case of security procedures, I'd argue that there is some room for tough beans. Reducing security to cater for carelessness seems like a really bad compromise to me, one that I see far too often.
Because it's less expensive to send a few e-mails than to provide customer support to everyone who forgets their password.
Most people want a way to recover their account if they lose those creds, especially when you ask them once they’ve lost their creds.
It’s also a rudimentary PoW system against bots. And people who don’t want to share their email can use a temp email service, so it’s no skin off their back.
So make it optional. I've seen sites like that.
Bots have no trouble signing up with @mybotfarm.example addresses.
Ultimately this is akin to password requirements. They are a bother but the average user is just much too careless to be trusted with their own security.
* recover password
* prevent signing up for someone else (validate it is you who owns the email)
* poor man's mfa, although please allow me to use totp instead (probably the three most legitimate reasons from a user perspective, email validation prevent you from making a typo)
* send ads and notifications (legitimate from the provider's perspective, they want campaigns to succeed, email validation makes them sure emails land)
* reduce throw-away or bot accounts
Weird that no one said this yet: To verify users' legitimacy. If you make effort to block 10 minute email services it works kinda well and slows down bots
Without traceability, any app that can be used for abuse will be. (An HN reader used an anonymous mail service to send me some hate speech and tell me to kill myself within the last day. The service they used to do it obviously does not care, but also cannot do anything about it, because they don't know who used their service to do it.)
I agree. username and password is much more robust to credential stuffing attacks.
> username and password is much more robust to credential stuffing attacks.
/s?
tell me how it's not.
The onus is on you here… but, I think I know where you’re going with this. In terms of number of email addresses people have and use, vs number of usernames people have and use, you might be right that some people have 1 or 2 email addresses and many usernames.
Email masking has become easier to use, and many people use `+addressing` to uniquely tie their email to the service for spam prevention / tracking, which would make stuffing harder.
In these cases, email would be much more unique and a better protection against stuffing. HOWEVER, it’s not obvious how Email verification protocol would work for these types of things.
You're the one who made the claim. So please explain how it is.
Credential stuffing happens when a user signs up on one Website B with account information matching the information they used when setting up their account on Website A, and the operator of either Website A or Website B can use those credentials to access the user's account with the other operator.
If websites authenticate with username and password combo chosen by the user, then credential stuffing is neutralized if the user avoids re-using the same combo, effected by the user selecting at least one of a different password or the selection of a different username.
If instead of a username, an email address is required to register, that generally results in one less degree of freedom; rather than being able to create a username with Website B that differs from the username they created on Website A, absent the use of a wildcard/catch-all mailbox or forwarding service (which are not straightforward to set up, and almost nobody has one), the user is required to disclose an existing email address.
(It also increases the surface area for attacks, since the malicious website, now knowing the user's email address, can attempt credential stuffing with the user's email provider itself.)
You can balk at whether or not these are negligible differences, but it's non-zero. Therefore, all other things held equal, then strictly speaking it is more robust.
>If instead of a username, an email address to register, that generally results in one less degree of freedom [...]
It "generally" doesn't, because the average user isn't randomly generating usernames per-site, just like they're not randomly generating passwords per-site. If they're randomly generating usernames per site, they'll need some sort of system to keep track of it, which is 90% of the way to using a password manager (and therefore randomized passwords, immune to credential stuffing). For it to practically make a difference, you'd need someone who cares about security enough to randomize usernames, but for whatever reason doesn't care enough about security to randomize passwords.
To start with, randomly generated usernames weren't mentioned, and they are not a prerequisite.
> It "generally" doesn't, because the average user isn't randomly generating usernames per-site
What other people do, whether average users or not, doesn't matter. When average user Alice is registering accounts on Websites A and B, the fact that average user Bob doesn't use different usernames for his accounts doesn't change the fact that if Alice would have otherwise registered account agirl on one site and pie_maker26 on the other, but instead has been forced to enter her email address, then that has a non-zero effect on risk.
For the claim as stated to be untrue, the difference in risk would need to be zero.* But it isn't zero. The claim as stated is true.
> For it to practically make a difference, you'd need someone who cares about […]
That's not true. Users who are exposed to lower risk by accident are still exposed to lower risk. It's not a prerequisite for the user to care at all, nor does it require them to understand any of this or to be trying to adhere to any particular scheme to achieve a certain outcome. The only thing that matters is what they're doing—and whether what they're doing increases or decreases risk. Intent doesn't matter.
* or it would need to be somehow less risky when email addresses are required in place of where a username otherwise would be, but that's not the case, either
>To start with, randomly generated usernames weren't mentioned, and they are not a prerequisite.
I've seen sites randomly generate passwords for users as well. Does that mean users reusing their passwords at all is a prerequisite? Moreover if we're really accepting "whether average users or not, doesn't matter", I can also say that using emails doesn't decrease security because you can use randomized emails, as others have mentioned. At some point you have to constrain yourself to realistic threat models, otherwise the conversation gets mired in lawyering over increasingly implausible scenarios. For instance, by asking for emails at registration, you can more easily perform 2fa, whereas you can't do that with only a username/password combination[1].
[1] before you jump to say "but can ask for an email with username/password too!", keep in mind the original claim that username/password is better was in response to a comment asking "Why must apps require email?".
> I've seen sites randomly generate passwords for users as well. Does that mean users reusing their passwords at all is a prerequisite?
wat
> I can also say that using emails doesn't decrease security because you can[*] use randomized emails
That _doesn't_ _matter_. Viz:
> The only thing that matters is what they're doing—and whether what they're doing increases or decreases risk.
In theory, maybe to some extent yes - unique usernames could beat reused emails.
But let's be real - nobody actually does that.
Because emails of real people can be sold to advertisers.
On the rare occasions where I would care about this as a user, I make a throwaway account on an anonymous service. If I don't want my email service to know I have an account with you then I don't trust you to handle my main address either.
Hard to see how this provides substantial benefits over OIDC. Either one requires support from the email provider, but one is already standardized and has widespread support.
OIDC is usually limited to a small selection of providers.
This isn’t fundamental to its design, though. It’s a result of providers wanting to gate access to identities for various reasons. The protocol presented here does nothing to address this gating.
This is sorta interesting, but it fails on several levels. First, email verification as it exists currently is fairly simple, there are a lot of different ways to do it, and it works universally for all email addresses (as long as you don't expire codes too fast for servers that use greylisting).
This protocol solves a pretty contrived problem ("By sending the email verification code, the inbox provider knows the user is using that service!") by making email verification exponentially more complex, with only one correct flow, and will only work for domains that have opted in and configured this protocol.
Importantly, the protocol seems to rely on 1st party web cookies, which means you could no longer run a "pure" MTA that offers IMAP; you would need to have some web interface where your users can log in, even if there is no webmail functionality.
The bigger question is: why would the company who is hosting the email have any economic incentive to invest time and money in implementing and maintaining this protocol which currently has zero adoption? It's a chicken-and-egg with no upside.
If my memory serves, this is the same wolf in sheep’s clothing that the attestation based Web Environment API was, from the same kinds of very interested parties. (Edit: I may be misremembering the name of that proposed API.)
It’s not about efficient, effective solutions. It’s about control. Something you have to look at with WICG and W3C is the source of proposals and drafts.
> User privacy is enhanced as the issuer does not learn which web application is making the request as the request is mediated by the browser.
How can you avoid revealing the application through the `Origin` header?
The request is sent by the browser, not the webapp itself (ie. using xhr or fetch) so it doesn't have headers like "Origin" added.
Ha! Thank you, I misunderstood who was behind this proposal but since it's W3C it's something that would directly be implemented by the browser itself.
> User privacy is enhanced as the issuer does not learn which web application is making the request as the request is mediated by the browser.
This seems extremely marginal. The point of verifying an email address is to subsequently use it to send email.
Is it reinventing OIDC or what is the benefit of this?
No way in hell I’m gonna learn another of these nightmarish protocols unless this is somehow much much better.
why does it have to be email?
Verify email addresses automatically