LGTM to extend up to 3 additional months (or 6 milestones).
On 10/8/26 6:00 p.m., Chromestatus wrote:
*Contact emails*
[email protected], [email protected], [email protected],
[email protected], [email protected]
*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
<https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3EIdentity%22>
*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
<https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?*
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
<https://chromestatus.com>.
--
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 [email protected].
To view this discussion visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6ac81275.6e0b2b3a.151e33.03fa.GAE%40google.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6ac81275.6e0b2b3a.151e33.03fa.GAE%40google.com?utm_medium=email&utm_source=footer>.
--
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 [email protected].
To view this discussion visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/04add302-2ff7-4f4f-99d0-c735c27ba527%40chromium.org.
