El tedioso "Revisa tu Correo" al registrarse tiene los días contados. Descubre el nuevo Protocolo de Verificación de Email (EVP), un estándar que promete facilitarle la vida a tus usuarios, verificar sus emails sin que tengan que abandonar la página y mejorar su privacidad. Aprende a implementar esta nueva parte del futuro del desarrollo web.
Si hay una experiencia universal en la Web es esa pequeña rutina al registrarse en un nuevo servicio: Escribes tu email y aparece el inevitable mensaje: "Te hemos enviado un correo de verificación". A partir de ahí, comienza el ritual: cambiar a tu cliente de correo, esperar a que llegue el mensaje (que a veces se retrasa o cae en spam) y hacer clic en un enlace o copiar un código para volver a la página original 😫
Este proceso, con mucha fricción, es una de las principales causas de que los usuarios abandonen un registro a la mitad. Pero es necesario, ya que el proveedor del servicio debe verificar que eres quién dices ser, por supuesto.
La principal alternativa hasta ahora han sido los inicios de sesión sociales (los botones de tipo "Inicia sesión con Google/Apple"). Pero no son una solución perfecta. Nos obligan a los desarrolladores a integrar y mantener múltiples servicios de terceros. Y no es sencillo, aunque los frameworks incorporen la parte puramente técnica (por cierto, en campusMVP te dejamos entrar a la plataforma con tus cuentas de Microsoft, Google o GitHub). Además, no es muy granular y, a través del flujo OAuth 2 o bien OpenID Connect, suelen pedir a los usuarios que compartan más información de la estrictamente necesaria solo para confirmar una dirección de email (al menos nombre y apellidos).
Pero, ¿y si pudiéramos verificar un correo electrónico sin recibir un solo email y sin salir de la página en la que estamos?
Esa es la promesa de un nuevo estándar todavía en desarrollo: el Protocolo de Verificación de Email (EVP, por sus siglas en inglés: Email Verification Protocol).
Vamos a verlo...
Visión general del Protocolo de Verificación de Correo Electrónico (EVP)
El Email Verification Protocol (EVP) es un nuevo mecanismo que permite a una página web verificar que un usuario controla una determinada dirección de correo sin enviar un email y sin que el usuario abandone la página. Todo ocurre dentro del navegador, de forma automática y privada.
Nota: este protocolo está definido por el Web Incubator Community Group (WICG), un grupo dentro del Consorcio de la World Wide Web (W3C) que se encarga de incubar nuevas funcionalidades de la plataforma web. El WICG no es un organismo de normalización, sino más bien un foro de discusión e incubación de nuevas ideas que algún día podrían convertirse en estándares web. En este caso el protocolo todavía está en fase de diseño, pero seguramente saldrá adelante a lo largo de 2026. Conviene ir conociéndolo.
El flujo general del protocolo se basa en una delegación de confianza, al igual que ocurre con una autenticación con OpenID Connect) pero que en este caso está intermediada por el propio navegador, que ya tiene acceso a todas nuestras cookies de sesión en cualquier caso. El dominio del correo electrónico delega la responsabilidad de la verificación a una entidad denominada Emisor (Issuer, controlado por el propio servicio de correo y publicada en una entrada DNS).
Cuando un usuario introduce su correo en un formulario, el navegador se comunica directamente con el Emisor, utilizando las cookies de autenticación existentes del usuario con dicho servicio. El Emisor genera un token criptográfico que devuelve al navegador. El navegador, a su vez, lo verifica, lo enriquece con información de la transacción y lo entrega a la aplicación web (Relying Party o RP). Finalmente, la RP puede validar este token para confirmar la autenticidad del correo electrónico.
¿Cómo funciona el protocolo EVP? (versión simplificada)
El proceso es transparente para el usuario. Vamos a verlo a continuación a vista de pájaro para entenderlo bien:
En un apartado un poco más abajo tienes una explicación de los conceptos principales de esta vista de pájaro.
Básicamente los pasos de este flujo son los siguientes:
-
El usuario escribe o selecciona su email: por ejemplo usuario@gmail.com y el navegador detecta el dominio del correo.
-
El navegador busca un registro DNS especial en el dominio: _email-verification.<dominio> TXT iss=<endpoint del emisor>. Ese registro indica qué servicio Emisor (issuer) está autorizado para verificar emails de ese dominio.
-
El navegador pide un token al issuer: genera una clave pública/privada temporal. Crea un request_token (un JWT firmado) que incluye la dirección de email a verificar. Lo envía al Emisor junto con las cookies del usuario para el dominio de correo, para demostrar que está autenticado.
-
El Emisor verifica y emite un SD‑JWT (explicado más abajo): si el usuario realmente controla ese email, el Emisor (tu proveedor de correo) devuelve un token SD‑JWT que contiene los siguientes y campos: email, estado de verificación (email_verified), la clave pública del navegador. Y está firmado por el issuer.
-
El navegador crea el token final de verificación: el navegador verifica el SD‑JWT recibido, crea un segundo token JWT (SD-JWT+KB) vinculado al sitio web actual: incluye el nonce del servidor, y firma un hash del SD‑JWT.
-
La web recibe el token y lo valida: el servidor de la web inicial comprueba el hash, verifica la firma del Emisor, verifica la firma del navegador, confirma que el email está verificado.
Y listo: email verificado sin enviar correos.
⚡Hemos preparado una página interactiva en la que puedes ver este proceso simplificado mucho mejor.
En la documentación oficial del protocolo EVP tienes todos los detalles además de este diagrama de flujo detallado que ya te acabo de describir en esencia:
Implementación de EVP en el lado cliente (HTML de tu app)
Para implementar este tipo de verificación en tu aplicación debes generar un nonce (un valor único aleatorio y atado a la sesión actual) desde el servidor e incluirla en el campo de email:
<input id="email" type="email" autocomplete="email" nonce="1234567890...">
Esto desencadena el proceso de validación en segundo plano que vimos en el apartado anterior. Al terminar el proceso se lanza un evento emailverified que debes gestionar con JavaScript y que recibirá el token final:
<script>
const input = document.getElementById('email')
input.addEventListener('emailverified', e => {
// e.presentationToken is SD-JWT+KB
console.log({
presentationToken: e.presentationToken
})
})
</script>
Se recibe en la propiedad presentationToken del evento y debes enviarlo al servidor para ser validado y poder confirmar, por tanto, que el email es válido.
Aquí hay un depurador para poder probar el proceso.
Inciso: algunos conceptos técnicos sobre EVP
Nota: si ya tienes claros estos conceptos te lo puedes saltar e ir a los siguientes apartados. Pero conviene darle un repaso para tenerlos claros.
Para comprender el funcionamiento anterior del protocolo, es necesario conocer sus dos componentes principales: el formato del token utilizado para transmitir la aserción de verificación y la entidad responsable de emitirlo.
El token SD-JWT+KB
El token SD-JWT+KB (Selective Disclosure JSON Web Token with Key Binding) es el elemento criptográfico central del protocolo. Aunque su nombre completo sugiere capacidades de "divulgación selectiva", para este protocolo se utiliza exclusivamente su característica de vinculación de clave (key binding). Esta propiedad permite una separación segura entre la entidad que emite el token y la que lo presenta, un aspecto clave para la protección de la privacidad en EVP.
Estructuralmente, el token es una cadena de texto compuesta por dos JWTs (JSON Web Tokens) separados por el carácter ~.
| Componente |
Descripción |
| SD-JWT (Token de Emisión) |
Es el primer JWT, también conocido como issuance_token. Es firmado por el Emisor y contiene las afirmaciones (claims) clave, como la dirección de correo del usuario (email), la confirmación de su verificación (email_verified), y el claim de confirmación (cnf) que contiene la clave pública efímera generada por el navegador para esta transacción. |
| KB-JWT (Token de Vinculación) |
Es el segundo JWT, o Key Binding token. Lo firma el navegador utilizando la clave privada efímera correspondiente a la clave pública enviada en el SD-JWT. Contiene el audience (aud) de la aplicación, el nonce de la transacción y un hash del SD-JWT (sd_hash), vinculando criptográficamente ambos tókenes y demostrando que el poseedor de la clave privada es quien presenta el token. |
El token completo, SD-JWT+KB, se denomina presentationToken y es el artefacto final que recibe la aplicación web para su validación.
El rol del issuer (Emisor)
El Emisor es el servicio responsable de realizar la verificación de que un usuario controla una dirección de correo electrónico específica. Su autoridad para actuar en nombre de un dominio de correo se establece de forma explícita y segura:
-
Delegación de Autoridad: la autoridad del Emisor se establece mediante un registro DNS de tipo TXT en el dominio del correo electrónico, como hemos visto. Este registro apunta al identificador del Emisor (p. ej., emisor.dominio.com), demostrando que el propietario del dominio de correo confía en ese Emisor. El uso de un registro DNS TXT para la delegación de autoridad es una elección hecha conciencia que busca que garantizar que se tiene control del dominio, ya que la gestión de DNS está separada de la operativa de los servidores web. Esto evita que un atacante que comprometa el servidor web pueda designarse a sí mismo como un Emisor autorizado.
-
Archivo de Metadatos: El Emisor debe alojar un archivo de metadatos público en /.well-known/email-verification/ en el dominio reflejado en la entrada DNS anterior. Este archivo JSON le da al navegador la información necesaria para poder interactuar con él. Debe contener las siguientes propiedades:
issuance_endpoint: la URL del punto de conexión al que el navegador enviará la solicitud de token.jwks_uri: la URL que apunta al archivo JWKS (JSON Web Key Set), que contiene las claves públicas para verificar la firma del SD-JWT.signing_alg_values_supported (Opcional): un array JSON con los algoritmos de firma JWS soportados. Si se omite, el valor por defecto es EdDSA.
Una regla de seguridad crítica es que cada una de estas propiedades DEBE incluir el dominio del emisor como la raíz de su nombre de host.
Críticas al protocolo de verificación de email (EVP)
El paso que más críticas está recibiendo es el 3 ya que se envían las cookies de tu servicio de correo al Emisor. Pero realmente son críticas infundadas ya que las cookies que se envían ya las tiene el propio servicio de correo si estás autenticado. Y quien las envía es el propio navegador, que también las tiene.
Y si alguien tiene ya acceso a tu navegador (o a tu equipo)... el problema es ese, y no que se envíen las mismas cookies que se envían cuando entras a ver el correo 🤷🏻♂️
Otras críticas que se pueden hacer serían:
- Vulnerabilidad en equipos públicos: las cookies se quedan en un navegador si no cierras la sesión. Esto realmente es un problema con o sin el protocolo EVP. Ahí entra en juego la responsabilidad (y conocimientos) del usuario. De todos modos, se está considerando el uso futuro de Passkeys para permitir verificaciones en ordenadores públicos sin implicar el uso de secretos.
- Depende de tener cookies válidas: si las cookies faltan o caducan, el emisor devuelve un error
401 Unauthorized, lo que obliga al usuario a realizar una autenticación manual y rompe la fluidez del proceso. Pero en ese caso estaríamos igual que ahora, así que tampoco es un grave problema.
- Inferencia del estado de la sesión: el sitio web solicitante (RP) puede deducir si el usuario tiene una sesión activa en el servicio de correo basándose en si recibe o no el token de verificación. Sobre todo si es un servicio conocido que sabe que sí implementa este servicio. Bueno, es cierto, podrían conocer si sueles estar logueado en el email habitualmente, pero no parece algo demasiado grave.
Efecto secundario: tu proveedor de email no sabrá qué webs usas
Esto es algo quizá poco obvio, pero muy interesante. Aparte de la comodidad que le puede dar el protocolo EVP a los usuarios, otro de los beneficios que obtenemos es que mejora en la privacidad del usuario. En el sistema actual de verificación por enlace o código, tu proveedor de correo (Gmail, Outlook, etc.) se entera de cada servicio en el que te registras, ya que es el intermediario que entrega el mensaje. Y si usas un botón de autenticación, pues exactamente lo mismo o peor, porque el servicio que has autorizado queda registrado en el proveedor de correo.
El nuevo protocolo cambia esto ya que el navegador actúa como un mediador seguro entre la página web que solicita la verificación (recuerda, la RP o "relying party") y el servicio que confirma la propiedad del email (el Emisor o "issuer"). Gracias a este diseño, el "issuer" nunca llega a saber qué sitio web específico está pidiendo la verificación.
Alternativas y posible evolución de EVP
EVP es un estándar sin cerrar y, por lo tanto, en plena evolución. Ahora mismo el grupo está explorando otros enfoques adicionales para mejorar su flexibilidad y su seguridad. En concreto:
- API de JavaScript: en lugar de depender de atributos HTML, se está proponiendo una nueva API de JavaScript. La página web podría realizar una llamada explícita pasando la dirección de correo y el
nonce. Esto otorgaría a los desarrolladores mayor flexibilidad para gestionar la recopilación del correo aunque, en mi opinión, podría abrir otros frentes para vulnerar la privacidad, haciendo sondeos para ver en qué tipos de cuenta de correo estás logueado permanentemente.
- Autenticación con Passkeys: como alternativa mucho más interesante al uso de cookies para la autenticación con el Emisor, se está viendo la posibilidad de usar WebAuthN (Passkeys). Si el Emisor detecta que no hay una sesión activa, podría devolver una solicitud de este protocolo. El usuario podría autenticarse con su passkey en el móvil, permitiendo el uso del protocolo en ordenadores públicos sin introducir secretos o dejar una sesión abierta.
Conclusión: ¿el futuro de la verificación de email?
El protocolo de verificación de email EVP intenta poner fin a una de los mayores fastidios de la web, buscando mejorar la experiencia del usuario (UX) para que sea más rápida, más privada y mucho más sencilla.
EVP ofrece un buen equilibrio entre esos tres componentes: usabilidad, seguridad y privacidad, y beneficia tanto a los desarrolladores de aplicaciones web (a los que nos interesa simplificar las altas de nuevos usuarios), como a los propios usuarios ( que verán un proceso más rápido, sencillo y privado).
Veremos cómo evoluciona y cómo incorporarlo a nuestras aplicaciones.