Email Verification API 与 FedCM 有何关系同一个浏览器会话如何两用完整指南【免费下载链接】email-verificationverified autofill项目地址: https://gitcode.com/GitHub_Trending/em/email-verificationEmail Verification APIEVP与FedCM是 Web 身份领域的两项新技术而它们共用的同一块基石正是浏览器中已登录邮件服务商的会话前者用它签发我拥有这封邮箱的加密证明EVT 令牌后者用它发现你能用哪些账号登录实现一键登录。本仓库正是 Email Verification API 的提案与规范带你一次看懂这套同一会话两用的设计。 先看问题邮件验证为什么这么让人头疼先看几组数据来自 README.md 的背景调研访问排名前 50 的网站中95% 支持用邮箱注册/登录其中73% 会在验证邮箱之前卡住注册流程而传统验证方式 生成验证码 → 发邮件 → 用户切到收件箱 → 复制粘贴回来这一流程慢自动邮件可能进垃圾箱、体验差上下文反复切换、还容易被钓鱼网站骗走验证码。于是有了两条技术路线来改善账号 身份体验技术回答的问题典型场景FedCM联邦凭证管理 API你是谁能用哪些账号登录一键登录Email Verification APIEVP你能证明拥有这个邮箱吗注册时免验证码完成邮箱验证 两者的共同地基浏览器里的邮件服务商登录会话两项 API 都建立在同一份资产上——用户登录邮件服务商如 Gmail后浏览器 Cookie 中保留的那份第一方登录会话。关键在于邮件服务商在用户登录时会通过Login Status API通知浏览器自己已处于登录状态调用登录状态接口或返回Set-Login: logged-in响应头。于是这份会话就成了两项 API 的公共能源用户登录邮件服务商浏览器持有该登录会话 │ ├──▶ FedCM发现你有哪些账号 ──▶ 一键登录 │ └──▶ Email Verification API签发加密所有权证明 ──▶ 表单自动验证FedCM 拿这份会话做什么发现可登录的账号浏览器访问支持 FedCM 的网站时会向邮件服务商的.well-known/web-identity文件查询accounts 端点拉回一份你当前已登录的账号清单邮箱 姓名用户点一下即可完成登录。这也是为什么 FedCM 的大头部署方正是邮件服务商Google/Gmail、seznam.cz、gmx.de / web.de 等。Email Verification API 拿这份会话做什么签发加密所有权证明当用户在表单中选中一个邮箱地址例如自动填充浏览器会通过 DNS TXT 记录发现该邮箱域对应的签发方issuer检查用户是否登录该签发方用的就是 Login Status accounts 清单与 FedCM 同一机制经用户授权后向签发方申请一枚EVT 令牌加密签名的 SD-JWT把令牌与网站域名、一次性随机数nonce绑定KB-JWT在表单提交前自动填入隐藏字段网站服务端验签即可全程无需发送验证邮件完整协议流程含登录状态、EVT 请求、签发、绑定的 9 个步骤见 README.md 的 The Proposal 章节。⚖️ 同一会话两种用法一张表看懂区别对比维度FedCMEmail Verification APIEVT用户目的用已有账号登录证明拥有某个邮箱复用的会话能力读取已登录账号列表确认登录状态 申请签发令牌输出结果可用账号列表邮箱、姓名一次性加密验证令牌网站侧改动接入 FedCM 登录调用表单加一行隐藏输入框不支持时的降级回落到手动登录回落到传统邮箱验证码也就是说FedCM 消费这份会话的身份信息EVT 消费它的登录状态来换取加密证明。邮件服务商已经为 FedCM 部署过的端点accounts、login_url 等EVT 可以近乎零成本地复用这正是同一会话两用的精髓。 快速上手5 步在 Chrome 中体验免验证码邮箱验证按照 HOWTO.md 的官方步骤普通用户/开发者只需 5 步安装 Chrome Canary 测试版浏览器访问chrome://flags/搜索Email Verification Protocol启用#email-verification-protocol后重启浏览器在chrome://version确认版本为145在chrome://settings/addresses中确认地址簿里有一个EVP 支持域名的邮箱没有就添加确认浏览器中已登录该邮箱所属域名完成后访问支持该特性的网站在邮箱输入框选中地址、点击授权验证就会在表单提交瞬间自动完成 ✅✍️ 一行 HTML让网站支持验证过的邮箱自动填充对网站开发者来说EVP 的接入成本极低——在现有表单里加一行带nonce的隐藏输入框即可input typeemail nameemail autocompleteemail input typehidden nametoken nonce由服务端生成的随机数 autocompleteemail-verification-token要点nonce是每次渲染页面时由服务端生成的随机数用于把令牌绑定到当前表单、防止重放攻击浏览器不支持时表单自然降级为传统验证码流程用户行为零变化邮件服务商侧需预配置 DNS TXT 记录与.well-known/email-verification元数据详见 README.md 的 Issuer Discovery 与 EVT Issuance 小节 隐私对比比传统 OTP 多暴露了什么规范对隐私问题非常坦诚摘要见 QUESTIONNAIRE.md 安全隐私自评相比发验证码邮件的传统方式✅邮件服务商被致盲展示令牌时它不知道你在访问哪个网站⚠️ 网站会知道用户在本设备登录了邮件服务商比魔法链接多透露的一点点信息⚠️ 签发请求中服务商能知道用户选中了哪个邮箱✅ 全程有用户授权弹窗把关且不在跨站点间保留额外状态 常见问题 FAQQ用了 FedCM 的邮件服务商是不是就白送了 EVT 能力A基本是。两者共享 Login Status、accounts 端点与账号发现流程服务商部署一套基础设施即可支撑两种用途参见 README.md 的 Relationship to other APIs 章节。Q用户没登录邮件服务商时怎么办A流程会静默停止网站回落到传统验证码/魔法链接流程用户无感知。QEVT 会让密码和通行密钥Passkey变得多余吗A官方观点是共存共生——EVT 是工具箱里多出来的一件工具不太可能拖慢无密码化进程。 相关项目文件README.md — 完整提案问题背景、9 步协议流程、与 FedCM / WebAuthn / 数字凭证的关系HOWTO.md — Chrome 中快速试用 EVT 的操作指南index.bs — 规范 Bikeshed 源文件浏览器处理模型的权威描述index.html — 渲染后的规范文档含 HTML 扩展、表单提交流程细节QUESTIONNAIRE.md — W3C 安全与隐私自评问卷w3c.json — W3C 社区小组元数据配置CONTRIBUTING.md — 参与贡献指南一句话总结Email Verification API 与 FedCM 像是同一口井浏览器里的登录会话里打出的两桶水——一桶用来认出你是谁一桶用来证明你拥有这封邮箱而服务商与浏览器只需修好这一口井。【免费下载链接】email-verificationverified autofill项目地址: https://gitcode.com/GitHub_Trending/em/email-verification创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考