邮箱验证是现代 Web 应用中最常见的用户引导与身份确认流程之一。传统方案要么通过邮件链接或验证码强制用户切换应用场景，要么依赖社交登录提供商获取已验证邮箱。这些方案要么引入显著的用户体验摩擦，要么泄露使用偏好给邮件服务商，或需要与多家提供商建立集成关系。WICG 正在推进的 Email Verification Protocol (EVP) 尝试在浏览器原生层建立一种更安全、更尊重隐私的验证基础设施，其核心技术采用了选择性披露 JWT 配合密钥绑定的双 Token 架构 (SD‑JWT+KB)。
双重 JWT 架构的密码学基础
EVP 的创新在于将邮箱验证的 “发行 (issuance)” 与 “呈现 (presentation)” 职责通过两个相互关联的 JWT 明确分离。第一个 JWT 是标准的选择性披露 JWT (SD‑JWT)，由邮箱发行者签发，包含 email 与 email_verified 等声明及发行者标识 iss、签发时间 iat 等字段。第二个是密钥绑定 JWT (KB‑JWT)，由浏览器端生成的密钥对签发，其载荷包含目标依赖方 (RP) 的来源 aud、防重放的随机数 nonce、以及对 SD‑JWT 的哈希值 sd_hash。两个 JWT 通过 ~ 字符拼接形成 SD‑JWT+KB 组合，作为最终的呈现令牌。
这种分离带来的安全属性是明确的：发行者仅负责确认用户对邮箱的控制并签发验证声明，它并不直接与具体 Web 应用交互；而浏览器端通过生成密钥对并签发 KB‑JWT，确保只有发起请求的浏览器实例能够将发行者的声明绑定到目标应用。这种职责分离为后续的隐私保护与安全验证奠定了基础。
DNS 委托与发行者授权机制
EVP 在身份授权层面引入了域名系统 (DNS) 的信任锚。当用户选择某个邮箱地址进行验证时，浏览器会查询 _email-verification.<邮箱域名> 的 TXT 记录。该记录必须以 iss= 开头，指定负责该邮箱域的发行者域名。DNS TXT 记录的使用有几个关键好处：其一，只有邮箱域名的实际控制者才能设置该记录，从而建立了 “域名控制权即验证授权” 的可信链条；其二，DNS 作为 Web 基础设施已广泛部署，长尾个人域也无需额外托管 Web 服务即可参与协议。
浏览器随后获取发行者的 .well-known/email-verification 元数据文件，该文件规定发行者的签发端点 (issuance_endpoint) 与公钥发布位置 (jwks_uri)，并可声明支持的签名算法集。所有这些端点的域名必须与发行者域名一致，确保授权边界与协议边界严格对齐。通过 DNS 委托与 .well‑known 元数据的双重校验，EVP 将 “谁能发行邮箱验证” 这一决策权明确地绑定到域名所有者的控制范围内。
浏览器中介与隐私增强
传统邮箱验证流程的一个显著隐私问题是：应用向用户邮箱发送验证码时，邮件服务商能够感知到用户正在使用某个应用及其时间线。EVP 通过让浏览器成为中介来打破这一信息通道。浏览器持有用户的认证 Cookie (在发行者域下)，代表用户向发行者发起请求，并在验证完成后将 SD‑JWT+KB 转发给依赖方。这一中介架构意味着发行者仅知道 “某用户请求了邮箱验证”，但不知道具体是哪一个 Web 应用发起的请求，从而显著减少隐私泄露面。
需要指出的是，协议也坦承几项残余风险：依赖方可以通过 “是否获得 SD‑JWT” 推断用户在发行者处的登录状态；发行者可能首次了解到用户拥有某个它此前不知道的邮箱地址。EVP 的设计选择是在不引入额外复杂性的前提下尽可能降低可避免的泄露，例如将应用的标识从发行者可见的通道中移除。
验证流程中的安全控制点
从安全工程的角度，EVP 的验证流程在多个环节设置了防重放、防篡改与防伪造的控制点。浏览器首先生成新的密钥对，签发请求令牌 (request token)，其中包含自己的公钥 (jwk)、目标发行者 (aud)、时间戳 (iat) 与邮箱地址 (email)。发行者验证该请求令牌的签名与时效 (60 秒窗口)，并确认认证 Cookie 与邮箱控制权匹配后签发 SD‑JWT。SD‑JWT 的载荷通过 cnf 确认声明将浏览器的公钥与发行者签发的邮箱声明绑定。
浏览器在收到 SD‑JWT 后对其进行验证，包括检查发行者身份与 DNS 委托的一致性、签名有效性与时效。随后浏览器签发 KB‑JWT，将 SD‑JWT 的哈希与 RP 的来源及会话随机数绑定。最终依赖方服务端在验证 SD‑JWT+KB 时，需要同时验证 KB‑JWT 对 RP 的针对性与 SD‑JWT 对发行者的可信性，并核对随机数与会话状态。这一系列校验确保了令牌无法被跨应用复用，也无法在时间窗口外被重放。
与现有方案的对比与局限
相较于邮件验证码方案，EVP 的用户体验显著改善：用户在表单中即可完成邮箱验证，无需切换至邮件应用等待与点击链接。相较于社交登录，EVP 不要求应用与多家提供商建立集成关系，也不要求用户共享额外的画像信息。协议还预留了与 Passkey 集成的路径：在用户未登录发行者的场景下，发行者可以返回 WebAuthn 挑战以进行无密码认证。
不过，EVP 的采用也面临现实约束。首先是 DNS 与 .well‑known 端点的部署与维护负担，需要域名所有者配置 TXT 记录并提供可用的元数据与 JWKS 端点。其次，浏览器对请求头 (如 Sec-Fetch-Dest) 与新增事件 (如 emailverified) 的支持与交互细节仍在演化，开发者需要关注规范的推进与兼容性变化。此外，协议目前对 RP 如何从页面获取令牌的具体 API 仍标注为 TBD，意味着前端集成模式尚未完全定稿。
在浏览器身份认证基础设施中的意义
从更宏观的视角看，EVP 代表了一种在浏览器原生层构建 “最小可行身份块” 的努力。它将 “验证邮箱控制权” 这一通用需求从应用自建流程中抽离出来，成为浏览器、域名与发行者共同参与的协议层能力。这种分层有助于减少整个生态的重复实现与安全漏洞面，同时为未来的无密码认证与跨站身份声明打下基础。
DNS 作为信任锚的选择既有历史惯性也有现实优势，它避免了另起炉灶的证书体系复杂性，同时与域名的现有管理流程保持一致。随着规范进一步完善，EVP 有望与 Passkey、WebAuthn 等原生认证机制形成互补，逐步构建起一个更以用户为中心、更尊重隐私、更低摩擦的 Web 身份层。
参考资料
- WICG Email Verification Protocol 规范草案: https://github.com/WICG/email-verification-protocol