企业官网建设流程全解析

Email Verification API 全链路解析：从输入邮箱到服务端验证成功的 9 步自动流程

【免费下载链接】email-verificationverified autofill项目地址: https://gitcode.com/GitHub_Trending/em/email-verification

Email Verification API（邮箱验证协议 EVP）是一个让浏览器在用户输入邮箱后"无缝"完成所有权验证的 W3C 提案：它不再发送一次性验证码或魔法链接，而是由浏览器向邮箱服务商请求一个带数字签名的Email Verification Token（EVT，邮箱验证令牌），随表单提交到网站服务端自动完成验证。下面带你走完整条首次提交链路，理解这 9 步背后发生了什么。

为什么需要 Email Verification API？先看清旧方案的痛点

传统邮箱验证靠"发送-查收-回填"：

数据显示，访问最多的 50 个网站中 95% 支持邮箱注册，73% 会在验证邮箱之前卡住注册流程——而这套新流程能显著减少转化漏斗中的流失。完整的提案背景见 README.md。

角色速览：一次验证里的三个玩家

EVP 采用三方模型，浏览器是中间人：

• 🌐验证方（Verifier）：你的网站，负责发起验证请求并最终校验令牌
• 🖥️浏览器（User Agent）：发现服务商、检查登录态、代用户申请令牌
• 📮签发方（Issuer）：邮箱服务商（如邮箱厂商），对用户邮箱有权威，负责签发令牌

协议全景与示例流程定义在 index.bs 中。

全链路 9 步：从输入邮箱到验证成功

整个流程分为三个阶段。先记住一条主线：网站埋点 → 浏览器跑腿 → 服务端验票。

阶段一：前置准备（用户无感知）

第 1 步：登录邮箱服务商。用户提前在浏览器（或原生应用）中登录邮箱后，服务商通过 Login Status API 把状态置为"已登录"，浏览器会记下这个状态。这一步发生在任何网站访问之前，见 README.md。

第 2 步：网站表单"埋点"。网站在注册表单里除普通邮箱输入框外，多一个隐藏字段：autocomplete="email-verification-token"，外加服务端动态生成的nonce（一次性随机码，防重放攻击）。只需一行 HTML，老表单也能渐进增强：

<input type="email" name="email" autocomplete="email"> <input type="hidden" name="token" nonce="服务器生成的随机值" autocomplete="email-verification-token">

规范原文见 index.bs，nonce 的作用见 index.bs。

阶段二：浏览器后台静默执行（用户选完邮箱即触发）

第 3 步：观察邮箱选择。用户从自动填充列表选中（或手动输入）邮箱后，浏览器识别出同表单中的那个隐藏字段，开始验证流程。

第 4 步：DNS 发现签发方。浏览器查询_email-verification.<邮箱域名>的 DNS TXT 记录（如iss=issuer.example），找到该邮箱域名的权威签发方——签发方可以与邮箱域同名，也可以委托给专门的账户服务域名。

第 5 步：账号匹配校验。浏览器确认用户确实登录着该签发方，再拉取其.well-known/web-identity文件中的账号列表，逐一（忽略大小写）比对：选中的邮箱必须真实存在于该登录会话中，否则流程静默终止，回退到传统验证。具体算法见 index.bs。

第 6 步：权限弹窗，用户拍板。浏览器弹出类似"是否向 rp.example 共享 user@example.com 的已验证令牌？[允许] [拒绝]"的提示。点"允许"，浏览器向签发方请求令牌：生成一次性密钥对、构造含邮箱地址的签名请求（携带第一方 Cookie），签发方核实会话后返回 SD-JWT 格式的 EVT。细节见 README.md。

第 7 步：KB 绑定，令牌"盖章"。浏览器把令牌与网站来源 + nonce绑定成 Key-Bound JWT（KB-JWT）。这一步让令牌变成"一次性门票"：换个网站、换个表单、过期，统统无效。

第 8 步：提交时自动填充。浏览器等待表单提交，在onsubmit触发前把绑定后的令牌写入隐藏字段，随表单一起 POST 出去——用户全程没有多按任何按钮。处理模型见 index.bs。

阶段三：服务端验证成功

第 9 步：服务端五连校验。网站收到email和evt两个字段后依次验证：

1. 签名合法（由该邮箱域名的签发方签发）
2. audience等于自己的来源域名
3. nonce与当初表单里下发的值一致
4. 令牌未过期（exp）
5. 令牌中的邮箱与提交的email忽略大小写相等

全部通过 → 验证成功，无需再发一封验证邮件。校验流程见 index.bs。

快速上手：如何在 Chrome 里实测这条链路

项目自带一份测试手册 HOWTO.md，核心步骤：

1. 安装 Chrome Canary 版本
2. 在chrome://flags/搜索Email Verification Protocol，启用#email-verification-protocol并重启
3. 确认chrome://version版本 ≥ 145
4. 在chrome://settings/addresses确认已添加一个支持 EVP 的域名邮箱
5. 确认你已登录该邮箱

然后访问一个已支持 EVP 的示例页面，选中邮箱、允许弹窗、提交表单，即可观察到整条链路自动跑通。若要接入自己的网站：给邮箱输入框加 nonce、加一个隐藏字段，最后在表单处理器中校验presentationToken，两步完成，见 HOWTO.md。

为什么这套 Email Verification API 值得持续关注？

• 🔒更抗钓鱼：EVT 绑定了网站域名、nonce 与有效期，被截获的令牌无法重放到其他站点，见 index.bs
• 🕶️保护用户隐私：签发请求刻意隐藏了验证方的来源信息（blinding 设计），邮箱服务商不知道你在注册哪个网站，见 index.bs
• 🧩优雅降级：任何环节失败（未登录、DNS 无记录、用户拒绝），表单照常提交，网站回退到发送验证码的老路，用户行为零改变
• 📈渐进部署：网站一行隐藏字段即可接入，不依赖所有浏览器或所有邮箱服务商同时支持，提案的激活策略分析见 README.md

当然，它也有边界：验证的是"用户登录着该邮箱"，而非"邮件确实送达了收件箱"；邮箱域名也可能易主。这些安全权衡在 README.md 中有坦诚说明，隐私自审清单见 QUESTIONNAIRE.md。

一句话总结：Email Verification API 把"抄验证码"变成了"浏览器代跑一趟"——你在输入框里选中邮箱的那一刻，验证的接力棒就已悄悄交出，最终由服务端在表单提交瞬间完成签收。

【免费下载链接】email-verificationverified autofill项目地址: https://gitcode.com/GitHub_Trending/em/email-verification