Intent to Prototype: Email Verification Protocol

437 views
Skip to first unread message

Chromestatus

unread,
Sep 5, 2025, 7:52:57 PM (5 days ago)  Sep 5
to blin...@chromium.org, go...@google.com

Contact emails

go...@google.com

Explainer

https://github.com/dickhardt/email-verification-protocol

Specification

None

Summary

The EVP (email verification protocol) helps users create, access and recover accounts by providing cryptographic proof that they own an email address, rather than having to manually verify email addresses with magic links. https://github.com/dickhardt/email-verification-protocol



Blink component

Blink>Identity

Web Feature ID

Missing feature

Motivation

Verifying email addresses on the web today involves receiving magic link and proving that you have access to the email inbox. This is cumbersome for users and inefficient for developers: emails can take a while to arrive, can get into SPAM folders and users have to switch applications to verify them.



Initial public proposal

https://github.com/dickhardt/email-verification-protocol

TAG review

None

TAG review status

Pending

Risks



Interoperability and Compatibility

None



Gecko : No signal

WebKit : No signal

Web developers : No signals

Other signals :

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

None



Debuggability

None



Is this feature fully tested by web-platform-tests ?

No

Flag name on about://flags

None

Finch feature name

None

Non-finch justification

None

Requires code in //chrome?

False

Estimated milestones

No milestones specified



Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5205725253074944?gate=5165657771606016

This intent message was generated by Chrome Platform Status .

Reilly Grant

unread,
Sep 8, 2025, 3:44:18 PM (2 days ago)  Sep 8
to Chromestatus, blin...@chromium.org, go...@google.com
There's been some discussion recently on chromium-dev@ about a new phone number verification mechanism using flash calls. I'm curious if there's interest in expanding this work on email verification to include both email addresses and phone numbers.

Unrelatedly, as someone who hosts their own email I'm curious if there are reference implementations available for the email provider side of this system. I'd love to play around with this API and want to be sure it's not limited to users of the major email providers.
Reilly Grant |  Software Engineer | rei...@chromium.org  | Google Chrome


--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org .
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/68bb77c8.050a0220.257801.0191.GAE%40google.com .

Daniel Bratell

unread,
Sep 9, 2025, 11:24:53 AM (yesterday)  Sep 9
to Reilly Grant, Chromestatus, blin...@chromium.org, go...@google.com

That seems to be a major hurdle for this, unless every mail provider in the world sets up an email verification service, sites will have to maintain two code paths for email verification.

it also requires the user to be logged in to some kind of webmail service for their email in the browser they are using, with authentication handled by cookies, and for the verification site to be the same domain/site as the webmail so that those cookies are sent.  It seems to require a lot of things to be just right to be as smooth as envisioned.

(The spec could use more characters by the way, not everything needs to be 3 letters long, kty, alg, typ, iat, cnf, jwp, iss, aud, evp, ...)

/Daniel

Sam Goto

unread,
Sep 9, 2025, 12:04:51 PM (yesterday)  Sep 9
to Reilly Grant, Chromestatus, blin...@chromium.org
On Mon, Sep 8, 2025 at 12:43 PM Reilly Grant < rei...@chromium.org > wrote:
There's been some discussion recently on chromium-dev@ about a new phone number verification mechanism using flash calls.

Ah, that's pretty neat! I'll check out and report back what I learn from it!
I'm curious if there's interest in expanding this work on email verification to include both email addresses and phone numbers.

I think there are a lot of similarities and intersections from a use case perspective, but I think the mechanisms are pretty different. I'll keep an eye as we go along.

Unrelatedly, as someone who hosts their own email I'm curious if there are reference implementations available for the email provider side of this system. 
I'd love to play around with this API and want to be sure it's not limited to users of the major email providers.

This is a bit early, so there aren't any reference implementations yet. I'm personally using this on my own email servers too successfully for testing/development and I'd be happy to make the code available for others to try. WIll report back here too as this moves along and gets more stable! 

Sam Goto

unread,
Sep 9, 2025, 12:11:30 PM (yesterday)  Sep 9
to Daniel Bratell, Reilly Grant, Chromestatus, blin...@chromium.org
On Tue, Sep 9, 2025 at 8:24 AM Daniel Bratell < brat...@gmail.com > wrote:

That seems to be a major hurdle for this, unless every mail provider in the world sets up an email verification service

Yeah, this presupposes that email servers are going to be exporting this email verification service, which is a big if. 

, sites will have to maintain two code paths for email verification.

