Intent to Extend Experiment: Email Verification Protocol

[Chromestatus]

Contact emails

go...@google.com, yi...@google.com, cbies...@google.com, n...@google.com, ma...@chromium.org

Explainer

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

Specification

https://dickhardt.github.io/email-verification/draft-hardt-email-verification.html

Design docs

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

Summary

The EVP (email verification protocol) helps users create, access and recover accounts by providing cryptographic proof of ownership seamlessly rather than email OTPs manually.

Blink component

Blink>Identity

Web Feature ID

Missing feature

TAG review

We filed an early TAG review ~6 months ago and got an "ambivalent" assessment: https://github.com/w3ctag/design-reviews/issues/1169 One of the main asks was take part of the spec to IETF (which would be able to assess parts of the proposal better), which we have started the process by writing and circulating the following draft, as well as finding the appropriate groups: https://dickhardt.github.io/email-verification/draft-hardt-email-verification.html

TAG review status

Pending

Origin Trial Name

Email Verification Protocol

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.

Chromium Trial Name

EmailVerificationProtocol

Origin Trial documentation link

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

WebFeature UseCounter name

kEmailVerificationProtocol

Risks

Interoperability and Compatibility

No information provided

Gecko: Neutral (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 better the proposal now than we did 6 months ago, so we are planning to re-open the standard position request and try to offer 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. 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 that 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 listed here: https://github.com/samuelgoto/email-verification-protocol#website-api

Activation

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

Reason this experiment is being extended

First, it took us a bit more than we were expecting to resolve a privacy and UX discussion (opt-ins vs opt-outs) and that delayed our implementation on Android, which just released recently, so we haven't gotten enough data on how it performs against real users. We also iterated in our "loading" UX a couple of times (from inline indicators to browser toasts) and we are still working on that implementation on Android (we already implemented that on Desktop, and just recently released it). Second, we are also tightening up the implementation and specification of the email verification process for websites, which gets much harder to change after we launch (because there are a lot of relying parties). We are still making more backwards incompatible changes than we'd like, as a result of developer feedback, although the API has been stable for the last 2 branch cuts: https://developer.chrome.com/blog/email-verification-october-2026 Finally, we'd like to extend the origin trial is to allow us to gather in-person feedback and guidance from TPAC and IETF, which are happening just a couple of weeks after our original OT ended.

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

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

No
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

EmailVerificationProtocol

Requires code in //chrome?

True

Measurement

https://chromestatus.com/metrics/feature/timeline/popularity/5916 We also have a number of UMA metrics under Blink.Evp.*

Estimated milestones

Origin trial desktop first	150
Origin trial desktop last	156
Origin trial extension 1 end milestone	160
Origin trial Android first	154
Origin trial Android last	156

Link to entry on the Chrome Platform Status

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

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
Intent to Experiment: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMtUnc6OnWhdO%3D2hVznNzD_-YOfxVafLTAKCiSSzwN%3D5%3Dxm%2BuA%40mail.gmail.com

This intent message was generated by Chrome Platform Status.

[Mike Taylor]

LGTM to extend up to 3 additional months (or 6 milestones).

--
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/6ac81275.6e0b2b3a.151e33.03fa.GAE%40google.com.