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.
"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.
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?
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.
* 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.
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.
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.
I am a little sad the original pretty interesting FedCM work got reduced to this. There was some neat work underway to allow using identity providers without the site even knowing the provider! https://github.com/w3c-fedid/FedCM/issues/677
This is sort of missing the point of email verification. It's to test that the email from this particular site is deliverable and visible to the user, not just that it's a legitimate address known to work by some third party.
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.
The ideas proposed in here aren't bad, but it does seem like you'll need to maintain two user flows as a site owner because:
1) Not all email providers will implement this, and
2) Users may not be signed into their email at the moment they signup
As a developer, I would find it easier to have one "verification code" flow for all users rather than fragmenting the process; it's much easier to document for your support staff. Again, not a bad proposal but perhaps not very useful in practice.
I thought Mozilla Persona aka BrowserID handled this email validation well with a fallback provider that used the same flow (and also implemented the OIDC work for obvious existing social providers like Gmail/Google Accounts). Though obviously not well enough because that fallback provider was seen as a large expense and shutdown without a replacement killing the Mozilla Persona effort.
But that does relate to I keep wanting an email claim for Passkeys. A user's browser/OS could verify an email address once and then associate it with a Passkey. Passkeys might be a good place for that (as Persona/BrowserID suggested). Obviously some browsers could lie about verifying the email address in the claim and there might still need to be more steps to it, but if you are already taking Passkeys it doesn't necessarily add an entirely different flow to accept a verified email claim from a Passkey (and/or decide you don't trust that Passkey's claim and trigger your regular verification code flow).
I haven't managed to formulate the exact issue yet, but if I squint, I swear there's a path to track and/or deanonymize someone visiting your site. If you have any kind of previous information about the user, such as Meta, or Google or etc, you could easily try and see if the user holds any number of emails you think they might hold. From there on out we're practically back to third party cookie tracking.
"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."
Every web application nowadays send you a welcome, onboarding, reminder after the verification. (No user privacy enhancement)
So we get a new process that solves nothing, but makes everything complicated. (And complicated helps the big and hurt the little in th long run)
Not verified but feels like a Google draft that closes the web.
I can't tell you how many times email verification context switches made me completely lose track of what I was doing.
There's literally no worse context switch than having to go into your inbox, wait for an email, then come back to the appropriate tab to complete registration or login.
There are probably dozens, maybe hundreds, of services I never finished registering for all on account of this problem.
I worked authc/authz and security for a large fintech and we constantly butted heads against the growth folks. They fought hard and eventually won the right to do account creation and IDV without email verification. You don't have to verify your email until you're already making transactions, and that does wonders for growth. We're still accountable for all the stringent KYC regulations, of course.
What's worse is that the email is often delayed at the sender (cheap bulk email services) or the receiver (gray listing), but for no reason I can fathom have a short expiration date.
What's worse they are often unique AND delivered out of order AND have no timestamp or sequence number. So you get to guess which is the newest, using any other fails, and the ones that succeed often time out before they can be used.
Having an expiration date as short as 15 minutes seems insane and counter productive.
The convenience advantage is significant, and it goes farther than convenience, since it’s very common for services to have their verification mail blocked or sent to spam. (Bonus pain: there’s no user-visible difference between delayed and blocked mail.)
The privacy advantage is also significant and real: no, not every web app sends an onboarding reminder, and the current state of web apps came to be without this functionality, so you can expect behaviour changes for those services that value the privacy, plus new services/authentication options to spring up that weren’t previously possible.
I thought this initially, the privacy thing looks like a non issue and is confusing. But the advantage is stated in the preceding paragraph. The user doesn't need to leave the signup flow and doesn't need to open their email.
The auth mechanism flows through the cookies, assuming the email provider offers a web browser and the user is signed in this could be seamless, although I'm not certain the cookie could be safely read cross site without risk or without being blocked by the browse
It wouldn't be simple to implement but not impossible, and it sounds like it would cost nothing to the user, it could work behind the scenes. Like as a user you are logged in to gmail or zoho mail in your browser. You sihn up for another service and you didn't get a confirmation email, just a welcome email. No fucks are given, it just works.
Mobile does this with autofilling auth codes sometimes with sms, so there's precedent.
Congrats OP the idea looks feasible. I'm usually the ackshually guy looking for the nitpick, but it looks nice. Will check the technicals later, cause the devil is in the details.
I think there is benefit to this because folding some identity primitives into the browser helps the user (in UX, in security). This was certainly true of password managers.
The other comments talk about how you will need to have a fallback. That is certainly true. But just because you have to have a fallback doesn't mean you can't improve things.
> Every web application nowadays send you a welcome, onboarding, reminder after the verification. (No user privacy enhancement)
But would they need to if they could trust info coming from the browser?
> Verifying control of an email address is a frequent activity on the web today and is used both to prove the user has provided a valid email address
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.
I have a couple of problems with this, although kudos for the author and I won't dismiss this project's usefulness or value.
1) Email shouldn't be used for this purpose. It is inherently insecure. Many have tried, you won't succeed.
2) The subject line of the email should not contain verification details (code), it shouldn't even imply the content of the email. "A secure message from <insert site>" is enough.
3) The device receiving the verification message is often not the same device that initiated the process. It is very important that users are able to easily type out the code in the webapp, instead of what many do: require a link to be opened.
4) Alright, use email, but don't treat as a special or absolute means of contacting users. The whole "contact user" aspect should be abstracted to a point. Any messaging app that the user would like to use should be used. There are dozens of them, and all of them should be abstracted to the webapp. Managing api keys and integrations sounds like a nightmare, this is one big reason no one is doing it. But again, that's my gripe, this is a solvable problem, services and libraries to make it easier should exist, but where they don't .. the developers of the application should take on the costs associated with supporting them. Maybe not dozens but a handful of messaging protocols, based on target audience can be used (e.g.: Signal,Whatsapp, Weechat, VK, Telegram, Bluesky, Twitter) - 7 api keys to rotate once every few months and you've just made billions of potential users happy!
5) Perhaps the problem is a lack of a "secure address resolution layer" to messaging? Without requiring api keys and all of that, it should be possible to resolve the address of a recipient, encrypt a message to them, using their public key, and simply send it. Messaging apps should support a standard protocol of receiving external messages this way. The protocol should also allow including a "reply" address?
Is there a nonce relay vulnerability here? You try to verify your email with site A. Site A starts an email verification with site B. Site B sends a nonce to A, A relays the nonce to the user. The user generates the proof, sends it to A. Then A sends it to B.
41 comments
[ 16.2 ms ] story [ 956 ms ] threadThis seems extremely marginal. The point of verifying an email address is to subsequently use it to send email.
How can you avoid revealing the application through the `Origin` header?
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.
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.
* 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.
No way in hell I’m gonna learn another of these nightmarish protocols unless this is somehow much much better.
* 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.
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...
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.
1) Not all email providers will implement this, and
2) Users may not be signed into their email at the moment they signup
As a developer, I would find it easier to have one "verification code" flow for all users rather than fragmenting the process; it's much easier to document for your support staff. Again, not a bad proposal but perhaps not very useful in practice.
But that does relate to I keep wanting an email claim for Passkeys. A user's browser/OS could verify an email address once and then associate it with a Passkey. Passkeys might be a good place for that (as Persona/BrowserID suggested). Obviously some browsers could lie about verifying the email address in the claim and there might still need to be more steps to it, but if you are already taking Passkeys it doesn't necessarily add an entirely different flow to accept a verified email claim from a Passkey (and/or decide you don't trust that Passkey's claim and trigger your regular verification code flow).
There is no advantage.
"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." Every web application nowadays send you a welcome, onboarding, reminder after the verification. (No user privacy enhancement)
So we get a new process that solves nothing, but makes everything complicated. (And complicated helps the big and hurt the little in th long run)
Not verified but feels like a Google draft that closes the web.
I can't tell you how many times email verification context switches made me completely lose track of what I was doing.
There's literally no worse context switch than having to go into your inbox, wait for an email, then come back to the appropriate tab to complete registration or login.
There are probably dozens, maybe hundreds, of services I never finished registering for all on account of this problem.
I worked authc/authz and security for a large fintech and we constantly butted heads against the growth folks. They fought hard and eventually won the right to do account creation and IDV without email verification. You don't have to verify your email until you're already making transactions, and that does wonders for growth. We're still accountable for all the stringent KYC regulations, of course.
What's worse they are often unique AND delivered out of order AND have no timestamp or sequence number. So you get to guess which is the newest, using any other fails, and the ones that succeed often time out before they can be used.
Having an expiration date as short as 15 minutes seems insane and counter productive.
The privacy advantage is also significant and real: no, not every web app sends an onboarding reminder, and the current state of web apps came to be without this functionality, so you can expect behaviour changes for those services that value the privacy, plus new services/authentication options to spring up that weren’t previously possible.
The auth mechanism flows through the cookies, assuming the email provider offers a web browser and the user is signed in this could be seamless, although I'm not certain the cookie could be safely read cross site without risk or without being blocked by the browse
It wouldn't be simple to implement but not impossible, and it sounds like it would cost nothing to the user, it could work behind the scenes. Like as a user you are logged in to gmail or zoho mail in your browser. You sihn up for another service and you didn't get a confirmation email, just a welcome email. No fucks are given, it just works.
Mobile does this with autofilling auth codes sometimes with sms, so there's precedent.
Congrats OP the idea looks feasible. I'm usually the ackshually guy looking for the nitpick, but it looks nice. Will check the technicals later, cause the devil is in the details.
I think there is benefit to this because folding some identity primitives into the browser helps the user (in UX, in security). This was certainly true of password managers.
The other comments talk about how you will need to have a fallback. That is certainly true. But just because you have to have a fallback doesn't mean you can't improve things.
> Every web application nowadays send you a welcome, onboarding, reminder after the verification. (No user privacy enhancement)
But would they need to if they could trust info coming from the browser?
0: I wrote an intro to this here: https://www.infoq.com/articles/federated-credentials-managem...
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.
1) Email shouldn't be used for this purpose. It is inherently insecure. Many have tried, you won't succeed.
2) The subject line of the email should not contain verification details (code), it shouldn't even imply the content of the email. "A secure message from <insert site>" is enough.
3) The device receiving the verification message is often not the same device that initiated the process. It is very important that users are able to easily type out the code in the webapp, instead of what many do: require a link to be opened.
4) Alright, use email, but don't treat as a special or absolute means of contacting users. The whole "contact user" aspect should be abstracted to a point. Any messaging app that the user would like to use should be used. There are dozens of them, and all of them should be abstracted to the webapp. Managing api keys and integrations sounds like a nightmare, this is one big reason no one is doing it. But again, that's my gripe, this is a solvable problem, services and libraries to make it easier should exist, but where they don't .. the developers of the application should take on the costs associated with supporting them. Maybe not dozens but a handful of messaging protocols, based on target audience can be used (e.g.: Signal,Whatsapp, Weechat, VK, Telegram, Bluesky, Twitter) - 7 api keys to rotate once every few months and you've just made billions of potential users happy!
5) Perhaps the problem is a lack of a "secure address resolution layer" to messaging? Without requiring api keys and all of that, it should be possible to resolve the address of a recipient, encrypt a message to them, using their public key, and simply send it. Messaging apps should support a standard protocol of receiving external messages this way. The protocol should also allow including a "reply" address?