Intent to Experiment: Email Verification Protocol

Sam Goto

unread,

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. 

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

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.

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

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

Yoav Weiss (@Shopify)

unread,

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,

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,

Yoav Weiss (@Shopify)

unread,

Sam Goto

unread,

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

Oh, and can you also ask for a debuggability review?

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

LGTM to experiment M150-M153 inclusive (but please merge the explainers to avoid confusion :D)

Sam Goto

unread,

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

LGTM to experiment M150-M153 inclusive (but please merge the explainers to avoid confusion :D)

Thanks for the quick review!!!

Sam Goto

unread,

On Fri, May 22, 2026 at 12:03 PM Anton Bershanskyi <bersh...@gmail.com> wrote:

Is there a plan for Permission/Feature Policy and/or browser settings integration? CL 7868831 suggests that the current plan is to disable EVP in fenced frames and cross-origin documents. Is the final decision or just a temporary solution?

Yeah, disabling is just temporarily. We expect we'd figure out how to enable this in iframes at some point (e.g. as you suggested, with the proper permission/feature policies).

Will users 

This proposal might improve convenience, but also has two hidden effects. EVP appears to intentionally simultaneously reduce the friction of giving out personally identifiable information (PII) of real users and reduce the effort for email verification for automated users.

Accidental PII disclosure already occurs on the modern web. Is there a mechanism planned for opting out of the EVP flow and falling back to the old flow of 'submit email into a form' -> 'wait for an confirmation email' -> 'take action described in the email'?

Yes.

We are stil finalizing our settings / permissioning model, but as an approximation, we'd expect users to opt-in to this feature manually per email (and have global settings that enable/disable the feature).

I personally occasionally encounter forms which get filled out prior to my explicit action.

We want to figure out how to trigger EVP when (a) users type emails (e.g. maybe onblur) and (b) fill profiles, but we haven't figured out how to do that yet.

For example, I avoid storing credit card details in the browser because it is easier to copy few numbers than to dispute a charge. It would be unfortunate if user had multiple emails and autofill would auto-populate one email while the user actually wanted to input a different one. Will users be able to observe the information exchange between browser, RP Server, and Issuer?

I believe so, in its current implementation.

The second concern of automated form submissions by bots is even more challenging. Under the old flow, email mailbox providers can track which users sign up for a mail box just to activate an account elsewhere.

I'm not quite sure I understand the use case you are referring to (expand a bit?), but I just wanted to note that I don't think that email providers don't currently have any programatic / machine readable way to track which users sign-up for an account elsewhere.

Under the new scheme, the relying party is meant to validate ownership of the mailbox even without informing the mailbox provider of new account sign-up.

Anton Bershanskyi

unread,

This proposal might improve convenience, but also has two hidden effects. EVP appears to intentionally simultaneously reduce the friction of giving out personally identifiable information (PII) of real users and reduce the effort for email verification for automated users.

Accidental PII disclosure already occurs on the modern web. Is there a mechanism planned for opting out of the EVP flow and falling back to the old flow of 'submit email into a form' -> 'wait for an confirmation email' -> 'take action described in the email'? I personally occasionally encounter forms which get filled out prior to my explicit action. For example, I avoid storing credit card details in the browser because it is easier to copy few numbers than to dispute a charge. It would be unfortunate if user had multiple emails and autofill would auto-populate one email while the user actually wanted to input a different one. Will users be able to observe the information exchange between browser, RP Server, and Issuer?

The second concern of automated form submissions by bots is even more challenging. Under the old flow, email mailbox providers can track which users sign up for a mail box just to activate an account elsewhere. Under the new scheme, the relying party is meant to validate ownership of the mailbox even without informing the mailbox provider of new account sign-up.

Anton Bershanskyi

unread,

> > Under the old flow, email mailbox providers can track which users sign up for a mail box just to activate an account elsewhere.

> I'm not quite sure I understand the use case you are referring to (expand a bit?), but I just wanted to note that I don't think that email providers don't currently have any programatic / machine readable way to track which users sign-up for an account elsewhere.

Sam Goto

unread,

On Saturday, May 23, 2026 at 11:19:53 AM UTC-7 Anton Bershanskyi wrote:

Is there a plan for Permission/Feature Policy and/or browser settings integration? CL 7868831 suggests that the current plan is to disable EVP in fenced frames and cross-origin documents. Is the final decision or just a temporary solution?

More of a temporary solution. I think we'll have to figure out how to handle sub frames at some point, just hasn't gotten to the top of the list yet.

Will users 

This proposal might improve convenience, but also has two hidden effects. EVP appears to intentionally simultaneously reduce the friction of giving out personally identifiable information (PII) of real users and reduce the effort for email verification for automated users.

Accidental PII disclosure already occurs on the modern web. Is there a mechanism planned for opting out of the EVP flow and falling back to the old flow of 'submit email into a form' -> 'wait for an confirmation email' -> 'take action described in the email'? I personally occasionally encounter forms which get filled out prior to my explicit action. For example, I avoid storing credit card details in the browser because it is easier to copy few numbers than to dispute a charge. It would be unfortunate if user had multiple emails and autofill would auto-populate one email while the user actually wanted to input a different one. Will users be able to observe the information exchange between browser, RP Server, and Issuer?

I believe so. We are still iterating in our UX, but I think we share the same goals in giving users control and transparency over whats going on.

The second concern of automated form submissions by bots is even more challenging. Under the old flow, email mailbox providers can track which users sign up for a mail box just to activate an account elsewhere. Under the new scheme, the relying party is meant to validate ownership of the mailbox even without informing the mailbox provider of new account sign-up.

I'll reply this on the other message, which you seem to have expanded on.

Sam Goto

unread,

On Saturday, May 23, 2026 at 11:19:55 AM UTC-7 Anton Bershanskyi wrote:

> > Under the old flow, email mailbox providers can track which users sign up for a mail box just to activate an account elsewhere.

> I'm not quite sure I understand the use case you are referring to (expand a bit?), but I just wanted to note that I don't think that email providers don't currently have any programatic / machine readable way to track which users sign-up for an account elsewhere.

I'm concerned about use of EVP by bots to create many free-tier accounts with relying parties and inability of issuers to block bots. In other words, the existing email verification system has a problem of "farmability" and EVP might make account "farming" even easier.

<= this section isn't covered in this specific origin trial. This is "related work" that's worth noting, but not covered by this OT request specifically.

FWIW, it might be worth noting, in the context of bots, that we are actively trying to make logging in/out and creating accounts on websites programatically available to agents (I'm not sure if you make a distinction between agents and bots?), so seemed somewhat worth raising here:

Sam Goto

unread,

On Wed, May 20, 2026 at 7:35 AM Sam Goto <go...@google.com> wrote:

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.

Done.

Explainer:

Spec:

We renamed the repo so that it is more easily distinguishable to the IETF spec that will handle the protocol aspects (rather than the browser aspects):

Sam Goto

unread,

On Tuesday, June 16, 2026 at 11:28:40 AM UTC-7 Sam Goto wrote:

On Wed, May 20, 2026 at 7:35 AM Sam Goto <go...@google.com> wrote:

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.

Done.

Explainer:

Spec:

We renamed the repo so that it is more easily distinguishable to the IETF spec that will handle the protocol aspects (rather than the browser aspects):

... and ... to keep this thread up to date ... the issuance protocol has also moved out of a personal repo into an IETF draft: