7 ms·

Email verification protocol

214 points by sgoto 11mo ago

sgoto 11mo ago
Verify email addresses automatically
philipwhiuk 10mo ago
> 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.
- callahad 10mo ago
  I largely agree, but I still think there's a compelling argument that blinding the issuer implicitly precludes API gatekeeping or censorship. Sites wouldn't need to pre-register with any issuer, nor could the issuer refuse to provide tokens on the basis of where they'll be used.
mvid 10mo ago
Might want to take a look at https://github.com/zkemail https://github.com/zkemail
- deleted 10mo ago
  [deleted]
stavros 10mo ago
This is what Mozilla Persona did, too. I loved the UX, but it wasn't very successful, unfortunately.
- ErikBjare 10mo ago
  Apparently Persona was even based on some prior work called "VerifiedEmailProtocol", eerily similar to the OP
  - callahad 10mo ago
    The Verified Email Protocol got renamed to BrowserID, and Persona was its reference implementation. This looks broadly similar to that, but with some newer primitives (SD-JWT) and a focus on autocomplete as an entrypoint to the flow. If I recall correctly, the entire JOSE suite (JWT, JWK, JWE, etc.) was still under active iteration while we were building Persona. And hey, I applaud the effort. Persona got a lot of things right, and I still think we as an industry can do better than Passkeys. For historic interest, the Persona After Action Report has a few key insights from when we spun down the project: https://wiki.mozilla.org/Identity/Persona_AAR https://wiki.mozilla.org/Identity/Persona_AAR
littlestymaar 10mo ago
> 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?
- gruez 10mo ago
  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.
  - littlestymaar 10mo ago
    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.
ericpauley 10mo ago
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.
- kogir 10mo ago
  OIDC is usually limited to a small selection of providers.
  - ericpauley 10mo ago
    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.
  - gethly 10mo ago
    Well the problem is simply user base. There is no point in being provider if you have 100 users. On the other hand, despite OIDC being standardised, there are way too many ways of implementing it. It is essentially impossible to have a "wildcard" support for OIDC providers. How do I know? I just implemented one myself. For example, providers usually support only one or very few authorisation flows, so in reality you would likely end up with a lot of failed attempts to sign up with some "3rd world" provider. PS: just take PKCE where the provider has no way of communicating whether it is supported, or required, at all.
    - 9dev 10mo ago
      I have just added OIDC support for bring-your-own-SSO to our application, and it wasn’t as bad as you make it sound: As long as the identity provider exposes a well-known OpenID configuration endpoint, you can figure it out (including whether PKCE is required or supported, by the way!) 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.
yomismoaqui 10mo ago
"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.
- Y_Y 10mo ago
  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).
l___l 10mo ago
Why must apps require email? Why not only username and password?
- zetanor 10mo ago
  Because it's less expensive to send a few e-mails than to provide customer support to everyone who forgets their password.
- jgalt212 10mo ago
  I agree. username and password is much more robust to credential stuffing attacks.
  - gruez 10mo ago
    > username and password is much more robust to credential stuffing attacks. /s?
    - jgalt212 10mo ago
      tell me how it's not.
      - crazygringo 10mo ago
        You're the one who made the claim. So please explain how it is.
        cxr 10mo ago
        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.
meonkeys 10mo ago
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?
- hastamelo 10mo ago
  author: https://www.w3.org/community/wicg/ https://www.w3.org/community/wicg/ https://wicg.io/ https://wicg.io/
  - hirsin 10mo ago
    And specifically Sam goto (Google, fedcm) and Dick Hardt (hello, oauth2 spec writer). 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.
turnsout 10mo ago
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.
- TheNewsIsHere 10mo ago
  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.
- thayne 10mo ago
  > This protocol solves a pretty contrived problem ("By sending the email verification code, the inbox provider knows the user is using that service!") 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.
neilv 10mo ago
* 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.
- cartofupai 10mo ago
  The surveilance conpanies are already in the loop. They get the email verification code. This attempts to make the process smoother.
phyzome 10mo ago
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.
- immibis 10mo ago
  They could consider not using email at all
  - nine_k 10mo ago
    Any open channel that can be read by a human that could be lucratively scammed will be used the same way.
    - immibis 10mo ago
      I don't understand what you mean. This is used for creating an account on a web app. You don't actually need an email or anything else for that.
