Email Verification API 终极指南：SD-JWT 双方签名校验链，一次看懂如何验证 issuer 签发的邮件验证令牌

Email Verification API 终极指南SD-JWT 双方签名校验链一次看懂如何验证 issuer 签发的邮件验证令牌【免费下载链接】email-verificationverified autofill项目地址: https://gitcode.com/GitHub_Trending/em/email-verification什么是 Email Verification API为什么还需要验证邮箱所有权Email Verification API是 W3C WICG 正在推进的一项浏览器 API 提案README.md。它的核心能力是让网站在不发送 OTP 验证码、不发送魔法链接的前提下用加密签名的邮件验证令牌EVT来验证用户邮箱的所有权。理解它的关键在于一条双方签名校验链第一重签名issuer邮件服务商用私钥签发一枚SD-JWTSelective Disclosure for JSON Web TokensRFC 9682证明用户确实在我这里登录了第二重签名浏览器浏览器用临时密钥把令牌绑定到网站来源origin和服务端 nonce生成KB-JWT证明这枚令牌只属于这次提交。网站verifier必须把这两重签名都校验通过才能认定邮箱验证成功——这就是本文要讲透的SD-JWT 校验链。协议速览三个角色与完整流程整个协议涉及三方index.bs Protocol Overview角色英文职责网站Verifier发起验证请求最终校验双方签名浏览器User Agent中介发现 issuer、请求令牌、生成 KB-JWT邮件服务商Issuer签发 SD-JWT 格式的 EVT流程全景图来自 README.mdStep Website Browser Issuer 1.1 Login Status | |---- logged-in ----| 2.1 EVT Request |------ nonce ------| | 3.1 Email Selection | [用户选择邮箱] | 3.2 Issuer Discovery | [DNS TXT 发现 issuer] | 3.3 Accounts Request | |---- accounts -----| 3.4 Permission | [用户授权] | 3.5 EVT Issuance | |------ EVT --------| 3.6 KB Creation | [Create KB-JWT] | 3.7 EVT Verification | [Verify EVTKB] | 3.9 EVT Presentation |----- EVTKB ------| | 4.1 EVT Verification [Verify EVTKB] | |对新手最直观的一句话用户只要在邮箱输入框里选中一个邮箱浏览器就会在背后自动完成发现 → 签发 → 绑定 → 校验并在表单提交时把令牌填进隐藏字段。第一重签名issuer 如何签发 SD-JWTEVT Issuance签发环节是整个校验链的起点规范见 index.bs 的EVT Issuance算法。它采用临时密钥对 cnf 声明的设计非常优雅生成临时密钥对浏览器创建一对一次性ephemeral非对称密钥默认算法为Ed25519可由 issuer 元数据指定其他算法。构造 request_token这是一个签名的 JWT——头部headeralg 临时公钥jwk载荷payloadaudissuer 标识、iat签发时间、email用户选中的邮箱用临时私钥签名。POST 到 issuer 的 issuance endpoint以application/x-www-form-urlencoded发送携带 issuer 的一级 Cookie请求头Sec-Fetch-Dest: email-verification。issuer 返回 SD-JWT响应体 JSON 中的issuance_token就是一枚用 issuer 私钥签名的 SD-JWT末尾追加~分隔符响应示例见 README.md。 为什么用 SD-JWT 而不是普通 JWT因为 SD-JWT 支持选择性披露未来 issuer 可以只展示令牌中你同意的声明把隐私保护做进协议层。关键设计issuer 会把浏览器第 1 步的临时公钥写进 SD-JWT 的cnfconfirmation声明。这一步就是握手——浏览器稍后能用它确认这枚令牌确实是为我这次请求签发的防止令牌被调包。第二重签名浏览器生成 KB-JWT 绑定 nonce 与来源拿到 EVT 后浏览器不会直接交给网站而是先做密钥绑定Key Binding使用第 1 步的临时私钥对{aud: 网站 origin, nonce: 表单 nonce}进行签名得到KB-JWT将 KB 部分追加到 EVT 之后组合成EVTKB完整令牌KB 创建规则定义在 EVP 协议规范的KB Creation一节引用见 index.bs浏览器自身先执行一遍完整校验3.7 EVT Verification确认无误后才会在表单提交前把EVTKB填入autocompleteemail-verification-token的隐藏 inputindex.bsForm Submission Integration。这一步的意义即便令牌泄露它也被锁死在特定网站 特定表单 一次性 nonce上无法挪用。网站侧验证 issuer 签发 SD-JWT 的完整校验链重点表单提交后网站收到的 POST 载荷形如emailuseremail.exampleevteyJhbGciOiJFZERTQSIs...示例见 index.bs。verifier 必须按 index.bsVerifier Processing Model执行以下校验链任何一步失败即验证失败校验 1验证 SD-JWT 签名信任 issuer用 issuer 的公钥验证issuance_token的签名算法与签名值确认这枚 SD-JWT 确实由权威 issuer 签发而非伪造者。校验 2验证 KB-JWT 签名信任浏览器绑定用 SD-JWTcnf声明中的公钥验证 KB 部分的签名确认令牌在到达网站前被正确地绑定过。校验 3三项声明断言防重放三件套断言校验内容防什么audience必须等于本网站 origin令牌被跨站挪用nonce必须等于服务端为本次表单生成的值同一令牌重放exp必须未过期旧令牌长期滞留校验 4邮箱一致性从令牌中提取verifiedEmail与表单中提交的email做大小写不敏感的字符串比对二者必须一致index.bs。✅ 全部 4 步通过后网站即可直接完成注册/登录验证——无需再向邮箱发送任何验证码。这就是双方签名校验链的最终闭环issuer 签名证明邮箱是我的用户KB 签名证明令牌是为这次提交准备的。安全与隐私这条签名链防住了什么规范index.bsSecurity and Privacy Considerations明确了几个值得记住的点️ 防重放nonce audience exp三重绑定截获的EVTKB在其他站点、其他表单或过期后均无效️ 隐私保护issuer blinding浏览器在 issuance 请求中必须省略Referer/Origin头issuer 无法得知用户正在访问哪个网站 DNS 安全issuer 发现依赖 DNS TXT 记录_email-verification.邮箱域 TXT ississuer域浏览器应使用 DNS-over-HTTPS / DNS-over-TLS 并检查 DNSSEC防止发现过程被劫持到恶意 issuer⚠️ 能力边界EVT 证明的是用户登录了邮件应用不保证邮件真的投递到了收件箱比 OTP 略弱但对绝大多数登录/注册场景已足够。快速上手如何验证 SD-JWT 签名新手步骤清单 想亲手跑一遍这条校验链步骤如下详见 HOWTO.md安装 Chrome Canary确认版本 145打开chrome://flags/搜索并启用#email-verification-protocol重启浏览器在chrome://settings/addresses中确认存在一个支持 EVP 的邮箱并登录该邮箱服务商在自己的注册表单中加一行input typehidden nametoken nonce?php server_side_generate_nonce() ? autocompleteemail-verification-token服务器端收到token后按上文4 步校验链依次验证 SD-JWT 签名 → KB 签名 → aud/nonce/exp → 邮箱一致性。 完整协议后端issuer 侧签发、KB 创建、令牌验证算法定义在 IETF 草案Email Verification Protocol (EVP) Backend中引用关系见 index.bs 的参考文献列表。常见问题 FAQQ1网站需要改动多少代码很少。表单加一个隐藏 input 服务端生成 nonce后端实现上面的校验链即可对用户几乎零感知。Q2用户没登录邮件服务商怎么办浏览器会静默降级到传统流程发验证码/魔法链接不会阻塞注册——这是该 API 刻意设计的优雅降级。Q3issuer 一定是邮箱同域吗不一定。DNS TXT 记录允许委派例如gmail.com可以把签发委派给accounts.google.comREADME.md。Q4这条签名链和 passkey 是什么关系互补共存。EVT 覆盖邮箱验证/找回场景passkey 覆盖免密登录场景规范明确指出二者将共生README.md。总结环节谁签名用什么证明什么EVT 签发issuer邮件服务商私钥签 SD-JWTcnf写入浏览器公钥用户是该 provider 的登录用户KB 绑定浏览器临时私钥签 KB-JWT令牌绑定到特定 origin nonce最终校验网站verifier双签名 4 步校验链邮箱所有权验证成功Email Verification API 的本质就是把发验证码邮件这个又慢又不安全的环节替换成一条可机器验证的双方签名链——issuer 的 SD-JWT 签名负责身份浏览器的 KB-JWT 签名负责上下文网站只需跑完 4 步校验即可安心放行。核心规范文件index.bs 提案说明README.md 上手指南HOWTO.md 问卷QUESTIONNAIRE.md 参与贡献CONTRIBUTING.md【免费下载链接】email-verificationverified autofill项目地址: https://gitcode.com/GitHub_Trending/em/email-verification创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考