On Wed, May 20, 2026 at 7:58 AM Yoav Weiss (@Shopify) < [email protected]> wrote:
> LGTM to experiment M150-M153 inclusive (but please merge the explainers to > avoid confusion :D) > Thanks for the quick review!!! > > 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/CAMtUnc4s8KP1woR3TvUY89yC0i-JReEYWmLmuBx4ApqLfaDNXQ%40mail.gmail.com.