- kbaker 10mo ago
  Why is the solution not OAuth/OIDC? Or maybe creating some sort of reduced OAuth "Anonymous-Site-Verifying-Your-Email-Exists" flow?
  - thayne 10mo ago
    Not everyone uses an email provider that is also also an OIDC provider.
    - kbaker 10mo ago
      But not every email provider would support this new (from scratch) protocol either? Just don't see the need to reinvent OAuth but with a reduced scope for just email validation. Just add a happy path for this into OAuth itself?
binary132 10mo ago
why does it have to be email?
harvey9 10mo ago
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.
portaouflop 10mo ago
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.
Arch-TK 10mo ago
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.
- hypeatei 10mo ago
  What is your first paragraph referring to? This whole standard is trying to eliminate the context switching that happens when a website wants to verify your email. Perhaps you mistook the two bullet points outlining what currently happens as goals for the standard?
  - Arch-TK 10mo ago
    The new standard relies on some possibly third party (at least that seems somewhat implied here) which has a database of email addresses which it can attest exist and which is tied to some user authentication. If the email address isn't yet known to this third party (or, you are not logged in), there _will_ be a context switch which in my example case will occur for every registration since I use a per-entity email address.
    - nopassrecover 10mo ago
      Agree with you, though potentially easily remediated if that third party provisioned for the “+” convention.
      - 10mo ago
jauntywundrkind 10mo ago
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 https://github.com/w3c-fedid/FedCM/issues/677 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/rwu9wFl0mF4/m/bikJ9wIjAQAJ https://groups.google.com/a/chromium.org/g/blink-dev/c/rwu9w...
nine_k 10mo ago
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.
- dcm360 10mo ago
  > 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). 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.
hypeatei 10mo ago
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.
- cartofupai 10mo ago
  Just like login federated or with email/pwd.
- TZubiri 10mo ago
  Of course, if the new standard which no one supports doesn't work, the incumbent standard would be used.
- WorldMaker 10mo ago
  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).
Etheryte 10mo ago
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.
- callahad 10mo ago
  The key mitigation is that the protocol - as envisioned - is mediated by the user agent; you as a website cannot silently fire off probes that tell you anything.
  - kbaker 10mo ago
    This section https://github.com/WICG/email-verification-protocol/blob/main/README.md#2-email-selection https://github.com/WICG/email-verification-protocol/blob/mai... could easily be done by malicious JS, an ad script, or the website itself, and then as the RP gets the output of 6.4) email and email_verified claims. I'm guessing that this proposal requires new custom browser (user-agent) code just to handle this protocol? Like a secure <input Email> element that makes sure there is some user input required to select a saved one, and that the value only goes to the actual server the user wants, that cannot be replaced by malicious JS.
    - callahad 10mo ago
      > This section could easily be done by [...] Less easily than you'd think. You'd have to make an authenticated cross-origin request to the issuer, which would be equivalent to mounting a Cross-Site Request Forgery (CSRF) attack against the target email providers. Even if you could send an authenticated request, the Same Origin Policy means your site won't be able to read the result unless the issuer explicitly returns appropriate CORS headers including `Access-Control-Allow-Origin: <* or your domain>` and `Access-Control-Allow-Credentials: true` in its response. Browsers can exempt themselves from these constraints when making requests for their own purposes, but that's not an option available to web content. > I'm guessing that this proposal requires new custom browser (user-agent) code just to handle this protocol? Correct; which is going to be the main challenge for this to gain traction. We called it the "three-way cold start" in Persona: sites, issuers, and browsers are all stuck waiting for the other two to reach critical mass before it makes sense for them to adopt the protocol. Google could probably sidestep that problem by abusing their market dominance in both the browser and issuer space, but I don't see the incentive nor do I see it being feasible for anyone else.
bullen 10mo ago
Or you just use SMTP and read the 200 response on the SEND?
- 1718627440 10mo ago
  In extension to that spirit, some SPAM could be eliminated, if more people would turn address verification on in their SMTP servers, which makes the delivery peers symmetric.
  - gerdesj 10mo ago
    Do you mean source or destination address verification or both? 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?
    - 1718627440 10mo ago
      With source address verification (and server validation) it is guaranteed that the mail comes from the server that controls the senders mail address and that this address does indeed exist. With symmetric I mean that both servers then resolve each other the same, both check whether their side of mailbox exists and they share the time during which this happens, so you can't use it for DOS, since it takes your time as well.
    - gsich 10mo ago
      You send me mail with noreply@example. I go to your MX to see if noreply@example will receive mails. If not you are spamming.
