On Wed, May 20, 2026 at 8:00 AM Yoav Weiss (@Shopify) < [email protected]> wrote:
> Oh, and can you also ask for a debuggability review? > Done > > On Wed, May 20, 2026 at 4:58 PM Yoav Weiss (@Shopify) < > [email protected]> wrote: > >> LGTM to experiment M150-M153 inclusive (but please merge the explainers >> to avoid confusion :D) >> > Will do. > >> 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/CAMtUnc6ZjOCyrfmghXD1h2WiwT%2BzuntCzj7VHVTWH_07Pvp2kQ%40mail.gmail.com.