Yeah, same goes for websites: it requires them to add support for it too, so it certainly comes at a cost.

I do think that the benefits outweigh the costs, at least for a meaningful part of websites, that can help enough users.

Hard to know at the moment, so I'll keep an eye on the cost/benefit ratio for websites and see if we are striking the right balance, but that's part of the hypothesis that we are trying to test in this intent to prototype.  

it also requires the user to be logged in to some kind of webmail service for their email in the browser they are using, with authentication handled by cookies, and for the verification site to be the same domain/site as the webmail so that those cookies are sent.  It seems to require a lot of things to be just right to be as smooth as envisioned.

It does indeed require the user to be logged in.

You are right that it requires a lot of things to go right before it can provide value, but I think the key insight here is that this progressively enhances the status quo, without requiring any user behavioral change. Meaning, if none of the stars align (e.g. the email provider provides the service, the website supports the cryptographic proof and the user is logged in), the user just goes through what they were already going through with no behavioral change. But when the stars do align, they have a better time. So, a strict win, with no losses (other than the implementation cost) when it isn't available.  

(The spec could use more characters by the way, not everything needs to be 3 letters long, kty, alg, typ, iat, cnf, jwp, iss, aud, evp, ...)

All of these are coming from the JWT/SD-JWT+KB RFC, so a convention that is already in place and time-tested by developers deploying variations of OAuth. 

Reilly Grant

unread,
Sep 9, 2025, 1:22:54 PM (yesterday)  Sep 9
to Sam Goto, Daniel Bratell, Chromestatus, blin...@chromium.org
It would be nice if this could support the case where the user is not logged into their email provider (i.e. it could open an authentication page if no cookie is present). This matters for email providers that don't use a web-based client. For example, since I access my email with Thunderbird there's no cookie in my browser related to my email provider.
Reilly Grant |  Software Engineer | rei...@chromium.org  | Google Chrome

Sam Goto

unread,
Sep 9, 2025, 1:26:10 PM (yesterday)  Sep 9
to Reilly Grant, Daniel Bratell, Chromestatus, blin...@chromium.org
On Tue, Sep 9, 2025 at 10:22 AM Reilly Grant < rei...@chromium.org > wrote:
It would be nice if this could support the case where the user is not logged into their email provider (i.e. it could open an authentication page if no cookie is present). This matters for email providers that don't use a web-based client. For example, since I access my email with Thunderbird there's no cookie in my browser related to my email provider.

Were you thinking Thunderbird on desktop or mobile?

I can totally see how on mobile users are, for the most part, using native apps for email clients, rather than web email clients. So, yeah, will totally have to work on mobile too with native apps.

But for desktop, that hasn't occurred to me yet.

Daniel Bratell

unread,
Sep 9, 2025, 3:48:28 PM (yesterday)  Sep 9
to Reilly Grant, Sam Goto, Chromestatus, blin...@chromium.org

I was thinking about that when reading the explainer, and I can see why not doing it initially. If you are signing up for an account at www.possibly-malicious.site it could be scary to have something asking for your email password. Such questions could also make it easier for www.really-malicious.site to trick a user to hand over their email password to the wrong party.

It is certainly possible, but it would also add complexity and risks.

/Daniel

Sam Goto

unread,
Sep 9, 2025, 3:54:28 PM (yesterday)  Sep 9
to Daniel Bratell, Reilly Grant, Chromestatus, blin...@chromium.org
On Tue, Sep 9, 2025 at 12:48 PM Daniel Bratell < brat...@gmail.com > wrote:

I was thinking about that when reading the explainer, and I can see why not doing it initially. If you are signing up for an account at www.possibly-malicious.site it could be scary to have something asking for your email password. Such questions could also make it easier for www.really-malicious.site to trick a user to hand over their email password to the wrong party.

It is certainly possible, but it would also add complexity and risks.


Yeah, signing-in to the email provider can open a lot of challenges. Doesn't seem like we are cornering ourselves, but yeah, probably simplifies a bunch if we assume that the user is already logged in to the email provider.

PhistucK

unread,
9:45 AM (11 hours ago)  9:45 AM
to Sam Goto, Daniel Bratell, Reilly Grant, Chromestatus, blin...@chromium.org
>  with authentication handled by cookies
I created an issue for that part as (to my limited knowledge) it seems like it could be done in other ways.


☆ PhistucK


To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMtUnc6tit4yHzbSkDOBDM-U49U4T7QLHf9F%2Br37%3D1y7N9SYkg%40mail.gmail.com .
Reply all
Reply to author
Forward
0 new messages