0x073 10mo ago
Make everything what works complicated. 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.
- echelon 10mo ago
  > There is no advantage. 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.
  - wl 10mo ago
    And when a customer fat fingered their email address and that fintech company didn't bother verifying email addresses, policy probably prohibited granting a request from the email address owner to remove their address from the account because they're not the financial account owner. Fortunately for that company, financial institutions seem to avoid Gmail's spam filter no matter how many times I mark those emails as spam.
  - 0x073 10mo ago
    > 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. Then it's something maybe the customer isn't interested in the first place. Most of the time mail just works for me only issues are sometimes greylisting and it takes hours. I can understand it from the company side, but not sure how well it really works when someone use a mail app on mobile and on desktop not even logged into the mail account.
rekabis 10mo ago
> 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.
notepad0x90 10mo ago
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?
- TZubiri 10mo ago
  1) Email shouldn't be used for this purpose. It is inherently insecure. Many have tried, you won't succeed. Sorry if I didn't read the rest. But email isn't secure? Email isn't used for auth? First I've heard of such a thing
  - notepad0x90 10mo ago
    > Email isn't used for auth? I didn't say that, you added that part. It is used for auth. it isn't secure. Email is less secure than SMS, unless you encrypt your email (even then..). With email, there are multiple middle parties that can just read the message. Forget malicious insiders, it is more than reasonable to assume at least one MTA out there is compromised. Mail server CVE's aren't that rare. Furthermore, despite email being used for auth, as you correctly claimed, email clients aren't secured like authentication applications or password managers are. For most people, a compromise of their email account means a compromise of most of their other accounts. Even furthermore, not only is email used for authentication, email is being used to revoke,reset and tamper with other authentication methods and account security in general. You don't just login to apps via email, your password, MFA, account changes,etc.. can all be done by someone controlling your email (and more and more, your phone number/SIM these days). End to end encryption is all the rage on sites like HN, but I'm shocked when those same people have no problem using email for sensitive operations.
8organicbits 10mo ago
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.
- callahad 10mo ago
  Step 5.2; the browser binds the KB-JWT to the site it's on, so Site A would receive a JWT that is only valid for Site A.
timedrun 10mo ago
Creating a email/messaging protocol to solve spam, which is a different problem from verifying sign ups to solve spam sign ups in this thread, but is relevant for people in this thread interested in the issue of spam. It is directly compatible with email/messengers, including all of the large email providers, low false negative rate compared to current spam filtering, free for senders. Check this profile for the email if you wanna ask for more info or get updates.
jiveturkey 10mo ago
Surprising proposal. Normally I'd review the credentials of the authors but it's late Sunday night so nevermind. I like the idea in general - an OIDC-like flow without needing any a priori setup. But, the RP has only a signed token with the pubkey in DNS, so this doesn't prove anything about the user unless the RP also verifies against some trusted and known email providers. This is absolutely awful for the Internet and makes sure power stays concentrated. PLEASE don't let this become a thing. Second, this doesn't improve privacy. Most RPs will send an email right at signup, or soon thereafter. Thus the email provider does learn of the individual's association with that web application. A last issue that's immediately obvious, is that you have to use a webmail interface.
deknos 10mo ago
to be honest, i am kinda wondering, why mailserver do not publish on some http service: - whom the accept mails from under which conditions - who's blocked and why - perhaps hashed-and-salted-email-addresses for verification - how much spam (as the receiver understands it) happened from where - that you produce tokens with hashcash, so you unknown senders can verify themselves with that per mail/receiver
mcny 10mo ago
If this is a proposal, how do I politely refuse and ask these people to stop working on this? Or is this one of those things they will shove in our faces whether we like it or not?
jesprenj 10mo ago
This needs to be implemented in Firefox ASAP. Although this would require firefox to gain support for IMAP.
gsich 10mo ago
Talk about overengineering. Why not allow users to use the service (or parts of it) without verification?
Bender 10mo ago
Ages ago we intentionally configured MTA's to prevent enumeration and validation of email addresses on purpose. This appears to be a convoluted way to unwind that change and in my opinion would be heavily abused by shady email marketing groups on day 1. With all due respect I would never implement this in a company and would fight it. I choose my battles carefully before presenting them to the board until groups such as NCC [1] have reviewed the implementation concepts and details. All it would take is one poorly coded application using this incorrectly to be abused. i.e. devil in the implementation details or otherwise known as the weakest link. Having NCC validate every single implementation is going to get very expensive. [1] - https://www.nccgroup.com/ https://www.nccgroup.com/
npodbielski 10mo ago
Seems like Oidc os much easier to implement and use by the user.

