Intent to Experiment: Email Verification Protocol

86 views
Skip to first unread message

Sam Goto

unread,
May 19, 2026, 8:02:14 PM (17 hours ago) May 19
to blink-dev
Contact emails
go...@google.com

Explainer
https://github.com/samuelgoto/email-verification-protocol

Specification
Per TAG feedback, we broke the specification into two parts:
And a corresponding W3C frontend specification which we will provide as we go through the Origin Trial and see the API design settle.

Demos
https://code.sgo.to/2024/10/25/verified-email-autocomplete.html

Summary
EVP (email verification protocol) helps users create, access and recover accounts by providing cryptographic proof of ownership seamlessly rather than email OTPs manually. It requires website authors, email providers and browsers to participate.

Blink component
Blink>Identity

Web Feature ID
Missing feature

TAG review
https://github.com/w3ctag/design-reviews/issues/1169 

One of the main pieces of feedback was to take part of the spec to IETF (which would be able to assess parts of the proposal better), which we took by writing and circulating the following draft, as well as starting to find the appropriate groups for broader review: https://dickhardt.github.io/email-verification/draft-hardt-email-verification.html

TAG review status
We requested an early TAG review and got an "ambivalent". We will request another TAG review or reopen it as the design settles.

Goals for experimentation
There is much that we'd like to learn in origin trials, because there are multiple moving parts here. 

First, we'd like to gather evidence of developer demand and API fitness: is autocomplete a good entry point? what kinds of forms and UXs are out there? does the benefit developers get outweigh the cost of implementation? 

Second, we'd like to gather evidence if email providers are incentivized too. What's in it for them? Is the backend API appropriate? 

Third, we'd like to gather data on how users interact with the UX implementation: will users accept the prompt? do they expect the token to be shared during form submission or email selection? 

Fourth, we'd love to learn if other browsers empathize with the user and ecosystem pain too, and if the implementation choices we made are transferable to their architectures too. 

Fifth, more broadly, email verification is at the center of a lot of identity flows, so we'd like to learn how it might relate to other mechanisms, such as federation, phone number verification and password/passkey management.

Risks




Interoperability and Compatibility
No information provided

Gecko: Defer (https://github.com/mozilla/standards-positions/issues/1316) We filed for an early review before we had all of the information for Mozilla to make a proper assessment. We think we understand the proposal better now than we did 6 months ago, so we are planning to re-open the standard position request and try to offer some of the clarity that was lacking.

WebKit: No signal (https://github.com/WebKit/standards-positions/issues/578) We haven't formally gotten a review from Webkit, but we got some informal feedback last TPAC with their preference to augment WebOTP / one-time-codes and OTPs and activate IMAP clients (of which there are fewer) rather than email providers. We believe this alternative isn't necessarily mutually exclusive and can work symbiotically with what's being proposed. We expanded on that here: https://github.com/samuelgoto/email-verification-protocol#webotp-otps-vs-evts-and-imap

Web developers: Positive This API requires participation by websites and email providers. We successfully ran a devtrial with a few partners which we expect will join us running an original trial. Based on what we heard so far, we are optimistic this will hit a sweet spot with website authors, but  we'd like to gather further evidence of developer demand and API fitness in an actual production setup.

Other signals:

Ergonomics
We think a declarative autocomplete API strikes the right balance for developers and users. There are a series of other variations that we have explored and are open to revisiting based on developer feedback that we listed here: https://github.com/samuelgoto/email-verification-protocol#website-api

Activation
This proposal requires incentivizing and changing websites, email providers, browsers and, to a smaller extent, user behavior. Much of the incentives are going to be pulled by the availability of email providers, which we think might be feasible to bootstrap. More on the economics here:
https://github.com/samuelgoto/email-verification-protocol#activation-considerations

Security
https://github.com/samuelgoto/email-verification-protocol#security-considerations

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?

No information provided


Ongoing technical constraints
No information provided

Debuggability
Still being developed. Basic error messages in the developer console available.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?
No. We are planning to start on desktop first and then introduce Android. We aren't sure if it would be possible/useful to support WebView.

Is this feature fully tested by web-platform-tests?
Not currently available.

DevTrial instructions
https://github.com/WICG/email-verification-protocol/blob/main/HOWTO.md

Flag name on about://flags
#email-verification-protocol

Finch feature name
No information provided

Non-finch justification
No information provided

Requires code in //chrome?
True

Estimated milestones
Origin trial desktop first150
Origin trial desktop last153


Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5205725253074944?gate=5146029401964544

Links to previous Intent discussions
Intent to Prototype: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/68bb77c8.050a0220.257801.0191.GAE%40google.com


This intent message was generated by Chrome Platform Status.

Yoav Weiss (@Shopify)

unread,
7:46 AM (5 hours ago) 7:46 AM
to blink-dev, Sam Goto
On Wednesday, May 20, 2026 at 2:02:14 AM UTC+2 Sam Goto wrote:
I see that those two explainers are different.. What's preventing aligning them?

Sam Goto

unread,
10:36 AM (2 hours ago) 10:36 AM
to Yoav Weiss (@Shopify), blink-dev


On Wed, May 20, 2026, 4:46 AM Yoav Weiss (@Shopify) <yoav...@chromium.org> wrote:


On Wednesday, May 20, 2026 at 2:02:14 AM UTC+2 Sam Goto wrote:
I see that those two explainers are different.. What's preventing aligning them?

Ah, just a fork that I'm working on getting merged into the main branch. There was a batch of changes that we made recently (mostly on non-normative text) that we didn't have the time yet to review. But yeah, it should be momentarily merged into the WICG repo.

Yoav Weiss (@Shopify)

unread,
10:58 AM (2 hours ago) 10:58 AM
to Sam Goto, blink-dev
LGTM to experiment M150-M153 inclusive (but please merge the explainers to avoid confusion :D)

Yoav Weiss (@Shopify)

unread,
11:00 AM (2 hours ago) 11:00 AM
to Sam Goto, blink-dev
Oh, and can you also ask for a debuggability review?
Reply all
Reply to author
Forward
0 new messages