Email Verification API 全链路解析从输入邮箱到服务端验证成功的 9 步自动流程【免费下载链接】email-verificationverified autofill项目地址: https://gitcode.com/GitHub_Trending/em/email-verificationEmail Verification API邮箱验证协议 EVP是一个让浏览器在用户输入邮箱后无缝完成所有权验证的 W3C 提案它不再发送一次性验证码或魔法链接而是由浏览器向邮箱服务商请求一个带数字签名的Email Verification TokenEVT邮箱验证令牌随表单提交到网站服务端自动完成验证。下面带你走完整条首次提交链路理解这 9 步背后发生了什么。为什么需要 Email Verification API先看清旧方案的痛点传统邮箱验证靠发送-查收-回填对比项传统 OTP / 魔法链接Email Verification APIEVT验证凭证随机验证码 / 链接服务商签名的加密令牌用户操作切到邮箱 → 找邮件 → 复制粘贴选邮箱 → 点允许 → 提交抗钓鱼能力弱验证码可被诱导泄露强令牌绑定网站域名与 nonce依赖邮件投递是可能进垃圾箱、延迟否数据显示访问最多的 50 个网站中 95% 支持邮箱注册73% 会在验证邮箱之前卡住注册流程——而这套新流程能显著减少转化漏斗中的流失。完整的提案背景见 README.md。角色速览一次验证里的三个玩家EVP 采用三方模型浏览器是中间人验证方Verifier你的网站负责发起验证请求并最终校验令牌️浏览器User Agent发现服务商、检查登录态、代用户申请令牌签发方Issuer邮箱服务商如邮箱厂商对用户邮箱有权威负责签发令牌协议全景与示例流程定义在 index.bs 中。全链路 9 步从输入邮箱到验证成功整个流程分为三个阶段。先记住一条主线网站埋点 → 浏览器跑腿 → 服务端验票。阶段一前置准备用户无感知第 1 步登录邮箱服务商。用户提前在浏览器或原生应用中登录邮箱后服务商通过 Login Status API 把状态置为已登录浏览器会记下这个状态。这一步发生在任何网站访问之前见 README.md。第 2 步网站表单埋点。网站在注册表单里除普通邮箱输入框外多一个隐藏字段autocompleteemail-verification-token外加服务端动态生成的nonce一次性随机码防重放攻击。只需一行 HTML老表单也能渐进增强input typeemail nameemail autocompleteemail input typehidden nametoken nonce服务器生成的随机值 autocompleteemail-verification-token规范原文见 index.bsnonce 的作用见 index.bs。阶段二浏览器后台静默执行用户选完邮箱即触发第 3 步观察邮箱选择。用户从自动填充列表选中或手动输入邮箱后浏览器识别出同表单中的那个隐藏字段开始验证流程。第 4 步DNS 发现签发方。浏览器查询_email-verification.邮箱域名的 DNS TXT 记录如ississuer.example找到该邮箱域名的权威签发方——签发方可以与邮箱域同名也可以委托给专门的账户服务域名。第 5 步账号匹配校验。浏览器确认用户确实登录着该签发方再拉取其.well-known/web-identity文件中的账号列表逐一忽略大小写比对选中的邮箱必须真实存在于该登录会话中否则流程静默终止回退到传统验证。具体算法见 index.bs。第 6 步权限弹窗用户拍板。浏览器弹出类似是否向 rp.example 共享 userexample.com 的已验证令牌[允许] [拒绝]的提示。点允许浏览器向签发方请求令牌生成一次性密钥对、构造含邮箱地址的签名请求携带第一方 Cookie签发方核实会话后返回 SD-JWT 格式的 EVT。细节见 README.md。第 7 步KB 绑定令牌盖章。浏览器把令牌与网站来源 nonce绑定成 Key-Bound JWTKB-JWT。这一步让令牌变成一次性门票换个网站、换个表单、过期统统无效。第 8 步提交时自动填充。浏览器等待表单提交在onsubmit触发前把绑定后的令牌写入隐藏字段随表单一起 POST 出去——用户全程没有多按任何按钮。处理模型见 index.bs。阶段三服务端验证成功第 9 步服务端五连校验。网站收到email和evt两个字段后依次验证签名合法由该邮箱域名的签发方签发audience等于自己的来源域名nonce与当初表单里下发的值一致令牌未过期exp令牌中的邮箱与提交的email忽略大小写相等全部通过 → 验证成功无需再发一封验证邮件。校验流程见 index.bs。快速上手如何在 Chrome 里实测这条链路项目自带一份测试手册 HOWTO.md核心步骤安装 Chrome Canary 版本在chrome://flags/搜索Email Verification Protocol启用#email-verification-protocol并重启确认chrome://version版本 ≥ 145在chrome://settings/addresses确认已添加一个支持 EVP 的域名邮箱确认你已登录该邮箱然后访问一个已支持 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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Email Verification API 全链路解析：从输入邮箱到服务端验证成功的 9 步自动流程
Email Verification API 全链路解析从输入邮箱到服务端验证成功的 9 步自动流程【免费下载链接】email-verificationverified autofill项目地址: https://gitcode.com/GitHub_Trending/em/email-verificationEmail Verification API邮箱验证协议 EVP是一个让浏览器在用户输入邮箱后无缝完成所有权验证的 W3C 提案它不再发送一次性验证码或魔法链接而是由浏览器向邮箱服务商请求一个带数字签名的Email Verification TokenEVT邮箱验证令牌随表单提交到网站服务端自动完成验证。下面带你走完整条首次提交链路理解这 9 步背后发生了什么。为什么需要 Email Verification API先看清旧方案的痛点传统邮箱验证靠发送-查收-回填对比项传统 OTP / 魔法链接Email Verification APIEVT验证凭证随机验证码 / 链接服务商签名的加密令牌用户操作切到邮箱 → 找邮件 → 复制粘贴选邮箱 → 点允许 → 提交抗钓鱼能力弱验证码可被诱导泄露强令牌绑定网站域名与 nonce依赖邮件投递是可能进垃圾箱、延迟否数据显示访问最多的 50 个网站中 95% 支持邮箱注册73% 会在验证邮箱之前卡住注册流程——而这套新流程能显著减少转化漏斗中的流失。完整的提案背景见 README.md。角色速览一次验证里的三个玩家EVP 采用三方模型浏览器是中间人验证方Verifier你的网站负责发起验证请求并最终校验令牌️浏览器User Agent发现服务商、检查登录态、代用户申请令牌签发方Issuer邮箱服务商如邮箱厂商对用户邮箱有权威负责签发令牌协议全景与示例流程定义在 index.bs 中。全链路 9 步从输入邮箱到验证成功整个流程分为三个阶段。先记住一条主线网站埋点 → 浏览器跑腿 → 服务端验票。阶段一前置准备用户无感知第 1 步登录邮箱服务商。用户提前在浏览器或原生应用中登录邮箱后服务商通过 Login Status API 把状态置为已登录浏览器会记下这个状态。这一步发生在任何网站访问之前见 README.md。第 2 步网站表单埋点。网站在注册表单里除普通邮箱输入框外多一个隐藏字段autocompleteemail-verification-token外加服务端动态生成的nonce一次性随机码防重放攻击。只需一行 HTML老表单也能渐进增强input typeemail nameemail autocompleteemail input typehidden nametoken nonce服务器生成的随机值 autocompleteemail-verification-token规范原文见 index.bsnonce 的作用见 index.bs。阶段二浏览器后台静默执行用户选完邮箱即触发第 3 步观察邮箱选择。用户从自动填充列表选中或手动输入邮箱后浏览器识别出同表单中的那个隐藏字段开始验证流程。第 4 步DNS 发现签发方。浏览器查询_email-verification.邮箱域名的 DNS TXT 记录如ississuer.example找到该邮箱域名的权威签发方——签发方可以与邮箱域同名也可以委托给专门的账户服务域名。第 5 步账号匹配校验。浏览器确认用户确实登录着该签发方再拉取其.well-known/web-identity文件中的账号列表逐一忽略大小写比对选中的邮箱必须真实存在于该登录会话中否则流程静默终止回退到传统验证。具体算法见 index.bs。第 6 步权限弹窗用户拍板。浏览器弹出类似是否向 rp.example 共享 userexample.com 的已验证令牌[允许] [拒绝]的提示。点允许浏览器向签发方请求令牌生成一次性密钥对、构造含邮箱地址的签名请求携带第一方 Cookie签发方核实会话后返回 SD-JWT 格式的 EVT。细节见 README.md。第 7 步KB 绑定令牌盖章。浏览器把令牌与网站来源 nonce绑定成 Key-Bound JWTKB-JWT。这一步让令牌变成一次性门票换个网站、换个表单、过期统统无效。第 8 步提交时自动填充。浏览器等待表单提交在onsubmit触发前把绑定后的令牌写入隐藏字段随表单一起 POST 出去——用户全程没有多按任何按钮。处理模型见 index.bs。阶段三服务端验证成功第 9 步服务端五连校验。网站收到email和evt两个字段后依次验证签名合法由该邮箱域名的签发方签发audience等于自己的来源域名nonce与当初表单里下发的值一致令牌未过期exp令牌中的邮箱与提交的email忽略大小写相等全部通过 → 验证成功无需再发一封验证邮件。校验流程见 index.bs。快速上手如何在 Chrome 里实测这条链路项目自带一份测试手册 HOWTO.md核心步骤安装 Chrome Canary 版本在chrome://flags/搜索Email Verification Protocol启用#email-verification-protocol并重启确认chrome://version版本 ≥ 145在chrome://settings/addresses确认已添加一个支持 EVP 的域名邮箱确认你已登录该邮箱然后访问一个已支持 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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考