掌握注册与登录后，回到英文规范核对边界。这份导读保留原有章节与链接，帮助你按问题定位，而不把浏览器和认证器实现算法误当作必须自己手写的业务代码。
主来源：Web Authentication: An API for accessing Public Key Credentials — Level 2，W3C Recommendation，2021 年 4 月 8 日。以下是章节释义与索引；完整定义、算法顺序和要求以英文原文为准。
规范用词如何理解#
§2 Conformance 说明一致性要求。阅读规范时，特别注意这些词：
| 英文 | 中文理解 | 开发时的含义 |
|---|---|---|
| MUST / MUST NOT | 必须 / 不得 | 一致性要求，不能为了让示例通过而忽略 |
| SHOULD / SHOULD NOT | 应当 / 不应当 | 通常遵循；例外需要理解后果和适用条件 |
| MAY | 可以 | 可选能力，不能假定所有实现都有 |
| non-normative | 非规范性 | 示例、背景和解释，不是独立的合规算法 |
同一章节可能同时包含规范性算法、说明和 Note。本文的“建议”若标为开发补充，不应被误引为 W3C 的 MUST。
完整章节导航#
| 原文 | 中文主题 | 对本站开发者最直接的用途 |
|---|---|---|
| §1 Introduction | 简介、用例和 API 示例 | 理解两种仪式与参与者 |
| §2 Conformance | 一致性要求 | 区分 RP、浏览器、认证器各自的要求 |
| §3 Dependencies | 外部依赖 | 找到 Web IDL、HTML、Credential Management 等基础规范 |
| §4 Terminology | 术语 | 澄清凭据、认证器、用户句柄和 RP ID |
| §5 Web Authentication API | 浏览器 API | 查选项、响应类型和错误条件 |
| §6 Authenticator Model | 认证器模型 | 理解认证器数据、公钥、签名和计数器 |
| §7 Relying Party Operations | RP 操作 | 注册与认证验证的核心依据 |
| §8 Attestation Statement Formats | 证明语句格式 | 有设备来源或企业准入需求时深入 |
| §9 WebAuthn Extensions | 扩展机制 | 理解客户端与认证器扩展如何处理 |
| §10 Defined Extensions | 已定义扩展 | 查 credProps、largeBlob、AppID 等 |
| §11 User Agent Automation | 自动化 | 建立虚拟认证器测试 |
| §12 IANA Considerations | 标识符注册 | 实现底层格式或扩展时参考 |
| §13 Security Considerations | 安全考量 | challenge、凭据丢失、证明的局限 |
| §14 Privacy Considerations | 隐私考量 | 用户句柄、账号枚举和跨站关联 |
| §15 Accessibility | 无障碍 | 足够的时间、多种验证方式与提示 |
| §16 Acknowledgements | 致谢 | 原规范贡献者 |
| Index · References · IDL Index | 索引、参考文献和接口 | 精确查定义和类型 |
本文完整保留了规范的阅读入口，但没有逐字翻译所有认证器内部算法、证明格式和 Web IDL。学习与实现本站示例所需的内容，在前面章节按流程展开。
§6：认证器数据的结构#
§6.1 Authenticator Data 定义一段字节序列，而不是 JSON 对象。其开头包含：
| 字节内容 | 长度 | 意义 |
|---|---|---|
rpIdHash |
32 字节 | RP ID 的 SHA-256 哈希 |
flags |
1 字节 | 用户在场、用户验证及后续数据等标志 |
signCount |
4 字节 | 大端无符号签名计数 |
| attested credential data | 可变，可选 | 注册公钥、凭据 ID 和 AAGUID 等 |
| extensions | 可变，可选 | 扩展输出 |
应交给成熟验证库按格式和标志解析。不能简单用“长度大于 37 字节”证明有效。现代 L3 又定义了备份相关标志；不要把 L2 未定义位的解释套在所有新凭据上。
认证断言的核心签名输入为：
authenticatorData || SHA-256(clientDataJSON)这里的 || 表示拼接原始字节。clientDataJSON 中包含 challenge 与 origin，authenticatorData 中包含 RP ID 哈希和用户操作标志。服务端必须既验证签名，也校验这些字段符合自己发出的请求。
§6.5 与 §8：Attestation 证明什么#
Authentication assertion 用已注册的凭据私钥证明本次认证；Attestation 在注册阶段表达新公钥的来源与认证器属性。后者可能涉及设备厂商、证书链和信任策略，并不证明注册者就是某个业务账号的合法主人。
常规公众站点通常可以从 attestation: 'none' 开始，以减少隐私和部署负担。这不等于“跳过注册验证”：仍然需要解析 attestation object，提取公钥，验证 challenge、origin、RP ID、算法、标志和其他必需条件。该选择也不能作为“私钥必定存放在某种硬件”的证据。
| 格式入口 | 中文解释 |
|---|---|
| packed | 通用紧凑证明格式 |
| TPM | 与可信平台模块结构相关的证明 |
| Android Key | Android 密钥证明 |
| Android SafetyNet | L2 中保留的历史格式；不能据此推断服务当前可用性 |
| FIDO U2F | U2F 兼容证明 |
| none | 不提供可验证设备来源的证明语句 |
| Apple anonymous | Apple 匿名证明格式 |
企业若必须限制认证器型号，需要额外的证明校验、可信根与元数据、撤销处理和隐私评估。这比“设置 direct”多出一整套信任决策。§13.4.4 Attestation Limitations
§9 与 §10：扩展是可选能力#
| L2 扩展 | 用途 | 学习时的注意点 |
|---|---|---|
| appid | 兼容旧 FIDO U2F 凭据 | 仅有迁移需求才引入 |
| appidExclude | 注册时排除已有旧 U2F 凭据 | 不替代新凭据的正常注册检查 |
| uvm | 用户验证方法信息 | 可用性和隐私要分别考虑 |
| credProps | 获取凭据属性，例如 rk |
用于了解可发现性；客户端输出不能代替服务器身份验证 |
| largeBlob | 凭据关联的大数据存储 | 非所有认证器支持；不要当作通用应用数据库 |
调用 credential.getClientExtensionResults() 读取客户端扩展输出。某项输出缺失可能意味着未支持或未执行；根据该扩展的定义处理。客户端输出和认证器签名覆盖的扩展输出不是同一信任层次，不能把所有扩展结果都当作已签名事实。