214 points by sgoto 11mo ago

sgoto 11mo ago

Verify email addresses automatically

> 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.

callahad 10mo ago
I largely agree, but I still think there's a compelling argument that blinding the issuer implicitly precludes API gatekeeping or censorship. Sites wouldn't need to pre-register with any issuer, nor could the issuer refuse to provide tokens on the basis of where they'll be used.

mvid 10mo ago

Might want to take a look at https://github.com/zkemail https://github.com/zkemail

deleted 10mo ago
[deleted]

stavros 10mo ago

This is what Mozilla Persona did, too. I loved the UX, but it wasn't very successful, unfortunately.

ErikBjare 10mo ago
Apparently Persona was even based on some prior work called "VerifiedEmailProtocol", eerily similar to the OP
- callahad 10mo ago
  The Verified Email Protocol got renamed to BrowserID, and Persona was its reference implementation. This looks broadly similar to that, but with some newer primitives (SD-JWT) and a focus on autocomplete as an entrypoint to the flow. If I recall correctly, the entire JOSE suite (JWT, JWK, JWE, etc.) was still under active iteration while we were building Persona. And hey, I applaud the effort. Persona got a lot of things right, and I still think we as an industry can do better than Passkeys. For historic interest, the Persona After Action Report has a few key insights from when we spun down the project: https://wiki.mozilla.org/Identity/Persona_AAR https://wiki.mozilla.org/Identity/Persona_AAR

littlestymaar 10mo ago

> 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?

gruez 10mo ago
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.
- littlestymaar 10mo ago
  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.

ericpauley 10mo ago

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.

kogir 10mo ago
OIDC is usually limited to a small selection of providers.
- ericpauley 10mo ago
  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.
- gethly 10mo ago
  Well the problem is simply user base. There is no point in being provider if you have 100 users. On the other hand, despite OIDC being standardised, there are way too many ways of implementing it. It is essentially impossible to have a "wildcard" support for OIDC providers. How do I know? I just implemented one myself. For example, providers usually support only one or very few authorisation flows, so in reality you would likely end up with a lot of failed attempts to sign up with some "3rd world" provider. PS: just take PKCE where the provider has no way of communicating whether it is supported, or required, at all.
  - 9dev 10mo ago
    I have just added OIDC support for bring-your-own-SSO to our application, and it wasn’t as bad as you make it sound: As long as the identity provider exposes a well-known OpenID configuration endpoint, you can figure it out (including whether PKCE is required or supported, by the way!) 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.

yomismoaqui 10mo ago

"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.

Y_Y 10mo ago
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).

l___l 10mo ago

Why must apps require email? Why not only username and password?

zetanor 10mo ago
Because it's less expensive to send a few e-mails than to provide customer support to everyone who forgets their password.
jgalt212 10mo ago
I agree. username and password is much more robust to credential stuffing attacks.
- gruez 10mo ago
  > username and password is much more robust to credential stuffing attacks. /s?
  - jgalt212 10mo ago
    tell me how it's not.
    - crazygringo 10mo ago
      You're the one who made the claim. So please explain how it is.
      - cxr 10mo ago
        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.

meonkeys 10mo ago

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?

hastamelo 10mo ago
author: https://www.w3.org/community/wicg/ https://www.w3.org/community/wicg/ https://wicg.io/ https://wicg.io/
- hirsin 10mo ago
  And specifically Sam goto (Google, fedcm) and Dick Hardt (hello, oauth2 spec writer). 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.

turnsout 10mo ago

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.

TheNewsIsHere 10mo ago
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.
thayne 10mo ago
> This protocol solves a pretty contrived problem ("By sending the email verification code, the inbox provider knows the user is using that service!") 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.

neilv 10mo ago

* 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.

cartofupai 10mo ago
The surveilance conpanies are already in the loop. They get the email verification code. This attempts to make the process smoother.

phyzome 10mo ago

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.

immibis 10mo ago
They could consider not using email at all
- nine_k 10mo ago
  Any open channel that can be read by a human that could be lucratively scammed will be used the same way.
  - immibis 10mo ago
    I don't understand what you mean. This is used for creating an account on a web app. You don't actually need an email or anything else for that.
