LGTM to experiment M150-M153 inclusive (but please merge the explainers to avoid confusion :D)
On Wed, May 20, 2026 at 4:35 PM Sam Goto <[email protected]> wrote: > > > On Wed, May 20, 2026, 4:46 AM Yoav Weiss (@Shopify) < > [email protected]> wrote: > >> >> >> On Wednesday, May 20, 2026 at 2:02:14 AM UTC+2 Sam Goto wrote: >> >> *Contact emails* >> [email protected] >> >> *Explainer* >> https://github.com/samuelgoto/email-verification-protocol >> >> >> Why not https://github.com/WICG/email-verification-protocol ? >> 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. > > >> >> >> >> *Specification* >> Per TAG feedback, we broke the specification into two parts: >> An IETF backend specification here: https://dickhardt. >> github.io/email-verification/draft-hardt-email-verification.html >> 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 >> <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3EIdentity%22> >> >> *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 >> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?* >> 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 first150Origin 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 >> <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/CAOmohSLL6TB6HVb-G3hVhHbcgFfWbnMW4Og0YGHf%3DUBjaiRvgg%40mail.gmail.com.
