传统邮箱验证的痛点与 EVP 的革命性方案
在当今的 Web 应用中，邮箱验证几乎是用户注册和身份确认的标准流程。然而，传统的邮箱验证方式存在显著的体验和隐私问题：用户需要在应用和邮箱之间频繁切换，等待验证邮件到达，并点击链接或输入验证码完成验证。这种多步骤流程不仅增加了用户的认知负担，还导致了显著的转化率下降。更重要的是，邮件传输过程会向邮件服务提供商泄露用户正在使用的应用信息和使用时间，构成了潜在的隐私风险。
WICG（Web 社区小组）推出的邮箱验证协议（Email Verification Protocol, EVP）正是为了解决这些痛点而设计的创新解决方案。EVP 协议的核心目标是在不发送邮件、不要求用户离开当前页面的情况下，让 Web 应用获得用户已验证的邮箱地址，同时通过浏览器中介机制保护用户隐私。
技术架构解析：SD-JWT+KB 双令牌机制
EVP 协议的技术基础是选择性披露 JWT 与密钥绑定（SD-JWT+KB）的组合设计。这种设计巧妙地将令牌发行和令牌呈现分离，通过双 JWT 结构实现了强大的安全保证。
双 JWT 结构设计
SD-JWT+KB 令牌由两个通过 "~" 字符分隔的 JWT 组成：
- 第一个 JWT（SD-JWT）：由发行商签名的发行令牌，包含用户的邮箱和验证状态声明
- 第二个 JWT（KB-JWT）：由浏览器签名的密钥绑定令牌，包含对第一个 JWT 的哈希引用
这种设计的关键在于，浏览器生成独立的密钥对来完成密钥绑定，而发行商只能验证邮箱所有权，无法获知具体是哪个依赖方（Relying Party）在请求验证。
浏览器中介的隐私保护
EVP 协议的创新之处在于浏览器的角色设计。浏览器不仅是请求的发起者，更是隐私保护的关键环节：
- 请求中介：浏览器代表用户向发行商发起请求，发行商只知道有验证请求，但不知道具体的 Web 应用
- 令牌验证：浏览器验证 SD-JWT 的有效性，包括签名验证、时效性检查和 DNS 授权确认
- 密钥绑定：浏览器使用生成的密钥对创建 KB-JWT，确保令牌与特定设备和会话绑定
发行商授权与 DNS 委派机制
EVP 协议通过 DNS TXT 记录实现邮箱域向发行商的授权委派，这是整个安全模型的基础：
DNS 授权记录格式
_email-verification.$EMAIL_DOMAIN TXT "iss=issuer.example"
这种设计具有以下安全优势：
- 域级控制：只有控制邮箱域的实体才能设置相关 DNS 记录
- 防冒名顶替：防止恶意实体冒充发行商进行邮箱验证
- 灵活委派：允许邮箱服务提供商将验证功能委派给专门的发行商
发行商元数据配置
发行商必须提供标准的.well-known/email-verification配置文件，包含：
issuance_endpoint：浏览器调用获取发行令牌的 API 端点jwks_uri：发行商公钥信息的获取地址signing_alg_values_supported：支持的签名算法列表
六步验证流程的工程实现
EVP 协议的验证流程设计严谨，每个步骤都有明确的安全检查点：
第一步：邮箱请求
用户访问需要验证邮箱的 Web 应用，服务器生成与用户会话绑定的 nonce，并返回包含autocomplete="email"属性的输入框。
第二步：邮箱选择
用户聚焦邮箱输入框时，浏览器显示可用的邮箱列表供用户选择。这个过程利用了浏览器的自动填充功能，同时为 EVP 验证做准备。
第三步：令牌请求
浏览器解析邮箱域名，查询 DNS TXT 记录确定发行商，然后：
- 获取发行商元数据
- 生成新的密钥对
- 创建包含公钥的请求令牌
- 向发行商发送验证请求
第四步：令牌发行
发行商验证请求的有效性：
- 检查请求头（Content-Type、Sec-Fetch-Dest）
- 验证请求令牌的签名和声明
- 确认用户已登录且控制指定邮箱
- 生成包含邮箱验证状态的 SD-JWT
第五步：令牌呈现
浏览器验证发行令牌后创建密钥绑定：
- 验证 SD-JWT 的签名和时效性
- 创建 KB-JWT，包含对 SD-JWT 的哈希引用
- 将 SD-JWT+KB 组合令牌返回给 Web 应用
第六步：令牌验证
Web 应用服务器执行最终验证：
- 分离并验证两个 JWT 组件
- 检查 nonce 与会话绑定
- 验证 DNS 授权和发行商公钥
- 确认邮箱验证状态
WebAuthn 生态集成与 Passkey 支持
EVP 协议与 WebAuthn 生态的集成为邮箱验证带来了革命性的改进。通过结合 Passkey 技术，协议能够支持更广泛的场景：
跨设备验证能力
传统邮箱验证的一个局限是用户在公共计算机上难以安全验证。EVP 协议与 Passkey 的结合解决了这个问题：
- 设备绑定验证：用户可以使用个人设备上的 Passkey 进行身份验证
- 生物识别安全：结合指纹、人脸识别等生物认证方式
- 漫游认证器支持：支持外部安全密钥进行高安全级别验证
隐私增强的公共场景
在网吧、图书馆等公共计算机上，用户无需输入任何敏感信息，仅通过 Passkey 认证即可完成邮箱验证。这种设计：
- 消除了键盘记录器风险
- 避免了密码在不可信设备上的输入
- 提供了与本地设备相同的安全级别
工程实践中的关键考虑因素
错误处理与用户体验
EVP 协议定义了详细的错误处理机制，包括：
- 认证失败：用户未登录或邮箱控制权验证失败
- 无效令牌：请求令牌格式错误或签名验证失败
- 服务器错误：发行商服务暂时不可用
Web 应用需要优雅处理这些错误情况，提供适当的用户反馈和降级方案。
安全配置最佳实践
- 签名算法选择：推荐使用 EdDSA 算法，如需兼容可支持 RS256
- DNS 记录保护：确保 DNS 记录的安全性和防篡改性
- 会话管理：nonce 与用户会话的严格绑定
- 缓存策略：合理配置元数据和公钥的缓存时间
浏览器兼容性准备
虽然 EVP 协议处于早期阶段，但 Web 应用可以提前准备：
- 实现渐进式增强，EVP 失败时回退到传统验证
- 与浏览器厂商保持同步，关注实现进展
- 建立测试环境，验证协议交互的正确性
隐私保护的设计哲学
EVP 协议的隐私保护设计体现了现代 Web 安全的重要原则：
最小化信息披露
通过浏览器中介机制，发行商只能获得验证请求的必要信息，无法获知具体的 Web 应用，这对于邮箱服务提供商保护用户隐私具有重要意义。
用户控制权增强
用户在整个过程中保持对邮箱使用的完全控制，可以在任何时候撤销授权或更换验证方式。
跨域安全边界
协议严格维护不同域之间的安全边界，防止信息泄露和跨域攻击。
未来发展与生态影响
EVP 协议代表了 Web 身份验证发展的重要方向。随着 WebAuthn 生态的成熟和 Passkey 的普及，这种基于公钥密码学的邮箱验证方式将成为标准配置：
标准化进程
WICG 正在推动 EVP 协议的标准化，预计将与其他 Web 身份验证标准形成完整的生态系统。
广泛应用前景
从企业级应用到消费级服务，EVP 协议为各种需要邮箱验证的场景提供了更安全、更友好的解决方案。
技术演进方向
协议可能扩展支持更多身份属性验证，如电话号码、地址信息等，构建更完整的数字身份验证体系。
结论
WICG 邮箱验证协议通过 SD-JWT+KB 的双令牌设计和 WebAuthn 生态集成，实现了邮箱验证的革命性改进。它不仅消除了传统验证方式的体验摩擦，更重要的是通过浏览器中介机制保护了用户隐私。协议的设计充分体现了现代 Web 安全的原则，为构建更安全、更私密的 Web 生态系统奠定了基础。
随着浏览器支持逐步完善和生态系统发展，EVP 协议有望成为邮箱验证的新标准，推动整个 Web 身份验证领域向更安全、更用户友好的方向发展。对于 Web 开发者和安全从业者来说，深入理解这一协议的技术细节和实现原理，将有助于构建更好的身份验证体验。