Chrome is testing an email verification protocol with no emails and no one-time codes

The Chrome for Developers team has announced the start of an open trial (origin trial) for the new Email Verification API. The idea is to spare users the familiar ritual of confirming their email, when after signing up or logging in they have to leave the page for their inbox to fetch a one-time code or a “magic link.” The authors of the proposal point out that this break in the flow is exactly the moment when a person (or, increasingly often, an automated agent) tends to simply abandon what they started.

How it works

Instead of an email, the browser negotiates directly with the email provider. The user picks an address from an autofill suggestion and submits the form, and the site receives proof of ownership — without a single email being sent.

The scheme has three roles: the verifier — the site that needs to check the address (also known as the relying party); the email provider — the service that hosts the address itself, for example gmail.com; and the issuer — the service that manages the account (accounts.google.com). One requirement is mandatory: the user must be signed in with their provider in the same browser profile.

Once an address is selected, the browser requests the _email-verification DNS record for the email domain — it points to the issuer. The issuer confirms the active session and issues a verification token (EVT). The browser wraps it in a key-bound signed JWT, adding the site's origin and a one-time nonce from a hidden form field. When the form is submitted, the site receives the package and verifies five components: the email, the nonce, the key binding, the DNS record and the issuer's signature. The first time a specific address is confirmed, the user sees a permission prompt once.

Gradual rollout

The mechanism is designed as a progressive enhancement. The hidden token field is only processed when a token is present, so feature detection isn't needed: if there is no token or the check fails, the site falls back to sending a regular email. Technically it all rests on already familiar building blocks — DNS TXT records, .well-known endpoints, FedCM and the Login Status API — and the tokens are formatted as SD-JWTs.

An important caveat: the protocol only confirms that the user has an active session with the provider, but does not guarantee that an email will actually reach them. So welcome and onboarding emails aren't going anywhere.

Google stresses that this is an experiment with traffic limits and backward-incompatible changes ahead, and it is looking for feedback from sites, email providers and users through its repositories on GitHub.

Source: Lobsters