The Future of Login: Replacing OTPs with Browser-Mediated Email Verification


The Future of Login: Replacing OTPs with Browser-Mediated Email Verification

WICG/email-verification-protocol

2025-11-16

The WICG/email-verification-protocol is a proposed web standard by the Web Platform Incubator Community Group (WICG). Its main goal is to allow a web application to get a verified email address from a user without sending a traditional verification email or forcing the user to leave the current webpage.

As developers, we currently deal with friction in two main ways when we need a verified email

Traditional Email Verification (The Pain Point)

Poor User Experience (UX)
Users have to switch to their email app, wait for the email, click a link or copy a code, and then switch back. This high friction often leads to user drop-off during signup or critical flows.

Development Overhead
We have to build and maintain email sending infrastructure, handle deliverability issues, manage secure tokens, and track confirmation status.

Privacy Concerns
The email service learns which applications the user is using and when.

Social Logins (The Alternative)

We must integrate with multiple third-party providers (Google, Apple, etc.).

The user is often required to share more profile information than just the email.

The user must already be using one of the supported social services.

The Email Verification Protocol eliminates this friction, offering

Improved Conversion Rates
A much faster, on-page experience reduces user drop-off.

Reduced Development Complexity
Less need for custom email verification logic and infrastructure.

Enhanced User Privacy
The request for verification is mediated by the browser, which can limit the information shared with the email issuer.

"Verified autofill" is the user-facing mechanism enabled by this protocol. Instead of the site sending an email, the process is handled by the browser and a trusted Issuer (often the user's mail provider).

User Interaction
The user focuses on an email input field on your website.

Browser Mediation
The browser checks if it has a stored, verified email address for the user from a past interaction with an Issuer.

User Selection
The browser presents the user with a list of their verified emails to choose from in a standard autofill dialog.

Token Exchange
Once the user selects an email, the browser internally contacts the Issuer to get a cryptographically secure token (like an SD-JWT) proving the user controls that email.

Token Presentation
The browser then populates your email input field with the selected email address AND provides the verification token to your application.

Server-Side Verification
Your backend receives the email and the token. Your application must then verify the token with the Issuer to confirm its validity and that the email is genuinely verified.

The core change for a developer is primarily in the HTML form and how your backend validates the data.

To enable this feature, the HTML input field for the email address needs the standard autocomplete attribute set to email, and possibly a new protocol-specific attribute (which is still being finalized in the WICG proposal, but is often discussed as verified-autofill).

Example HTML

<form id="signup-form">
  <label for="email">Email Address</label>
  <input type="email" 
         id="email" 
         name="email" 
         autocomplete="email" 
         required>
  
  <button type="submit">Sign Up</button>
</form>

When a compliant browser detects this field, it will manage the flow. The key is that the browser injects the verified email and token into the submission. The details of how the token is injected (e.g., a hidden field, a special API call) are part of the ongoing specification work. For now, just ensure your autocomplete="email" is correct.

This is the most critical part. When your server receives the form submission, it will get the email address and a verification token. You must validate this token before trusting the email.

Conceptual Backend Steps (e.g., using Node.js/Express)

// Pseudocode for an Express.js route handler

app.post('/register', async (req, res) => {
  const { email, verificationToken } = req.body; 

  if (!email || !verificationToken) {
    return res.status(400).send('Missing email or verification token.');
  }

  try {
    // 1. You would determine the Issuer's public key or endpoint based on the email domain (e.g., using DNS records).
    const issuerEndpoint = getIssuerEndpoint(email); 
    
    // 2. The key step: Verify the SD-JWT token. 
    // This involves a request to the Issuer to ensure the token is:
    // a) Signed correctly by the Issuer.
    // b) Valid (not expired, not revoked).
    // c) Bound to the correct user (Key Binding).
    // d) Contains the correct 'email' claim matching the submitted email.

    const isTokenValid = await verifyTokenWithIssuer(verificationToken, issuerEndpoint);

    if (isTokenValid) {
      // 3. Success! The email is verified and safe to use.
      console.log(`Successfully verified email: ${email}`);
      await createUser(email); 
      return res.status(201).send('User registered with a verified email!');
    } else {
      // Token verification failed.
      return res.status(401).send('Invalid email verification token.');
    }

  } catch (error) {
    console.error('Verification error:', error);
    return res.status(500).send('Internal server error during verification.');
  }
});

The specific libraries and APIs for handling the SD-JWT (Selective Disclosure JSON Web Token) token are still emerging, but this backend verification step is the fundamental requirement for adopting the protocol.

The following video discusses the WICG's Email Verification Protocol and how it uses verified autofill to improve the process of getting a verified email address.


WICG/email-verification-protocol