This was originally thought up a couple (5-6) years ago along side fedcm and privacy sandbox, but before SD-jwt was full baked, so it wasn't as clean. The use of SD-jwt is much better for privacy.
A user may make a typo in the email, and that email might still be a valid email know to work (but for another, unrelated person). The user's email agent (such as GMail or Outlook) can mark the email unimportant and make it hard to notice, or even mark as spam. All these issues are much better to find out and iron out before the user sees themself unable to communicate, or successfully bound to an email they cannot access.
The whole point of email verification is to make certain that a channel of alternative communication exists for a case when the user would be unable to identify themself normally, for whatever reason. A working email alone is not always sufficient for successful credentials reset, but almost always it's much easier to when the user has it.
That won't verify. The issuer should check if the request has valid session cookies for the e-mail-address that should be verified. This also implies that it just won't work for any service that uses sessions with a short timeout.
This seems extremely marginal. The point of verifying an email address is to subsequently use it to send email.
PS: just take PKCE where the provider has no way of communicating whether it is supported, or required, at all.
The only relevant flow is authorisation code with PKCE now (plus client credentials if you do server-to-server), and I haven’t found an identity provider yet that wouldn’t support that. Yes, that protocol has way too many knobs providers can fiddle with. But it’s absolutely doable.
code_challenge_methods_supported
There's also a proposal to add stateless ephemeral clients.
So it might get some traction, and finally break the monopoly of "Login With Google" buttons.
Source address verification doesn't really mean anything (no-reply@example.co.uk) and destination verification is obvious and as far as I am aware pretty much no-one doesn't do it already.
"delivery peers symmetric" - what does that mean?
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.
I agree with a lot of what you are saying, but I think the main motivation is actually trying to reduce friction for the user to verify their email, which is good for the user, because it makes registration easier, and good for the company, because less users bounce at the email registration step.
But yeah, this is quite complicated, and there isn't a lot of motivation for email providers to implement it.
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.
But after some work the team scoped down, to focusing on email verification. I think that's what lead to this spec? https://groups.google.com/a/chromium.org/g/blink-dev/c/rwu9w...
No way in hell I’m gonna learn another of these nightmarish protocols unless this is somehow much much better.
LOL WUT??
This is also ideal in “war dialling” eMail servers to get accurate lists of what eMail accounts exist on said server. This has been the case since marketing first hit the Internet.
Do you really want all of your legitimate eMail addresses to end up on spam lists? Because this is how you get complete and unabridged lists of your domain’s valid eMail addresses onto spam lists.
It’s why my own eMail server is set up to quietly confirm and accept any and all eMail sent to the domain - regardless of username employed. Even invalid eMail accounts get confirmed and incoming eMails to them get accepted.
Anything not sent to a valid account then drops into a catch-all account for further processing. Occasionally I’ll get eMail where the username was misspelled - it happens - and I just forward it to the appropriate family member.
The rest get reported as spam. And I enjoy making every last report. Enjoy ending up on a blacklist.
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.
Tough beans?
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.
Bots have no trouble signing up with @mybotfarm.example addresses.
* 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
/s?
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.
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.
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.
> 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
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?".
What?
> 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.
But let's be real - nobody actually does that.