kbaker 10mo ago
Why is the solution not OAuth/OIDC? Or maybe creating some sort of reduced OAuth "Anonymous-Site-Verifying-Your-Email-Exists" flow?
- thayne 10mo ago
  Not everyone uses an email provider that is also also an OIDC provider.
  - kbaker 10mo ago
    But not every email provider would support this new (from scratch) protocol either? Just don't see the need to reinvent OAuth but with a reduced scope for just email validation. Just add a happy path for this into OAuth itself?

binary132 10mo ago

why does it have to be email?

harvey9 10mo ago

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.

portaouflop 10mo ago

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.

Arch-TK 10mo ago

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.

hypeatei 10mo ago
What is your first paragraph referring to? This whole standard is trying to eliminate the context switching that happens when a website wants to verify your email. Perhaps you mistook the two bullet points outlining what currently happens as goals for the standard?
- Arch-TK 10mo ago
  The new standard relies on some possibly third party (at least that seems somewhat implied here) which has a database of email addresses which it can attest exist and which is tied to some user authentication. If the email address isn't yet known to this third party (or, you are not logged in), there _will_ be a context switch which in my example case will occur for every registration since I use a per-entity email address.
  - nopassrecover 10mo ago
    Agree with you, though potentially easily remediated if that third party provisioned for the “+” convention.
    - 10mo ago

jauntywundrkind 10mo ago

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 https://github.com/w3c-fedid/FedCM/issues/677 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/rwu9wFl0mF4/m/bikJ9wIjAQAJ https://groups.google.com/a/chromium.org/g/blink-dev/c/rwu9w...

nine_k 10mo ago

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.

dcm360 10mo ago
> 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). 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.

hypeatei 10mo ago

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.

cartofupai 10mo ago
Just like login federated or with email/pwd.
TZubiri 10mo ago
Of course, if the new standard which no one supports doesn't work, the incumbent standard would be used.
WorldMaker 10mo ago
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).

Etheryte 10mo ago

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.

callahad 10mo ago
The key mitigation is that the protocol - as envisioned - is mediated by the user agent; you as a website cannot silently fire off probes that tell you anything.
- kbaker 10mo ago
  This section https://github.com/WICG/email-verification-protocol/blob/main/README.md#2-email-selection https://github.com/WICG/email-verification-protocol/blob/mai... could easily be done by malicious JS, an ad script, or the website itself, and then as the RP gets the output of 6.4) email and email_verified claims. I'm guessing that this proposal requires new custom browser (user-agent) code just to handle this protocol? Like a secure <input Email> element that makes sure there is some user input required to select a saved one, and that the value only goes to the actual server the user wants, that cannot be replaced by malicious JS.
  - callahad 10mo ago
    > This section could easily be done by [...] Less easily than you'd think. You'd have to make an authenticated cross-origin request to the issuer, which would be equivalent to mounting a Cross-Site Request Forgery (CSRF) attack against the target email providers. Even if you could send an authenticated request, the Same Origin Policy means your site won't be able to read the result unless the issuer explicitly returns appropriate CORS headers including `Access-Control-Allow-Origin: <* or your domain>` and `Access-Control-Allow-Credentials: true` in its response. Browsers can exempt themselves from these constraints when making requests for their own purposes, but that's not an option available to web content. > I'm guessing that this proposal requires new custom browser (user-agent) code just to handle this protocol? Correct; which is going to be the main challenge for this to gain traction. We called it the "three-way cold start" in Persona: sites, issuers, and browsers are all stuck waiting for the other two to reach critical mass before it makes sense for them to adopt the protocol. Google could probably sidestep that problem by abusing their market dominance in both the browser and issuer space, but I don't see the incentive nor do I see it being feasible for anyone else.

bullen 10mo ago

Or you just use SMTP and read the 200 response on the SEND?

1718627440 10mo ago
In extension to that spirit, some SPAM could be eliminated, if more people would turn address verification on in their SMTP servers, which makes the delivery peers symmetric.
- gerdesj 10mo ago
  Do you mean source or destination address verification or both? 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?
  - 1718627440 10mo ago
    With source address verification (and server validation) it is guaranteed that the mail comes from the server that controls the senders mail address and that this address does indeed exist. With symmetric I mean that both servers then resolve each other the same, both check whether their side of mailbox exists and they share the time during which this happens, so you can't use it for DOS, since it takes your time as well.
  - gsich 10mo ago
    You send me mail with noreply@example. I go to your MX to see if noreply@example will receive mails. If not you are spamming.

0x073 10mo ago

Make everything what works complicated. 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.

