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/CAMtUnc6vV0agZPeYexDGm%2BmumCj0w1ofRD49M%2BpvP75YT0hsMA%40mail.gmail.com.
