LGTM to experiment till M156 On Tue, Aug 18, 2026 at 8:55 PM 'Sam Goto' via blink-dev < [email protected]> wrote:
> > > On Tuesday, May 19, 2026 at 5:02:14 PM UTC-7 Sam Goto wrote: > > *Contact emails* > [email protected] > > *Explainer* > https://github.com/samuelgoto/email-verification-protocol > > *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 > > > Just a small clarification to this thread here (I believe no action is > required by anyone), but we are planning to run our origin trial until 156 > (or the month-equivalent of 156 prior to the 2 week releases), rather than > 153 as stated in this I2E. The > https://chromestatus.com/feature/5205725253074944 entry was always set > to156 and I think I just messed up writing 153 in this thread here (hence > wanted to clarify). > > We are planning to add the Android Clank implementation in 154-156 and > evaluate an I2S from there. > > > > *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/0716dc71-e7e5-42f8-8831-b3dae0118f91n%40chromium.org > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/0716dc71-e7e5-42f8-8831-b3dae0118f91n%40chromium.org?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/CAOmohSJ%3DvmgzX02X_xfCf6ORuig%2B0PcskZVu%3DXczbr%3D91yHRKQ%40mail.gmail.com.