echelon 10mo ago
> There is no advantage. 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.
- wl 10mo ago
  And when a customer fat fingered their email address and that fintech company didn't bother verifying email addresses, policy probably prohibited granting a request from the email address owner to remove their address from the account because they're not the financial account owner. Fortunately for that company, financial institutions seem to avoid Gmail's spam filter no matter how many times I mark those emails as spam.
- 0x073 10mo ago
  > 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. Then it's something maybe the customer isn't interested in the first place. Most of the time mail just works for me only issues are sometimes greylisting and it takes hours. I can understand it from the company side, but not sure how well it really works when someone use a mail app on mobile and on desktop not even logged into the mail account.

rekabis 10mo ago

> 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.

notepad0x90 10mo ago

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?

TZubiri 10mo ago
1) Email shouldn't be used for this purpose. It is inherently insecure. Many have tried, you won't succeed. Sorry if I didn't read the rest. But email isn't secure? Email isn't used for auth? First I've heard of such a thing
- notepad0x90 10mo ago
  > Email isn't used for auth? I didn't say that, you added that part. It is used for auth. it isn't secure. Email is less secure than SMS, unless you encrypt your email (even then..). With email, there are multiple middle parties that can just read the message. Forget malicious insiders, it is more than reasonable to assume at least one MTA out there is compromised. Mail server CVE's aren't that rare. Furthermore, despite email being used for auth, as you correctly claimed, email clients aren't secured like authentication applications or password managers are. For most people, a compromise of their email account means a compromise of most of their other accounts. Even furthermore, not only is email used for authentication, email is being used to revoke,reset and tamper with other authentication methods and account security in general. You don't just login to apps via email, your password, MFA, account changes,etc.. can all be done by someone controlling your email (and more and more, your phone number/SIM these days). End to end encryption is all the rage on sites like HN, but I'm shocked when those same people have no problem using email for sensitive operations.

8organicbits 10mo ago

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.

callahad 10mo ago
Step 5.2; the browser binds the KB-JWT to the site it's on, so Site A would receive a JWT that is only valid for Site A.

timedrun 10mo ago

Creating a email/messaging protocol to solve spam, which is a different problem from verifying sign ups to solve spam sign ups in this thread, but is relevant for people in this thread interested in the issue of spam. It is directly compatible with email/messengers, including all of the large email providers, low false negative rate compared to current spam filtering, free for senders. Check this profile for the email if you wanna ask for more info or get updates.

jiveturkey 10mo ago

Surprising proposal. Normally I'd review the credentials of the authors but it's late Sunday night so nevermind. I like the idea in general - an OIDC-like flow without needing any a priori setup. But, the RP has only a signed token with the pubkey in DNS, so this doesn't prove anything about the user unless the RP also verifies against some trusted and known email providers. This is absolutely awful for the Internet and makes sure power stays concentrated. PLEASE don't let this become a thing. Second, this doesn't improve privacy. Most RPs will send an email right at signup, or soon thereafter. Thus the email provider does learn of the individual's association with that web application. A last issue that's immediately obvious, is that you have to use a webmail interface.

deknos 10mo ago

to be honest, i am kinda wondering, why mailserver do not publish on some http service: - whom the accept mails from under which conditions - who's blocked and why - perhaps hashed-and-salted-email-addresses for verification - how much spam (as the receiver understands it) happened from where - that you produce tokens with hashcash, so you unknown senders can verify themselves with that per mail/receiver

mcny 10mo ago

If this is a proposal, how do I politely refuse and ask these people to stop working on this? Or is this one of those things they will shove in our faces whether we like it or not?

jesprenj 10mo ago

This needs to be implemented in Firefox ASAP. Although this would require firefox to gain support for IMAP.

gsich 10mo ago

Talk about overengineering. Why not allow users to use the service (or parts of it) without verification?

Bender 10mo ago

Ages ago we intentionally configured MTA's to prevent enumeration and validation of email addresses on purpose. This appears to be a convoluted way to unwind that change and in my opinion would be heavily abused by shady email marketing groups on day 1. With all due respect I would never implement this in a company and would fight it. I choose my battles carefully before presenting them to the board until groups such as NCC [1] have reviewed the implementation concepts and details. All it would take is one poorly coded application using this incorrectly to be abused. i.e. devil in the implementation details or otherwise known as the weakest link. Having NCC validate every single implementation is going to get very expensive. [1] - https://www.nccgroup.com/ https://www.nccgroup.com/

npodbielski 10mo ago

Seems like Oidc os much easier to implement and use by the user.