Web 身份验证
公钥凭据访问 API
第 2 级

1. 简介

本节不具有规范性。

本规范定义了一个 API，使得 Web 应用程序能够创建和使用强大的、经认证的、限定作用域的、基于公钥的凭据，旨在对用户进行强身份验证。公钥凭据由 WebAuthn 验证器 在 WebAuthn 依赖方 的指令下创建并存储，并受 用户同意 约束。随后，该公钥凭据仅能被属于该依赖方的 来源 (origins) 访问。这种作用域限定由 符合要求的用户代理 和 验证器 共同强制执行。此外，跨依赖方的隐私也得以维护；依赖方无法检测到任何限定作用域于其他依赖方的凭据的任何属性，甚至无法检测其存在。

依赖方在涉及用户的两个不同但相关的仪式 (ceremonies) 中使用 Web 身份验证 API。第一种是注册，即在验证器上创建公钥凭据，并将其限定作用域于与当前用户账户相关的依赖方（账户可能已存在，也可能此时创建）。第二种是身份验证，即向依赖方出示一份 身份验证断言，证明注册该公钥凭据的用户的在场和同意。从功能上讲，Web 身份验证 API 包含一个 PublicKeyCredential，它扩展了凭据管理 API [CREDENTIAL-MANAGEMENT-1]，以及允许这些凭据与 navigator.credentials.create() 和 navigator.credentials.get() 一起使用的基础设施。前者用于注册，后者用于身份验证。

总的来说，合规的验证器保护公钥凭据，并与用户代理交互以实现 Web 身份验证 API。在以下环境中执行软件可以实现合规验证器：(a) 通用计算设备，(b) 设备上的安全执行环境、可信平台模块 (TPM) 或安全元件 (SE)，或 (c) 设备外部。在设备上实现的验证器称为平台验证器。在设备外部实现的验证器（漫游验证器）可以通过通用串行总线 (USB)、低功耗蓝牙 (BLE) 或近场通信 (NFC) 等传输方式进行访问。

1.1. 规范路线图

虽然许多 W3C 规范主要针对用户代理开发人员以及 Web 应用程序开发人员（即“Web 作者”），但 Web 身份验证的性质要求本规范能够被多个受众正确使用，具体如下所述。

所有受众都应从 § 1.2 用例、§ 1.3 API 使用场景示例 和 § 4 术语 开始，并应参阅 [WebAuthnAPIGuide] 以获取全面指南。除此之外，本文档的目标受众是以下主要群体：

• 依赖方 Web 应用程序开发人员，特别是负责依赖方 Web 应用程序登录流程、账户恢复流程、用户账户数据库内容等的开发人员。

• Web 框架开发人员

  • 上述两类受众尤其应参阅 § 7 WebAuthn 依赖方操作。§ 5 Web 身份验证 API 的介绍可能有所帮助，尽管读者应该意识到 § 5 Web 身份验证 API 部分专门针对用户代理开发人员，而非 Web 应用程序开发人员。此外，如果他们打算验证验证器的认证，那么 § 6.5 认证 和 § 8 定义的认证语句格式 也将与之相关。如果他们希望利用扩展，那么 § 9 WebAuthn 扩展 和 § 10 定义的扩展 将会引起他们的兴趣。最后，他们应阅读 § 13.4 依赖方的安全性考虑 和 § 14.6 依赖方的隐私考虑，并考虑哪些挑战适用于他们的应用程序和用户。

• 用户代理开发人员

• 操作系统平台开发人员，负责与平台特定验证器 API、平台 WebAuthn 客户端实例化等相关的操作系统平台 API 设计和实现。

  • 上述两类受众应非常仔细地阅读 § 5 Web 身份验证 API，如果他们打算支持扩展，还应阅读 § 9 WebAuthn 扩展。他们还应仔细阅读 § 14.5 客户端的隐私考虑。

• 验证器开发人员。这些读者将需要特别注意 § 6 WebAuthn 验证器模型、§ 8 定义的认证语句格式、§ 9 WebAuthn 扩展 和 § 10 定义的扩展。他们还应仔细阅读 § 13.3 验证器的安全性考虑 和 § 14.4 验证器的隐私考虑。

1.2. 用例

以下用例场景说明了两种截然不同的验证器的使用，并概述了更多场景。包括示例代码在内的更多场景在稍后的 § 1.3 API 使用场景示例 中给出。

1.2.1. 注册

• 在手机上

  • 用户在浏览器中导航到 example.com，并使用他们一直使用的任何方法（可能是一个传统方法，如密码）登录现有账户，或创建一个新账户。

  • 手机提示：“您想将此设备注册到 example.com 吗？”

  • 用户同意。

  • 手机提示用户进行预先配置的授权手势（PIN、生物识别等）；用户提供该手势。

  • 网站显示消息：“注册完成。”

1.2.2. 身份验证

• 在笔记本电脑或台式机上

  • 用户通过蓝牙将手机与笔记本电脑或台式机配对。

  • 用户在浏览器中导航到 example.com 并发起登录。

  • 用户收到浏览器的消息：“请在您的手机上完成此操作。”

• 接着，在他们的手机上

  • 用户看到一个不显眼的提示或通知：“登录到 example.com。”

  • 用户选择此提示/通知。

  • 用户看到其 example.com 身份列表，例如：“以 Mohamed 身份登录 / 以张三身份登录”。

  • 用户选择一个身份，被提示进行授权手势（PIN、生物特征等）并提供该手势。

• 现在，回到笔记本电脑上

  • 网页显示所选用户已登录，并导航到登录后的页面。

1.2.3. 新设备注册

该用例场景说明了依赖方如何利用漫游验证器（例如 USB 安全密钥钥匙扣）和平台验证器（例如内置指纹传感器）的组合，以便用户拥有

• 一个“主”漫游验证器，用于在对他们来说是新的客户端设备（例如笔记本电脑、台式机）上，或者在缺乏平台验证器的客户端设备上进行身份验证，以及

• 一种低摩擦的、在具有平台验证器的客户端设备上进行强力重新身份验证的方法。

注意：这种为一个账户注册多个验证器的方法在账户恢复用例中也很有用。

• 首先，在台式电脑上（缺少平台验证器）

  • 用户在浏览器中导航到 example.com，并使用他们一直使用的方法（可能是旧方法，如密码）登录现有账户，或创建一个新账户。

  • 用户导航到账户安全设置并选择“注册安全密钥”。

  • 网站提示用户插入 USB 安全密钥钥匙扣；用户插入。

  • USB 安全密钥闪烁，指示用户应按下其上的按钮；用户按下。

  • 网站显示消息：“注册完成。”

  注意：由于此计算机缺少平台验证器，网站可能要求用户不时或在每次与网站交互时出示其 USB 安全密钥。这由网站自行决定。

• 后来，在他们的笔记本电脑上（具有平台验证器）

  • 用户在浏览器中导航到 example.com 并发起登录。

  • 网站提示用户插入 USB 安全密钥。

  • 用户插入先前注册的 USB 安全密钥并按下按钮。

  • 网站显示用户已登录，并导航到登录后页面。

  • 网站提示：“您想将此电脑注册到 example.com 吗？”

  • 用户同意。

  • 笔记本电脑提示用户输入先前配置的授权手势（PIN、生物特征等）；用户提供该手势。

  • 网站显示消息：“注册完成。”

  • 用户注销。

• 后来，再次在他们的笔记本电脑上

  • 用户在浏览器中导航到 example.com 并发起登录。

  • 网站显示消息：“请按照您电脑的提示完成登录。”

  • 笔记本电脑提示用户进行授权手势（PIN、生物特征等）；用户提供该手势。

  • 网站显示用户已登录，并导航到登录后页面。

1.2.4. 其他用例和配置

各种其他用例和配置也是可能的，包括（但不限于）：

• 用户在笔记本电脑上导航到 example.com，并被引导完成在手机上创建并注册凭据的流程。

• 用户获得一个离散的漫游验证器，例如带有 USB 或 USB+NFC/BLE 连接选项的“钥匙扣”，在笔记本电脑或手机上的浏览器中加载 example.com，并被引导完成在钥匙扣上创建和注册凭据的流程。

• 依赖方提示用户输入其授权手势，以授权单个交易，例如付款或其他金融交易。

1.3. API 使用场景示例

本节不具有规范性。

在本节中，我们将介绍公钥凭据生命周期中的一些事件，以及使用此 API 的相应示例代码。请注意，这是一个示例流程，并不限制 API 的使用范围。

与前面的部分一样，此流程侧重于涉及带有自身显示器的第一因素漫游验证器的用例。此类验证器的一个例子是智能手机。此 API 也支持其他验证器类型，但受限于客户端平台的实现。例如，对于嵌入在客户端设备中的验证器，此流程也无需修改即可工作。对于没有自身显示器的验证器（类似于智能卡），该流程在特定实现考虑下也适用。具体而言，客户端平台需要显示原本由验证器显示的任何提示，并且验证器需要允许客户端平台枚举所有验证器的凭据，以便客户端能够获得信息来显示适当的提示。

1.3.1. 注册

这是首次流程，其中创建了一个新凭据并将其注册到服务器。在此流程中，WebAuthn 依赖方没有对平台验证器或漫游验证器的偏好。

1. 用户访问 example.com，该网站提供脚本。此时，用户可能已经使用旧有的用户名和密码、额外验证器或其他依赖方可接受的方式登录，或者用户可能正在创建新账户的过程中。

2. 依赖方脚本运行以下代码片段。

3. 客户端平台搜索并定位验证器。

4. 客户端连接到验证器，如有必要，执行任何配对操作。

5. 验证器显示适当的 UI，供用户提供生物特征或其他授权手势。

6. 验证器向客户端返回响应，客户端随后向依赖方脚本返回响应。如果用户拒绝选择验证器或拒绝提供授权，则返回适当的错误。

7. 如果创建了新凭据，则：

   • 依赖方脚本将新生成的凭据公钥发送到服务器，以及额外的信息，例如关于验证器的来源和特性的认证。

   • 服务器在数据库中存储凭据公钥，并将其与用户以及认证所指示的身份验证特性相关联，同时存储一个友好名称以供以后使用。

   • 脚本可以将诸如凭据 ID 等数据存储在本地存储中，通过缩小用户的凭据选择范围来改善未来的用户体验。

生成并注册新密钥的示例代码如下

if (!window.PublicKeyCredential) { /* Client not capable. Handle error. */ }

var publicKey = {
  // The challenge is produced by the server; see the Security Considerations
  challenge: new Uint8Array([21,31,105 /* 29 more random bytes generated by the server */]),

  // Relying Party:
  rp: {
    name: "ACME Corporation"
  },

  // User:
  user: {
    id: Uint8Array.from(window.atob("MIIBkzCCATigAwIBAjCCAZMwggE4oAMCAQIwggGTMII="), c=>c.charCodeAt(0)),
    name: "alex.mueller@example.com",
    displayName: "Alex Müller",
  },

  // This Relying Party will accept either an ES256 or RS256 credential, but
  // prefers an ES256 credential.
  pubKeyCredParams: [
    {
      type: "public-key",
      alg: -7 // "ES256" as registered in the IANA COSE Algorithms registry
    },
    {
      type: "public-key",
      alg: -257 // Value registered by this specification for "RS256"
    }
  ],

  authenticatorSelection: {
    // Try to use UV if possible. This is also the default.
    userVerification: "preferred"
  },

  timeout: 360000,  // 6 minutes
  excludeCredentials: [
    // Don’t re-register any authenticator that has one of these credentials
    {"id": Uint8Array.from(window.atob("ufJWp8YGlibm1Kd9XQBWN1WAw2jy5In2Xhon9HAqcXE="), c=>c.charCodeAt(0)), "type": "public-key"},
    {"id": Uint8Array.from(window.atob("E/e1dhZc++mIsz4f9hb6NifAzJpF1V4mEtRlIPBiWdY="), c=>c.charCodeAt(0)), "type": "public-key"}
  ],

  // Make excludeCredentials check backwards compatible with credentials registered with U2F
  extensions: {"appidExclude": "https://acme.example.com"}
};

// Note: The following call will cause the authenticator to display UI.
navigator.credentials.create({ publicKey })
  .then(function (newCredentialInfo) {
    // Send new credential info to server for verification and registration.
  }).catch(function (err) {
    // No acceptable authenticator or user refused consent. Handle appropriately.
  });

1.3.2. 使用用户验证平台验证器的特殊注册

这是一个示例流程，适用于 WebAuthn 依赖方专门有兴趣使用用户验证平台验证器创建公钥凭据的情况。

1. 用户访问 example.com 并点击登录按钮，这会将用户重定向到 login.example.com。

2. 用户输入用户名和密码进行登录。登录成功后，用户被重定向回 example.com。

3. 依赖方脚本运行以下代码片段。

   1. 用户代理检查是否有用户验证平台验证器可用。如果没有，则终止此流程。

   2. 依赖方询问用户是否想用它创建凭据。如果不，则终止此流程。

   3. 用户代理和/或操作系统显示适当的 UI，并引导用户使用可用的平台验证器之一创建凭据。

   4. 凭据创建成功后，依赖方脚本将新凭据传达给服务器。

if (!window.PublicKeyCredential) { /* Client not capable of the API. Handle error. */ }

PublicKeyCredential.isUserVerifyingPlatformAuthenticatorAvailable()
    .then(function (uvpaAvailable) {
        // If there is a user-verifying platform authenticator
        if (uvpaAvailable) {
            // Render some RP-specific UI and get a Promise for a Boolean value
            return askIfUserWantsToCreateCredential();
        }
    }).then(function (userSaidYes) {
        // If there is a user-verifying platform authenticator
        // AND the user wants to create a credential
        if (userSaidYes) {
            var publicKeyOptions = { /* Public key credential creation options. */};
            return navigator.credentials.create({ "publicKey": publicKeyOptions });
        }
    }).then(function (newCredentialInfo) {
        if (newCredentialInfo) {
            // Send new credential info to server for verification and registration.
        }
    }).catch(function (err) {
        // Something went wrong. Handle appropriately.
    });

1.3.3. 身份验证

这是具有已注册凭据的用户访问网站并希望使用该凭据进行身份验证时的流程。

1. 用户访问 example.com，后者提供一个脚本。

2. 脚本向客户端请求身份验证断言，提供尽可能多的信息以缩小用户可接受的凭据选择范围。这可以从注册后本地存储的数据中获得，或者通过其他方式（例如提示用户输入用户名）获得。

3. 依赖方脚本运行以下代码片段之一。

4. 客户端平台搜索并定位验证器。

5. 客户端连接到验证器，如有必要，执行任何配对操作。

6. 验证器向用户发出需要其注意的通知。打开通知后，用户会看到一个友好的选择菜单，显示可接受的凭据（使用创建凭据时提供的账户信息），以及有关请求这些密钥的 来源 的一些信息。

7. 验证器从用户处获得生物特征或其他授权手势。

8. 验证器向客户端返回响应，客户端随后向依赖方脚本返回响应。如果用户拒绝选择凭据或拒绝提供授权，则返回适当的错误。

9. 如果成功生成并返回了断言：

   • 脚本将断言发送给服务器。

   • 服务器检查断言，提取凭据 ID，在数据库中查找已注册的凭据公钥，并验证断言签名。如果有效，它会查找与断言的凭据 ID 相关的身份；该身份现已完成身份验证。如果服务器不识别该凭据 ID（例如，由于不活动已被取消注册），则身份验证失败；每个依赖方将以自己的方式处理此情况。

   • 服务器现在执行身份验证成功后通常会执行的任何操作——返回成功页面、设置身份验证 Cookie 等。

如果依赖方脚本没有任何可用的提示（例如从本地存储的数据中）来帮助其缩小凭据列表范围，则执行此类身份验证的示例代码可能如下所示。

if (!window.PublicKeyCredential) { /* Client not capable. Handle error. */ }

// credentialId is generated by the authenticator and is an opaque random byte array
var credentialId = new Uint8Array([183, 148, 245 /* more random bytes previously generated by the authenticator */]);
var options = {
  // The challenge is produced by the server; see the Security Considerations
  challenge: new Uint8Array([4,101,15 /* 29 more random bytes generated by the server */]),
  timeout: 120000,  // 2 minutes
  allowCredentials: [{ type: "public-key", id: credentialId }]
};

navigator.credentials.get({ "publicKey": options })
    .then(function (assertion) {
    // Send assertion to server for verification
}).catch(function (err) {
    // No acceptable credential or user refused consent. Handle appropriately.
});

另一方面，如果依赖方脚本有一些提示来帮助其缩小凭据列表范围，则执行此类身份验证的示例代码可能如下所示。请注意，此示例还演示了如何使用凭据属性扩展。

if (!window.PublicKeyCredential) { /* Client not capable. Handle error. */ }

var encoder = new TextEncoder();
var acceptableCredential1 = {
    type: "public-key",
    id: encoder.encode("BA44712732CE")
};
var acceptableCredential2 = {
    type: "public-key",
    id: encoder.encode("BG35122345NF")
};

var options = {
  // The challenge is produced by the server; see the Security Considerations
  challenge: new Uint8Array([8,18,33 /* 29 more random bytes generated by the server */]),
  timeout: 120000,  // 2 minutes
  allowCredentials: [acceptableCredential1, acceptableCredential2],
  extensions: { 'credProps': true }
};

navigator.credentials.get({ "publicKey": options })
    .then(function (assertion) {
    // Send assertion to server for verification
}).catch(function (err) {
    // No acceptable credential or user refused consent. Handle appropriately.
});

1.3.4. 中止身份验证操作

下面的示例显示了开发人员如何使用 AbortSignal 参数中止凭据注册操作。身份验证操作也有类似的程序。

const authAbortController = new AbortController();
const authAbortSignal = authAbortController.signal;

authAbortSignal.onabort = function () {
    // Once the page knows the abort started, inform user it is attempting to abort.
}

var options = {
    // A list of options.
}

navigator.credentials.create({
    publicKey: options,
    signal: authAbortSignal})
    .then(function (attestation) {
        // Register the user.
    }).catch(function (error) {
        if (error == "AbortError") {
            // Inform user the credential hasn’t been created.
            // Let the server know a key hasn’t been created.
        }
    });

// Assume widget shows up whenever authentication occurs.
if (widget == "disappear") {
    authAbortController.abort();
}

1.3.5. 停用

以下是可能需要停用凭据的情况。请注意，所有这些都在服务器端处理，不需要此处指定的 API 的支持。

• 可能性 #1 —— 用户报告凭据丢失。

  • 用户前往 server.example.net，进行身份验证并跟踪链接以报告丢失/被盗的验证器。

  • 服务器返回一个页面，显示已注册凭据的列表，以及注册时配置的易于记忆的名称。

  • 用户选择一个凭据，服务器将其从数据库中删除。

  • 未来，依赖方脚本不会在任何可接受凭据列表中指定此凭据，并且由此凭据签名的断言将被拒绝。

• 可能性 #2 —— 服务器由于不活动而注销凭据。

  • 服务器在维护活动期间从其数据库中删除凭据。

  • 未来，依赖方脚本不会在任何可接受凭据列表中指定此凭据，并且由此凭据签名的断言将被拒绝。

• 可能性 #3 -- 用户从验证器中删除凭据。

  • 用户使用验证器特定的方法（例如，设备设置 UI）从他们的验证器中删除凭据。

  • 从这时起，此凭据将不会出现在任何选择提示中，并且无法使用它生成任何断言。

  • 一段时间后，服务器由于不活动而注销此凭据。

1.4. 特定平台的实现指南

本规范定义了在一般情况下如何使用 Web 身份验证。当结合特定的平台支持（例如 App）使用 Web 身份验证时，建议查看特定平台的文档和指南以获取额外的指导和限制。

2. 合规性

本规范定义了三个一致性类别。规定了这些类别中的每一个，以便该类别的合规成员能够抵御来自其他类别的不合规或敌对成员的攻击。

2.1. 用户代理

用户代理必须按照 § 5 Web 身份验证 API 的描述行事，才能被视为合规。合规用户代理可以以任何期望的方式实现本规范中给出的算法，只要最终结果与规范算法所获得的结果无法区分即可。

合规的用户代理也必须是本规范 IDL 片段的合规实现，如“Web IDL”规范中所述。[WebIDL]

2.1.1. 作为 DOMString 类型的枚举

Web IDL 的其他部分不引用枚举类型，因为这会妨碍在不更新本规范及其实现的情况下使用其他值。对于向后兼容性而言，重要的是客户端平台和依赖方处理未知值。本规范的枚举在这里存在是为了文档和作为注册表。在其他地方表示枚举时，它们被键入为 DOMString，例如在 transports 中。

2.2. 验证器

一个 WebAuthn 验证器必须提供 § 6 WebAuthn 验证器模型 定义的操作，并且这些操作必须按照那里的描述进行行事。这是一组功能和安全要求，以便验证器能够被 合规用户代理所使用。

如 § 1.2 用例 中所述，验证器可以在用户代理底层的操作系统中实现，也可以在外部硬件中实现，或者是两者的结合。

2.2.1. 与 FIDO U2F 的向后兼容性

仅支持 § 8.6 FIDO U2F 认证语句格式 的验证器没有存储用户句柄的机制，因此返回的 userHandle 将始终为 null。

2.3. WebAuthn 依赖方

一个 WebAuthn 依赖方必须按照 § 7 WebAuthn 依赖方操作 中的描述行事，以获得本规范提供的所有安全优势。有关此内容的进一步讨论，请参阅 § 13.4.1 WebAuthn 依赖方的安全优势。

2.4. 所有合规类别

上述合规类别的成员执行的所有 CBOR 编码必须使用 CTAP2 规范化 CBOR 编码形式。上述合规类别的所有解码器应拒绝未以 CTAP2 规范化 CBOR 编码形式有效编码的 CBOR，并应拒绝包含重复映射键的消息。

3. 依赖项

本规范依赖于其他几个基础规范，这些规范列在下方和通过引用定义的术语中。

Base64url 编码

术语 Base64url 编码 指的是使用 [RFC4648] 第 5 节中定义的 URL 和文件名安全字符集的 base64 编码，省略所有尾随的 '=' 字符（如第 3.2 节所允许），且不包含任何换行符、空白或其他附加字符。

CBOR

本规范中的许多结构，包括认证语句和扩展，都是使用紧凑二进制对象表示 (CBOR) [RFC8949] 的 CTAP2 规范化 CBOR 编码形式进行编码的，如 [FIDO-CTAP] 中定义。

CDDL

本规范使用 CBOR 数据定义语言 (CDDL) [RFC8610] 描述所有 CBOR 编码数据的语法。

COSE

CBOR 对象签名和加密 (COSE) [RFC8152]。本规范建立的 IANA COSE 算法注册表 [IANA-COSE-ALGS-REG] 也被使用。

凭据管理

本文档中描述的 API 是 [CREDENTIAL-MANAGEMENT-1] 中定义的 Credential 概念的扩展。

DOM

DOMException 以及本规范中使用的 DOMException 值在 [DOM4] 中定义。

ECMAScript

%ArrayBuffer% 在 [ECMAScript] 中定义。

HTML

浏览上下文 (browsing context)、来源 (origin)、不透明来源 (opaque origin)、元组来源 (tuple origin)、相关设置对象 (relevant settings object) 以及 是...的可注册域名后缀或等于... 的概念在 [HTML] 中定义。

URL

同站 (same site) 的概念在 [URL] 中定义。

Web IDL

本规范中的许多接口定义和所有 IDL 都依赖于 [WebIDL]。Web IDL 标准的这个更新版本增加了对 Promise 的支持，这现在是所有新 Web API 中异步交互的首选机制。

FIDO AppID

确定调用应用程序的 FacetID 和 确定调用者的 FacetID 是否被 AppID 授权（仅在 AppID 扩展中使用）的算法由 [FIDO-APPID] 定义。

本文档中的关键字 "MUST"、"MUST NOT"、"REQUIRED"、"SHALL"、"SHALL NOT"、"SHOULD"、"SHOULD NOT"、"RECOMMENDED"、"MAY" 和 "OPTIONAL" 应按照 [RFC2119] 中的描述进行解释。

4. 术语

证明（Attestation）

通常，认证 (attestation) 是一份用作见证、确认或验证的声明。在 WebAuthn 上下文中，认证用于证明 (attest) 验证器及其发出的数据的来源 (provenance)；包括，例如：凭据 ID、凭据密钥对、签名计数器等。在注册期间，通过认证对象传达认证语句。另请参阅 § 6.5 认证 和 图 6。客户端如何将认证对象的认证语句和 AAGUID 部分传达给依赖方，由认证传输 (attestation conveyance) 描述。

证明证书（Attestation Certificate）

一个用于验证器进行自身制造和能力证明的 认证密钥对 (attestation key pair) 的 X.509 证书。在注册时，验证器使用 认证私钥 来签署其生成并通过 authenticatorMakeCredential 操作返回的依赖方特定的凭据公钥（及额外数据）。依赖方使用认证证书中传达的 认证公钥 来验证认证签名。注意，在自认证的情况下，验证器既没有独立的认证密钥对也没有认证证书，详情请参阅自认证。

身份验证（Authentication）

身份验证仪式（Authentication Ceremony）

用户及其客户端（包含至少一个验证器）协作向依赖方以密码学方式证明用户控制了先前注册的公钥凭据的凭据私钥的仪式（参见注册）。注意，这包括用户在场测试或用户验证。

WebAuthn 身份验证仪式定义在 § 7.2 验证身份验证断言 中，由依赖方调用 navigator.credentials.get() 且带有 publicKey 参数来发起。有关入门概述，请参阅 § 5 Web 身份验证 API，有关实现示例，请参阅 § 1.3.3 身份验证。

身份验证断言（Authentication Assertion）

断言（Assertion）

作为 authenticatorGetAssertion 操作的结果，由验证器返回的经过加密签名的 AuthenticatorAssertionResponse 对象。

这对应于 [CREDENTIAL-MANAGEMENT-1] 规范的一次性凭据。

验证器（Authenticator）

WebAuthn 验证器 (WebAuthn Authenticator)

一种以硬件或软件形式存在的加密实体，当依赖方请求时，可以向给定的依赖方注册用户，稍后断言拥有 (assert possession) 已注册的公钥凭据，并可选择验证用户。验证器可以在注册期间通过认证报告有关其类型和安全特性的信息。

一个 WebAuthn 验证器可以是一个漫游验证器、一个集成到客户端设备中的专用硬件子系统，或是客户端或客户端设备的软件组件。

通常，一个验证器被假定只有一个用户。如果多个自然人共享对一个验证器的访问权限，则在那个验证器的上下文中，他们被视为同一个用户。如果一个验证器实现支持在隔离的分区中拥有多个用户，那么每个分区都被视为一个具有单个用户的独立验证器，且无法访问其他用户的凭据。

授权手势（Authorization Gesture）

授权手势是用户作为仪式（如注册或身份验证）的一部分与验证器进行的物理交互。通过进行这样的授权手势，用户提供同意（即授权）仪式继续进行。如果所使用的验证器具备相应能力，这可能涉及用户验证，或者可能仅涉及简单的用户在场测试。

生物识别（Biometric Recognition）

基于个体生物和行为特征的自动化识别 [ISOBiometricVocabulary]。

生物特征认证器

任何实现生物特征识别的验证器。

绑定凭据

一个公钥凭据源 (public key credential source) 或公钥凭据被称为被绑定 (bound) 到其管理验证器。这意味着只有管理验证器可以为绑定到它的公钥凭据源生成断言。

仪式

仪式 (ceremony) [Ceremony] 的概念是网络协议概念的扩展，包括人类节点和计算机节点，以及包含用户界面、人际沟通以及传输携带数据的物理对象的通信链路。协议之外的是仪式的范畴。在本规范中，注册和身份验证是仪式，而授权手势通常是这些仪式的一个组成部分。

客户端

WebAuthn 客户端

本文中也简称为客户端。另请参阅合规用户代理。一个 WebAuthn 客户端是一个中间实体，通常在用户代理中（全部或部分）实现。从概念上讲，它是 Web 身份验证 API 的基础，体现了 [[Create]](origin, options, sameOriginWithAncestors) 和 [[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors) 内部方法的实现。它负责为底层的验证器操作整理输入，并将这些操作的结果返回给 Web 身份验证 API 的调用者。

WebAuthn 客户端在 WebAuthn 客户端设备上运行，并且与该设备是分开的。

客户端设备

WebAuthn 客户端设备

WebAuthn 客户端在其上运行的硬件设备，例如智能手机、笔记本电脑或台式计算机，以及在该硬件上运行的操作系统。

WebAuthn 客户端设备和客户端之间的区别在于：

• 单个客户端设备可以支持运行多个客户端，即浏览器实现，它们都可以访问在该客户端设备上可用的相同验证器，并且

• 平台验证器绑定到客户端设备，而不是WebAuthn 客户端。

客户端设备和客户端共同构成了客户端平台。

客户端平台

客户端设备和客户端共同组成客户端平台。单个硬件设备可以通过运行不同的操作系统和/或客户端，在不同时间成为多个不同客户端平台的一部分。

客户端侧

这通常指用户的客户端平台、验证器以及将所有内容粘合在一起的一切事物的组合。

客户端可发现公钥凭据源 (Client-side discoverable Public Key Credential Source)

客户端可发现凭据 (Client-side discoverable Credential)

可发现凭据 (Discoverable Credential)

[已弃用] 驻留凭据 (Resident Credential)

[已弃用] 驻留密钥 (Resident Key)

注意：历史上，客户端可发现凭据被称为驻留凭据或驻留密钥。由于短语 ResidentKey 和 residentKey 在 WebAuthn API 以及 验证器模型（例如，在字典成员名称、算法变量名称和操作参数中）中被广泛使用，因此为了向后兼容，它们名称中 resident 的用法并未更改。此外，术语驻留密钥在此处定义为等同于客户端可发现凭据。

客户端可发现公钥凭据源，简称可发现凭据，是一种公钥凭据源，它是 可发现的 且可用于身份验证仪式，在这种仪式中，依赖方不提供任何凭据 ID，即依赖方在调用 navigator.credentials.get() 时带有 空 的 allowCredentials 参数。这意味着依赖方不一定需要首先识别用户。

因此，一个具有可发现凭据能力的验证器仅需提供依赖方 ID (RP ID) 即可为可发现凭据生成断言签名，这反过来要求公钥凭据源存储在验证器或客户端平台中。这与服务器端公钥凭据源形成对比，后者要求向验证器提供依赖方 ID 和凭据 ID，但不要求客户端存储公钥凭据源。

另请参阅：客户端凭据存储模态 和 非可发现凭据。

注意：客户端可发现凭据也适用于在身份验证仪式中提供凭据 ID 的情况，即调用 navigator.credentials.get() 时带有非空的 allowCredentials 参数。

符合规范的用户代理

一个用户代理，它与底层客户端设备协作，实现 Web 身份验证 API 和本规范中给出的算法，并处理验证器与依赖方之间的通信。

凭据 ID

一种概率唯一且标识公钥凭据源及其身份验证断言的字节序列。

凭据 ID 由验证器以两种形式生成：

1. 至少 16 字节且包含至少 100 位熵；或者

2. 公钥凭据源（不含其凭据 ID 或可变项）被加密，以便只有其管理验证器才能解密。这种形式允许验证器几乎是无状态的，由依赖方存储任何必要的状态。

   注意：[FIDO-UAF-AUTHNR-CMDS] 在“安全指南”下包含了关于加密技术的指导。

依赖方不需要区分这两种凭据 ID 形式。

凭据密钥对 (Credential Key Pair)

凭据私钥 (Credential Private Key)

凭据公钥

用户公钥

一个凭据密钥对是由验证器生成并限定作用域于特定 WebAuthn 依赖方的非对称加密密钥对。它是公钥凭据的核心部分。

一个凭据公钥是凭据密钥对的公钥部分。凭据公钥在注册仪式期间返回给依赖方。

一个凭据私钥是凭据密钥对的私钥部分。凭据私钥被绑定到特定的验证器（即其管理验证器），并且预期绝不会暴露给任何其他方，即使是验证器的所有者。

注意，在自认证的情况下，凭据密钥对也用作认证密钥对，详情请参阅自认证。

注意：凭据公钥在 FIDO UAF [UAFProtocol] 以及 FIDO U2F [FIDO-U2F-Message-Formats] 和本规范中与此相关的部分中被称为用户公钥 (user public key)。

凭据属性 (Credential Properties)

一个凭据属性是公钥凭据源的某种特征属性，例如它是否是客户端可发现凭据或是服务器端凭据。

人类可读性

一个人类可读的标识符，旨在让普通用户易于记忆和复现，这与例如随机生成的比特序列 [EduPersonObjectClassSpec] 等标识符形成对比。

不可发现凭据 (Non-Discoverable Credential)

这是一种凭据，当调用 navigator.credentials.get() 时，必须在 allowCredentials 中提供其凭据 ID，因为它不是客户端可发现的。另请参阅服务器端凭据。

公钥凭据源

由验证器用于生成身份验证断言的凭据源（[CREDENTIAL-MANAGEMENT-1]）。公钥凭据源由包含以下项的结构体组成：

type

其值为 PublicKeyCredentialType，默认为 public-key。

id

一个凭据 ID。

privateKey

凭据私钥。

rpId

依赖方标识符，即此公钥凭据源所作用于的依赖方。

userHandle

创建此公钥凭据源时关联的用户句柄。该项可为空。

otherUI

可选的其它信息，供验证器用于呈现其 UI。例如，这可能包括用户的 displayName。otherUI 是一个可变项，不应以阻止 otherUI 更新的方式绑定到公钥凭据源。

authenticatorMakeCredential 操作会创建一个绑定到管理验证器的公钥凭据源，并返回与其凭据私钥关联的凭据公钥。依赖方可以使用此凭据公钥来验证由该公钥凭据源创建的身份验证断言。

公钥凭据

通常，凭据是实体向另一实体提供的数据，旨在将前者认证给后者 [RFC4949]。术语公钥凭据指代以下之一：公钥凭据源、对应于公钥凭据源且可能经过认证的凭据公钥，或身份验证断言。具体指代哪一个通常由上下文决定。

注意：这是对 [RFC4949] 的故意违背。在英语中，“credential”既指代 a) 为证明某声明而提交的事物，也指代 b) 旨在被多次使用的事物。在公钥系统中，无法用单一数据安全地同时实现这两个标准。[RFC4949] 选择将凭据定义为可以多次使用的东西（公钥），而本规范赋予了“credential”一词英语层面的灵活性。本规范使用更具体的术语来标识与 [RFC4949] 凭据相关的数据。

“身份验证信息”（可能包含私钥）

公钥凭据源

“签名值”

身份验证断言

[RFC4949] “credential”

凭据公钥或认证对象

在注册时，验证器会创建一个非对称密钥对，并将其私钥部分和来自依赖方的信息存储到公钥凭据源中。公钥部分会被返回给依赖方，由其连同当前用户的账户一并存储。随后，只有通过其RP ID标识的该依赖方能够通过 get() 方法在身份验证仪式中使用该公钥凭据。依赖方使用其存储的凭据公钥副本，来验证由此产生的身份验证断言。

速率限制

验证器通过限制在特定时间内连续失败的身份验证尝试次数，来实现针对暴力破解攻击的控制过程（也称为节流）。如果达到限制，验证器应施加随每次后续尝试呈指数增长的延迟，或者禁用当前的身份验证模式，并在可用时提供另一种身份验证因素。速率限制通常作为用户验证的一个方面来实现。

注册

注册仪式

一种仪式，其中用户、依赖方和用户的客户端（包含至少一个验证器）协同工作，以创建一个公钥凭据并将其与用户的依赖方账户关联。注意，这包括采用用户在场测试或用户验证。在成功的注册仪式后，用户可以通过身份验证仪式进行认证。

WebAuthn 注册仪式定义在 § 7.1 注册新凭据 中，由依赖方调用带有 publicKey 参数的 navigator.credentials.create() 发起。请参阅 § 5 Web Authentication API 获取入门概述，以及 § 1.3.1 注册 获取实现示例。

依赖方

请参阅 WebAuthn 依赖方。

依赖方标识符

RP ID

在 WebAuthn API 的上下文中，依赖方标识符是一个有效域名字符串，用于标识正在为其执行给定注册或身份验证仪式的 WebAuthn 依赖方。公钥凭据只能与注册它的同一实体（由RP ID标识）进行身份验证。

默认情况下，WebAuthn 操作的RP ID被设置为调用者的源 (origin)的有效域名。调用者可以覆盖此默认值，只要调用者指定的RP ID值是调用者源的有效域名的可注册域名后缀或与之相等即可。另请参阅 § 5.1.3 创建新凭据 - PublicKeyCredential 的 [[Create]](origin, options, sameOriginWithAncestors) 方法 和 § 5.1.4 使用现有凭据进行断言 - PublicKeyCredential 的 [[Get]](options) 方法。

注意：RP ID 基于主机 (host)的域名。它本身不包含协议方案或端口，这与源 (origin)不同。公钥凭据的RP ID决定了其作用域 (scope)。即，它确定了公钥凭据可在其上使用的源的集合，具体如下：

• RP ID 必须等于源的有效域名，或者是该源的有效域名的可注册域名后缀。

• 源的协议方案必须为 https。

• 源的端口不受限制。

例如，给定一个源为 https://login.example.com:1337 的依赖方，以下RP ID是有效的：login.example.com（默认）和 example.com，但 m.login.example.com 和 com 无效。

这样做是为了匹配普遍部署的周边凭据（如 Cookie，[RFC6265]）的行为。请注意，这比 document.domain 的 setter 所提供的“同源”限制放宽程度更大。

这些对源值的限制适用于 WebAuthn 客户端。

其他模仿 WebAuthn API 以在非 Web 平台（如原生移动应用）上启用 WebAuthn 公钥凭据的规范，可能定义不同的规则来将调用者绑定到依赖方标识符。不过，RP ID 语法必须符合有效域名字符串或 URI [RFC3986] [URL]。

服务器端公钥凭据源 (Server-side Public Key Credential Source)

服务器端凭据 (Server-side Credential)

[已弃用] 非驻留凭据 (Non-Resident Credential)

注意： 在历史上，服务器端凭据被称为非驻留凭据。为了向后兼容，各种名称中包含 resident 形式的 WebAuthn API 和 验证器模型组件并未更改。

服务器端公钥凭据源（简称服务器端凭据）是一种公钥凭据源，仅当依赖方在 navigator.credentials.get() 的 allowCredentials 参数中提供其凭据 ID 时，才能在身份验证仪式中使用。这意味着依赖方必须管理凭据的存储和发现，并且必须能够先识别用户，以便发现要在 navigator.credentials.get() 调用中提供的凭据 ID。

服务器端凭据不需要客户端存储公钥凭据源。这与客户端可发现凭据形成对比，后者不需要用户先被识别即可向 navigator.credentials.get() 调用提供用户的凭据 ID。

另请参阅：服务器端凭据存储模式 和 不可发现凭据。

用户在场测试

用户在场测试是一种简单的授权手势和技术过程，用户通过（通常是）简单触摸验证器（也可能存在其他方式）与验证器进行交互，并返回布尔结果。注意，这不构成用户验证，因为根据定义，用户在场测试无法进行生物特征识别，也不涉及提交密码或 PIN 等共享密钥。

用户同意

用户同意意味着用户同意其被询问的内容，即它涵盖了阅读和理解提示。授权手势是一种经常用来表示用户同意的仪式组件。

用户句柄

用户句柄由依赖方指定，作为 user.id 的值，用于将特定的公钥凭据映射到依赖方的特定用户账户。验证器进而将 RP ID 和用户句柄对映射到公钥凭据源。

用户句柄是一个不透明的字节序列，最大长度为 64 字节，不打算向用户显示。

用户验证

验证器本地授权调用 authenticatorMakeCredential 和 authenticatorGetAssertion 操作的技术过程。用户验证可以通过各种授权手势模式发起；例如，通过触摸加 PIN 码、输入密码或生物特征识别（如提供指纹）[ISOBiometricVocabulary]。其目的是区分个体用户。

注意，用户验证并不向依赖方提供用户的具体身份，但当使用该凭据完成了 2 次或更多次用户验证仪式时，它表示所有这些操作都是由同一用户执行的。然而，如果多个自然人共享对同一个验证器的访问权限，同一个用户可能并不总是同一个自然人。

注意： 区分自然人在很大程度上取决于客户端平台和验证器的功能。例如，有些设备旨在由个人使用，但它们可能允许多个自然人注册指纹或知道同一个 PIN，从而使用该设备访问同一个依赖方账户。

注意：调用 authenticatorMakeCredential 和 authenticatorGetAssertion 操作意味着使用由验证器管理的密钥材料。

此外，为了安全起见，用户验证和凭据私钥的使用必须全部发生在定义验证器的逻辑安全边界内。

用户验证程序可能实现速率限制作为针对暴力破解攻击的保护。

用户在场

UP

成功完成用户在场测试后，即称用户“在场”。

用户已验证

UV

成功完成用户验证过程后，用户被称为“已验证 (verified)”。

WebAuthn 依赖方

其实体Web 应用程序利用 Web Authentication API 来注册和认证用户。

依赖方实现通常由在客户端调用 Web Authentication API 的客户端脚本，以及执行依赖方操作和其他应用逻辑的服务器端组件组成。两个组件之间的通信必须使用 HTTPS 或等效的传输安全协议，但这超出了本规范的范围。

注意： 虽然术语依赖方也常用于其他上下文（例如 X.509 和 OAuth），但在一个上下文中作为依赖方行动的实体，并不一定在其他上下文中也是依赖方。在本规范中，术语 WebAuthn 依赖方常被简称为依赖方，明确指代 WebAuthn 上下文中的依赖方。注意，在任何具体实例化中，WebAuthn 上下文都可能嵌入在更广泛的整体上下文中，例如基于 OAuth 的上下文。

5. Web Authentication API

本节规范性地规定了创建和使用公钥凭据的 API。基本思想是凭据属于用户，并由 WebAuthn 验证器管理，WebAuthn 依赖方通过客户端平台与验证器交互。依赖方脚本可以（经用户同意）请求浏览器为依赖方的未来使用创建一个新凭据。请参阅下方的 图 。

脚本还可以请求用户的许可，以使用现有凭据执行身份验证操作。请参阅下方的 图 。

所有此类操作均在验证器中执行，并由客户端平台代表用户调解。脚本在任何时候都无法访问凭据本身；它仅能以对象的形式获得有关凭据的信息。

除了上述脚本接口外，认证器还可以实现（或附带实现该功能的客户端软件）用于管理的用户界面。例如，此类界面可用于将认证器重置为干净状态或检查认证器的当前状态。换言之，此类界面类似于浏览器提供的用于管理用户状态（如历史记录、保存的密码和 cookie）的用户界面。诸如凭据删除之类的认证器管理操作被认为属于此类用户界面的职责，并在向脚本开放的 API 中刻意省略。

此 API 的安全属性由客户端和验证器共同提供。持有并管理凭据的验证器通过在响应中加入源，确保所有操作均作用于特定的源，且不能针对不同的源重放。具体而言，如 § 6.3 验证器操作 中定义，请求者的完整源被包含在创建新凭据时生成的认证对象中，并在此上进行签名，WebAuthn 凭据生成的所有断言中也包含此源。

此外，为了维护用户隐私并防止恶意依赖方探测属于其他依赖方的公钥凭据的存在，每个凭据也作用于一个依赖方标识符，即 RP ID。此 RP ID 由客户端在所有操作中提供给验证器，而验证器确保由依赖方创建的凭据只能在由相同 RP ID 请求的操作中使用。通过这种方式将源与 RP ID 分离，使得 API 可用于单一依赖方维护多个源的情况。

客户端通过为每次操作向验证器提供依赖方的源和 RP ID 来促进这些安全措施。由于这是 WebAuthn 安全模型不可或缺的一部分，用户代理仅在安全上下文中向调用者公开此 API。对于 Web 上下文，这仅包括通过无错误的、已建立的安全传输协议（如 TLS）访问的上下文。

Web Authentication API 是由以下各节中介绍的 Web IDL 片段合并定义的。合并后的 IDL 列表在 IDL 索引中给出。

5.1. PublicKeyCredential 接口

PublicKeyCredential 接口继承自 Credential [CREDENTIAL-MANAGEMENT-1]，并包含在创建新凭据或请求新断言时返回给调用者的属性。

[SecureContext, Exposed=Window]
interface PublicKeyCredential : Credential {
    [SameObject] readonly attribute ArrayBuffer              rawId;
    [SameObject] readonly attribute AuthenticatorResponse    response;
    AuthenticationExtensionsClientOutputs getClientExtensionResults();
};

id

此属性继承自 Credential，尽管 PublicKeyCredential 覆盖了 Credential 的 getter，转而返回对象 [[identifier]] 内部槽中所含数据的base64url 编码。

rawId

此属性返回 [[identifier]] 内部槽中所含的 ArrayBuffer。

✔MDN

PublicKeyCredential/response

在所有当前引擎中。

Firefox60+Safari13+Chrome67+

---

Opera无Edge79+

---

Edge (旧版)18IE无

---

Firefox for Android60+iOS Safari13.3+Chrome for Android70+Android WebView70+Samsung Internet无Opera Mobile无

response，类型为 AuthenticatorResponse，只读

此属性包含验证器对客户端创建公钥凭据或生成身份验证断言的请求的响应。如果 PublicKeyCredential 是为了响应 create() 而创建，则该属性的值将为 AuthenticatorAttestationResponse；否则，PublicKeyCredential 是为了响应 get() 而创建，该属性的值将为 AuthenticatorAssertionResponse。

getClientExtensionResults()

此操作返回 [[clientExtensionsResults]] 的值，这是一个由扩展程序的客户端扩展程序处理生成的、包含扩展程序标识符 → 客户端扩展输出条目的映射。

[[type]]

PublicKeyCredential 接口对象的 [[type]] 内部槽的值为字符串 "public-key"。

注意： 这通过继承自 Credential 的 type 属性 getter 反映出来。

[[discovery]]

PublicKeyCredential 接口对象的 [[discovery]] 内部槽的值为 "remote"。

[[identifier]]

此内部槽包含由验证器选择的凭据 ID。凭据 ID 用于查找可使用的凭据，因此预期其在所有相同类型的凭据中，以及所有验证器之间，具有很高的全局唯一性概率。

注意： 本 API 不约束此标识符的格式或长度，只要它足以让验证器唯一选择密钥即可。例如，没有内置存储的验证器可能会创建包含凭据私钥的标识符，该私钥由刻录在验证器中的对称密钥包裹。

[[clientExtensionsResults]]

此内部槽包含依赖方在调用 navigator.credentials.create() 或 navigator.credentials.get() 时，处理请求的客户端扩展的结果。

PublicKeyCredential 的接口对象继承 Credential 对 [[CollectFromCredentialStore]](origin, options, sameOriginWithAncestors) 的实现，并定义了自己的 [[Create]](origin, options, sameOriginWithAncestors)、[[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors) 和 [[Store]](credential, sameOriginWithAncestors) 实现。

5.1.1. CredentialCreationOptions 字典扩展

为支持通过 navigator.credentials.create() 进行注册，本文档对 CredentialCreationOptions 字典进行了如下扩展：

partial dictionary CredentialCreationOptions {
    PublicKeyCredentialCreationOptions      publicKey;
};

5.1.2. CredentialRequestOptions 字典扩展

为支持通过 navigator.credentials.get() 获取断言，本文档对 CredentialRequestOptions 字典进行了如下扩展：

partial dictionary CredentialRequestOptions {
    PublicKeyCredentialRequestOptions      publicKey;
};

5.1.3. 创建新凭据 - PublicKeyCredential 的 [[Create]](origin, options, sameOriginWithAncestors) 方法

5.1.4. 使用现有凭据进行断言 - PublicKeyCredential 的 [[Get]](options) 方法

WebAuthn 信赖方 调用 navigator.credentials.get({publicKey:..., ...}) 以发现并使用现有的 公钥凭据，并获得 用户的同意。信赖方 脚本可选择指定一些准则，以指示哪些 凭据来源 是其可接受的。客户端平台 定位符合指定准则的 凭据来源，并引导用户选择一个脚本允许使用的凭据。用户可以选择拒绝整个交互，即使存在 凭据来源，例如为了保持隐私。如果用户选择了 凭据来源，用户代理随后使用 § 6.3.3 The authenticatorGetAssertion 操作 对 信赖方 提供的挑战和其他收集的数据进行签名，并将其转换为断言，作为 凭据 使用。

get() 实现 [CREDENTIAL-MANAGEMENT-1] 调用 PublicKeyCredential.[[CollectFromCredentialStore]]() 来收集任何无需 用户中介（大致为本规范的 授权手势）即可使用的 凭据；如果没有找到其中确切的一个，它会随后调用 PublicKeyCredential.[[DiscoverFromExternalSource]]() 让用户选择一个 凭据来源。

由于本规范要求 授权手势 才能创建任何 凭据，PublicKeyCredential.[[CollectFromCredentialStore]](origin, options, sameOriginWithAncestors) 内部方法 继承了 Credential.[[CollectFromCredentialStore]]() 的默认行为，即返回空集。

此 navigator.credentials.get() 操作可以通过利用 AbortController 中止；有关详细说明，请参阅 DOM §3.3 在 API 中使用 AbortController 和 AbortSignal 对象。

5.1.4.1. PublicKeyCredential 的 [[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors) 方法

5.1.5. 存储现有凭据 - PublicKeyCredential 的 [[Store]](credential, sameOriginWithAncestors) 方法

5.1.6. 防止对现有凭据的静默访问 - PublicKeyCredential 的 [[preventSilentAccess]](credential, sameOriginWithAncestors) 方法

5.1.7. 用户验证平台身份验证器的可用性 - PublicKeyCredential 的 isUserVerifyingPlatformAuthenticatorAvailable() 方法

partial interface PublicKeyCredential {
    static Promise<boolean> isUserVerifyingPlatformAuthenticatorAvailable();
};

5.2. 验证器响应（接口 AuthenticatorResponse）

身份验证器 通过返回一个派生自 AuthenticatorResponse 接口的对象来响应 信赖方 请求

[SecureContext, Exposed=Window]
interface AuthenticatorResponse {
    [SameObject] readonly attribute ArrayBuffer      clientDataJSON;
};

5.2.1. 关于公钥凭据的信息（接口 AuthenticatorAttestationResponse）

AuthenticatorAttestationResponse 接口表示 身份验证器 对客户端创建新 公钥凭据 请求的响应。它包含关于新凭据的信息（可用于后续使用时标识它），以及 WebAuthn 信赖方 在注册期间可用来评估凭据特征的元数据。

[SecureContext, Exposed=Window]
interface AuthenticatorAttestationResponse : AuthenticatorResponse {
    [SameObject] readonly attribute ArrayBuffer      attestationObject;
    sequence<DOMString>                              getTransports();
    ArrayBuffer                                      getAuthenticatorData();
    ArrayBuffer?                                     getPublicKey();
    COSEAlgorithmIdentifier                          getPublicKeyAlgorithm();
};

5.2.1.1. 轻松访问凭据数据

[[Create]](origin, options, sameOriginWithAncestors) 方法的每个用户都需要解析并存储返回的 凭据公钥，以便验证未来的 身份验证断言。然而，凭据公钥 采用 [RFC8152] (COSE) 格式，位于 证明对象（由 AuthenticatorAttestationResponse.attestationObject 传达）内的 身份验证器数据 内的 已认证凭据数据 的 credentialPublicKey 成员中。信赖方 希望使用 证明 时，必须履行解析 attestationObject 并获取 凭据公钥 的工作，因为该公钥副本是 身份验证器 签署 的那一项。然而，许多有效的 WebAuthn 用例不需要 证明。对于这些用途，用户代理可以完成解析工作，直接公开 身份验证器数据，并将 凭据公钥 转换为更方便的格式。

getPublicKey() 操作因此将 凭据公钥 作为 SubjectPublicKeyInfo 返回。这个 ArrayBuffer 例如可以传递给 Java 的 java.security.spec.X509EncodedKeySpec、.NET 的 System.Security.Cryptography.ECDsa.ImportSubjectPublicKeyInfo 或 Go 的 crypto/x509.ParsePKIXPublicKey。

使用 getPublicKey() 确实有一些限制：通过使用 pubKeyCredParams，信赖方 可以与 身份验证器 协商使用用户代理可能无法理解的公钥算法。然而，如果 信赖方 这样做，用户代理将无法将生成的 凭据公钥 转换为 SubjectPublicKeyInfo 格式，并且 getPublicKey() 的返回值将为 null。

当 凭据公钥 具有以下 COSEAlgorithmIdentifier 值时，用户代理必须能够为 getPublicKey() 返回非 null 值：

• -7 (ES256)，其中 kty 为 2（带未压缩点），crv 为 1 (P-256)。

• -257 (RS256)。

• -8 (EdDSA)，其中 crv 为 6 (Ed25519)。

SubjectPublicKeyInfo 不包含 COSE 公钥中包含的签名算法信息（例如使用哪种哈希函数）。为了提供此信息，getPublicKeyAlgorithm() 返回 凭据公钥 的 COSEAlgorithmIdentifier。

为了在许多情况下完全消除解析 CBOR 的需要，getAuthenticatorData() 从 attestationObject 返回 身份验证器数据。身份验证器数据 包含其他以二进制格式编码的字段。但是，不提供用于访问它们的辅助函数，因为 信赖方 在 获取断言 时已经需要提取这些字段。与签名验证 可选 的 凭据创建 相比，信赖方 应该始终验证来自断言的签名，因此必须从已签署的 身份验证器数据 中提取字段。在那里使用的相同函数也将在凭据创建期间使用。

注意： getPublicKey() 和 getAuthenticatorData() 仅在本规范的二级中添加。信赖方 在使用这些函数之前，应通过测试 'getPublicKey' in AuthenticatorAttestationResponse.prototype 的值来使用功能检测。要求该函数必须存在的 信赖方 可能无法与旧版用户代理互操作。

5.2.2. Web 身份验证断言（接口 AuthenticatorAssertionResponse）

AuthenticatorAssertionResponse 接口表示 身份验证器 对客户端生成新 身份验证断言 请求的响应，该请求给定 WebAuthn 信赖方 的挑战和其知晓的可选凭据列表。此响应包含一个加密签名，证明拥有 凭据私钥，以及可选的用户对特定交易 同意 的证据。

[SecureContext, Exposed=Window]
interface AuthenticatorAssertionResponse : AuthenticatorResponse {
    [SameObject] readonly attribute ArrayBuffer      authenticatorData;
    [SameObject] readonly attribute ArrayBuffer      signature;
    [SameObject] readonly attribute ArrayBuffer?     userHandle;
};

5.3. 凭据生成的参数（字典 PublicKeyCredentialParameters）

dictionary PublicKeyCredentialParameters {
    required DOMString                    type;
    required COSEAlgorithmIdentifier      alg;
};

5.4. 凭据创建选项（字典 PublicKeyCredentialCreationOptions）

dictionary PublicKeyCredentialCreationOptions {
    required PublicKeyCredentialRpEntity         rp;
    required PublicKeyCredentialUserEntity       user;

    required BufferSource                             challenge;
    required sequence<PublicKeyCredentialParameters>  pubKeyCredParams;

    unsigned long                                timeout;
    sequence<PublicKeyCredentialDescriptor>      excludeCredentials = [];
    AuthenticatorSelectionCriteria               authenticatorSelection;
    DOMString                                    attestation = "none";
    AuthenticationExtensionsClientInputs         extensions;
};

5.4.1. 公钥实体描述（字典 PublicKeyCredentialEntity）

PublicKeyCredentialEntity 字典描述了一个用户账户，或一个WebAuthn 信赖方 (WebAuthn Relying Party)，公钥凭据分别与它们相关联或被作用于其中。

dictionary PublicKeyCredentialEntity {
    required DOMString    name;
};

5.4.2. 凭据生成的信赖方参数（字典 PublicKeyCredentialRpEntity）

PublicKeyCredentialRpEntity 字典用于在创建新凭据时提供额外的信赖方 (Relying Party) 属性。

dictionary PublicKeyCredentialRpEntity : PublicKeyCredentialEntity {
    DOMString      id;
};

5.4.3. 凭据生成的用户账户参数（字典 PublicKeyCredentialUserEntity）

PublicKeyCredentialUserEntity 字典用于在创建新凭据时提供额外的用户账户属性。

dictionary PublicKeyCredentialUserEntity : PublicKeyCredentialEntity {
    required BufferSource   id;
    required DOMString      displayName;
};

5.4.4. 验证器选择标准（字典 AuthenticatorSelectionCriteria）

WebAuthn 信赖方 (WebAuthn Relying Party) 可以使用 AuthenticatorSelectionCriteria 字典来指定其对验证器属性的要求。

dictionary AuthenticatorSelectionCriteria {
    DOMString                    authenticatorAttachment;
    DOMString                    residentKey;
    boolean                      requireResidentKey = false;
    DOMString                    userVerification = "preferred";
};

5.4.5. 验证器附件枚举（枚举 AuthenticatorAttachment）

此枚举的值描述了验证器的连接模态 (attachment modalities)。信赖方 (Relying Party) 在调用 navigator.credentials.create() 以创建凭据时，使用此项来表达其首选的验证器连接模态。

enum AuthenticatorAttachment {
    "platform",
    "cross-platform"
};

注意：AuthenticatorAttachment 枚举被刻意地不进行引用，请参阅 § 2.1.1 作为 DOMString 类型的枚举。

注意：验证器连接模态选择选项仅在 [[Create]](origin, options, sameOriginWithAncestors) 操作中可用。信赖方 (Relying Party) 可以利用它，例如：确保用户拥有一个用于在其他客户端设备上进行认证的漫游凭据 (roaming credential)；或者专门注册一个平台凭据 (platform credential) 以便在使用特定客户端设备时更容易地进行重新认证。[[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors) 操作没有验证器连接模态选择选项，因此信赖方 (Relying Party) 应接受用户的任何已注册凭据。客户端和用户届时将使用当时可用且方便的任何凭据。

5.4.6. 驻留密钥要求枚举（枚举 ResidentKeyRequirement）

enum ResidentKeyRequirement {
    "discouraged",
    "preferred",
    "required"
};

注意：ResidentKeyRequirement 枚举被刻意地不进行引用，请参阅 § 2.1.1 作为 DOMString 类型的枚举。

此枚举的值描述了信赖方 (Relying Party) 对客户端侧可发现凭据 (client-side discoverable credentials)（曾称为驻留凭据 (resident credentials) 或 驻留密钥 (resident keys)）的要求。

注意：信赖方 (Relying Party) 可以通过查看凭据属性扩展的返回值，并结合为 options.authenticatorSelection.residentKey 提供的值，来获取关于验证器是否创建了客户端侧可发现凭据的信息。当 authenticatorSelection.residentKey 的值为 discouraged 或 preferred 时，这非常有用，因为在这些情况下，验证器有可能创建客户端侧可发现凭据或服务器侧凭据。

5.4.7. 认证传达 (Attestation Conveyance) 偏好枚举（枚举 AttestationConveyancePreference）

WebAuthn 信赖方 (WebAuthn Relying Party) 可以使用 AttestationConveyancePreference 来指定其在凭据生成期间关于认证传达的偏好。

enum AttestationConveyancePreference {
    "none",
    "indirect",
    "direct",
    "enterprise"
};

注意：AttestationConveyancePreference 枚举被刻意地不进行引用，请参阅 § 2.1.1 作为 DOMString 类型的枚举。

5.5. 断言生成的选项（字典 PublicKeyCredentialRequestOptions）

PublicKeyCredentialRequestOptions 字典为 get() 提供其生成断言所需的数据。其 challenge 成员必须存在，而其他成员是可选的。

dictionary PublicKeyCredentialRequestOptions {
    required BufferSource                challenge;
    unsigned long                        timeout;
    USVString                            rpId;
    sequence<PublicKeyCredentialDescriptor> allowCredentials = [];
    DOMString                            userVerification = "preferred";
    AuthenticationExtensionsClientInputs extensions;
};

✔MDN

PublicKeyCredentialRequestOptions/challenge

在所有当前引擎中。

Firefox60+Safari13+Chrome67+

---

Opera54+Edge79+

---

Edge (旧版)无IE无

---

Firefox for Android?iOS Safari13.3+Chrome for Android67+Android WebView67+Samsung InternetNoneOpera Mobile48+

challenge, 类型为 BufferSource

此成员表示选定的验证器在产生身份验证断言 (authentication assertion) 时，连同其他数据一起签名的挑战。请参阅 § 13.4.3 加密挑战的安全注意事项。

✔MDN

PublicKeyCredentialRequestOptions/timeout

在所有当前引擎中。

Firefox60+Safari13+Chrome67+

---

Opera54+Edge79+

---

Edge (旧版)无IE无

---

Firefox for Android?iOS Safari13.3+Chrome for Android67+Android WebView67+Samsung InternetNoneOpera Mobile48+

timeout, 类型为 unsigned long

此可选成员指定调用者愿意等待操作完成的时间（以毫秒为单位）。该值仅作为提示，且可能被客户端覆盖。

✔MDN

PublicKeyCredentialRequestOptions/rpId

在所有当前引擎中。

Firefox60+Safari13+Chrome67+

---

Opera54+Edge79+

---

Edge (旧版)无IE无

---

Firefox for Android?iOS Safari13.3+Chrome for Android67+Android WebView67+Samsung InternetNoneOpera Mobile48+

rpId, 类型为 USVString

此可选成员指定调用者声称的信赖方标识符 (relying party identifier)。如果省略，其值将为 CredentialsContainer 对象关联的相关设置对象的源 (origin) 的有效域 (effective domain)。

✔MDN

PublicKeyCredentialRequestOptions/allowCredentials

在所有当前引擎中。

Firefox60+Safari13+Chrome67+

---

Opera54+Edge79+

---

Edge (旧版)无IE无

---

Firefox for Android?iOS Safari13.3+Chrome for Android67+Android WebView67+Samsung InternetNoneOpera Mobile48+

allowCredentials, 类型为 sequence<PublicKeyCredentialDescriptor>，默认值为 []

此可选成员包含代表调用者可接受的公钥凭据的 PublicKeyCredentialDescriptor 对象列表，按调用者的偏好降序排列（列表中的第一项为首选凭据，依此类推）。

✔MDN

PublicKeyCredentialRequestOptions/userVerification

在所有当前引擎中。

Firefox60+Safari13+Chrome67+

---

Opera54+Edge79+

---

Edge (旧版)无IE无

---

Firefox for Android?iOS Safari13.3+Chrome for Android67+Android WebView67+Samsung InternetNoneOpera Mobile48+

userVerification, 类型为 DOMString，默认值为 "preferred"

此可选成员描述了信赖方 (Relying Party) 关于 get() 操作中用户验证 (user verification) 的要求。该值应当是 UserVerificationRequirement 的成员，但客户端平台必须忽略未知值，将未知值视为如同成员不存在一样。符合条件的验证器被过滤为仅保留能够满足此要求的验证器。

✔MDN

PublicKeyCredentialCreationOptions/extensions

在所有当前引擎中。

Firefox60+Safari13+Chrome67+

---

Opera54+Edge79+

---

Edge (旧版)无IE无

---

Firefox for Android?iOS Safari13.3+Chrome for Android67+Android WebViewNoneSamsung InternetNoneOpera Mobile48+

PublicKeyCredentialRequestOptions/extensions

在所有当前引擎中。

Firefox60+Safari13+Chrome67+

---

Opera54+Edge79+

---

Edge (旧版)无IE无

---

Firefox for Android?iOS Safari13.3+Chrome for Android67+Android WebView67+Samsung InternetNoneOpera Mobile48+

extensions，类型为 AuthenticationExtensionsClientInputs

此可选成员包含请求客户端和验证器执行额外处理的附加参数。例如，如果寻求用户的交易确认，则提示字符串可能会作为扩展被包含在内。

5.6. 使用 AbortSignal 中止操作

鼓励开发人员利用 AbortController 来管理 [[Create]](origin, options, sameOriginWithAncestors) 和 [[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors) 操作。有关详细说明，请参阅 DOM §3.3 在 API 中使用 AbortController 和 AbortSignal 对象一节。

注意：DOM §3.3 在 API 中使用 AbortController 和 AbortSignal 对象一节规定，与 AbortController 集成的 Web 平台 API 必须在设置了中止标志 (aborted flag) 后立即拒绝承诺 (promise)。考虑到 [[Create]](origin, options, sameOriginWithAncestors) 和 [[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors) 方法复杂的继承和并行化结构，这两个 API 的算法通过在三处检查中止标志来履行此要求。对于 [[Create]](origin, options, sameOriginWithAncestors)，首先在 Credential Management 1 §2.5.4 创建凭据中，在调用 [[Create]](origin, options, sameOriginWithAncestors) 之前立即检查中止标志；其次在 § 5.1.3 创建新凭据 - PublicKeyCredential 的 [[Create]](origin, options, sameOriginWithAncestors) 方法中，在验证器会话 (authenticator sessions) 开始之前立即检查；最后在验证器会话期间进行检查。[[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors) 的情况也是如此。

Window 对象的可见性 (visibility) 和焦点 (focus) 状态决定了 [[Create]](origin, options, sameOriginWithAncestors) 和 [[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors) 操作是否应继续。当与 Document 相关联的 Window 对象失去焦点时，应中止 [[Create]](origin, options, sameOriginWithAncestors) 和 [[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors) 操作。

WHATWG HTML 工作组正在讨论是否在浏览上下文获得或失去焦点时提供钩子 (hook)。如果提供了钩子，上述段落将被更新以包含该钩子。有关更多详细信息，请参阅 WHATWG HTML WG 问题 #2711。

5.7. WebAuthn 扩展输入和输出

下文定义了用于传达 WebAuthn 扩展输入和输出的数据类型。

注意：验证器扩展输出作为验证器数据 (Authenticator data) 的一部分进行传达（参见表 1）。

注意：下文定义的数据类型 — AuthenticationExtensionsClientInputs 和 AuthenticationExtensionsClientOutputs — 既适用于注册扩展，也适用于认证扩展。它们名称中的 “Authentication...” 部分应被理解为指代 “WebAuthentication...”

5.7.1. 身份验证扩展客户端输入（字典 AuthenticationExtensionsClientInputs）

dictionary AuthenticationExtensionsClientInputs {
};

这是一个包含零个或多个 WebAuthn 扩展的客户端扩展输入值的字典。

5.7.2. 身份验证扩展客户端输出（字典 AuthenticationExtensionsClientOutputs）

dictionary AuthenticationExtensionsClientOutputs {
};

这是一个包含零个或多个 WebAuthn 扩展的客户端扩展输出值的字典。

5.7.3. 身份验证扩展验证器输入（CDDL 类型 AuthenticationExtensionsAuthenticatorInputs）

AuthenticationExtensionsAuthenticatorInputs = {
  * $$extensionInput .within ( tstr => any )
}

CDDL 类型 AuthenticationExtensionsAuthenticatorInputs 定义了一个 CBOR 映射，其中包含零个或多个 WebAuthn 扩展的验证器扩展输入值。扩展可以按 § 9.3 扩展请求参数中所述添加成员。

此类型不向信赖方 (Relying Party) 公开，而是由客户端和验证器使用。

5.7.4. 身份验证扩展验证器输出（CDDL 类型 AuthenticationExtensionsAuthenticatorOutputs）

AuthenticationExtensionsAuthenticatorOutputs = {
  * $$extensionOutput .within ( tstr => any )
}

CDDL 类型 AuthenticationExtensionsAuthenticatorOutputs 定义了一个 CBOR 映射，其中包含零个或多个 WebAuthn 扩展的验证器扩展输出值。扩展可以按 § 9.3 扩展请求参数中所述添加成员。

5.8. 支撑数据结构

公钥凭据类型使用在支撑规范中指定的某些数据结构。具体如下。

5.8.1. WebAuthn 签名中使用的客户端数据（字典 CollectedClientData）

客户端数据 (client data) 代表了 WebAuthn 信赖方 (WebAuthn Relying Party) 和客户端的上下文绑定。它是一个键值映射，其键为字符串。值可以是任何在 JSON 中具有有效编码的类型。其结构由以下 Web IDL 定义。

注意：CollectedClientData 未来可能会被扩展。因此，在解析时，必须能够容忍未知键和键的任何重新排序。另请参阅 § 5.8.1.2 受限验证算法。

dictionary CollectedClientData {
    required DOMString           type;
    required DOMString           challenge;
    required DOMString           origin;
    boolean                      crossOrigin;
    TokenBinding                 tokenBinding;
};

dictionary TokenBinding {
    required DOMString status;
    DOMString id;
};

enum TokenBindingStatus { "present", "supported" };

5.8.1.1. 序列化

CollectedClientData 的序列化是JSON 序列化为字节算法的一个子集。也就是说，它产生 CollectedClientData 的有效 JSON 编码，但也提供了验证器可能利用的附加结构，以避免集成完整的 JSON 解析器。虽然建议验证器执行标准 JSON 解析，但它们可以在完整 JSON 解析器过大的上下文中使用下方的更有限的算法。此验证算法仅需要base64url 编码、字节串拼接（可以通过写入固定模板来实现）以及三个条件检查（假设输入已知不需要转义）。

该序列化算法通过将连续的字节串追加到一个最初为空的部分结果中，直到获得完整结果为止。

1. 令 result 为一个空字节串。

2. 将 0x7b2274797065223a ({"type":) 追加到 result。

3. 将 CCDToString(type) 追加到 result。

4. 将 0x2c226368616c6c656e6765223a (,"challenge":) 追加到 result。

5. 将 CCDToString(challenge) 追加到 result。

6. 将 0x2c226f726967696e223a (,"origin":) 追加到 result。

7. 将 CCDToString(origin) 追加到 result。

8. 将 0x2c2263726f73734f726967696e223a (,"crossOrigin":) 追加到 result。

9. 如果 crossOrigin 不存在，或者为 false

   1. 将 0x66616c7365 (false) 追加到 result。

10. 否则

    1. 否则，将 0x74727565 (true) 追加到 result。

11. 创建 CollectedClientData 的临时副本，并移除字段 type、challenge、origin 和 crossOrigin（如果存在）。

12. 如果临时副本中没有剩余字段，则

    1. 将 0x7d (}) 追加到 result。

13. 否则

    1. 对临时副本调用序列化 JSON 为字节以产生字节串 remainder。

    2. 将 0x2c (,) 追加到 result。

    3. 从 remainder 中移除前导字节。

    4. 将 remainder 追加到 result。

14. 序列化的结果即为 result 的值。

上述算法中使用函数 CCDToString，定义如下：

1. 令 encoded 为一个空字节串。

2. 将 0x22 (") 追加到 encoded。

3. 对给定对象调用 ToString 以转换为字符串。

4. 对于结果字符串中的每个码点，如果码点

   在集合 {U+0020, U+0021, U+0023–U+005B, U+005D–U+10FFFF} 中

   将该码点的 UTF-8 编码追加到 encoded。

   是 U+0022

   将 0x5c22 (\") 追加到 encoded。

   是 U+005C

   将 0x5c5c (\\) 追加到 encoded。

   否则

   将 0x5c75 (\u) 追加到 encoded，后跟四个小写十六进制数字，当解释为十六进制数时，代表该码点。

5. 将 0x22 (") 追加到 encoded。

6. 此函数的结果即为 encoded 的值。

5.8.1.2. 受限验证算法

如果验证器无法支持完整的 JSON 解析器，则可以使用以下算法来验证编码的 CollectedClientData：

1. 算法的输入为：

   1. 一个字节串 clientDataJSON，包含 clientDataJSON —— 即待验证的序列化 CollectedClientData。

   2. 一个包含预期 type 的字符串 type。

   3. 一个字节串 challenge，包含在 PublicKeyCredentialRequestOptions 或 PublicKeyCredentialCreationOptions 中给出的挑战字节串。

   4. 一个包含预期 origin 的字符串 origin，即向用户代理发出请求的源。

   5. 一个布尔值 crossOrigin，仅当请求应该在跨源 iframe 内执行时为 true。

2. 令 expected 为一个空字节串。

3. 将 0x7b2274797065223a ({"type":) 追加到 expected。

4. 将 CCDToString(type) 追加到 expected。

5. 将 0x2c226368616c6c656e6765223a (,"challenge":) 追加到 expected。

6. 对 challenge 执行base64url 编码以产生字符串 challengeBase64。

7. 将 CCDToString(challengeBase64) 追加到 expected。

8. 将 0x2c226f726967696e223a (,"origin":) 追加到 expected。

9. 将 CCDToString(origin) 追加到 expected。

10. 将 0x2c2263726f73734f726967696e223a (,"crossOrigin":) 追加到 expected。

11. 如果 crossOrigin 为 true

    1. 将 0x74727565 (true) 追加到 expected。

12. 否则（即 crossOrigin 为 false）

    1. 将 0x66616c7365 (false) 追加到 expected。

13. 如果 expected 不是 clientDataJSON 的前缀，则验证失败。

14. 如果 clientDataJSON 的长度不至少比 expected 长一个字节，则验证失败。

15. 如果在等于 expected 长度的偏移量处 clientDataJSON 的字节

    是 0x7d

    验证成功。

    是 0x2c

    验证成功。

    否则

    验证失败。

5.8.1.3. 未来发展

为了保持与受限验证算法的兼容性，本规范的未来版本不得从 CollectedClientData 中移除 type、challenge、origin 或 crossOrigin 中的任何字段。它们也不得更改序列化算法以更改这些字段被序列化的顺序。

如果将附加字段添加到 CollectedClientData，那么在上述两个算法更新以包含它们之前，使用受限验证算法的验证器将无法考量这些字段。一旦发生此类更新，添加的字段将继承与上一段所述相同的限制。此类算法更新必须适应以前版本产生的序列化结果。也就是说，验证算法必须处理这样一个事实：如果由运行先前版本的用户代理生成，第五个键值对可能不会出现在第五位（或者根本不出现）。

5.8.2. 凭据类型枚举（枚举 PublicKeyCredentialType）

enum PublicKeyCredentialType {
    "public-key"
};

注意：PublicKeyCredentialType 枚举被刻意地不进行引用，请参阅 § 2.1.1 作为 DOMString 类型的枚举。

5.8.3. 凭据描述符（字典 PublicKeyCredentialDescriptor）

dictionary PublicKeyCredentialDescriptor {
    required DOMString                    type;
    required BufferSource                 id;
    sequence<DOMString>                   transports;
};

此字典包含调用者在将公钥凭据作为 create() 或 get() 方法的输入参数进行引用时所指定的属性。它映射了由后者方法返回的 PublicKeyCredential 对象的字段。

5.8.4. 验证器传输枚举 (enum AuthenticatorTransport)

enum AuthenticatorTransport {
    "usb",
    "nfc",
    "ble",
    "internal"
};

注意：AuthenticatorTransport 枚举被特意不进行引用，参见 § 2.1.1 作为 DOMString 类型的枚举。

5.8.5. 密码算法标识符 (typedef COSEAlgorithmIdentifier)

typedef long COSEAlgorithmIdentifier;

注意：使用这些算法正确实现签名验证需要进行许多检查。其中之一是：在处理未压缩的椭圆曲线点时，实现应检查该点是否确实位于曲线上。之所以强调此检查，是因为它被认为在密码库和其他代码之间容易出现疏漏，存在特殊风险。

5.8.6. 用户验证要求枚举 (enum UserVerificationRequirement)

enum UserVerificationRequirement {
    "required",
    "preferred",
    "discouraged"
};

WebAuthn 信赖方可能要求对某些操作进行用户验证，而对其他操作则不需要，并可使用此类型来表达其需求。

注意：UserVerificationRequirement 枚举被特意不进行引用，参见 § 2.1.1 作为 DOMString 类型的枚举。

5.9. 权限策略集成

本规范定义了一个由策略控制的功能，其特征标识符标记为 "publickey-credentials-get"。其默认允许列表为 'self'。[Permissions-Policy]

Document 的权限策略决定了该文档中的任何内容是否被允许成功调用 Web Authentication API，即通过 navigator.credentials.get({publicKey:..., ...}) 调用。如果该策略在任何文档中被禁用，则该文档中的任何内容都将不被允许使用上述方法：尝试这样做将返回一个错误。

注意：[CREDENTIAL-MANAGEMENT-1] 中指定的算法执行实际的权限策略评估。这是因为此类策略评估需要在能够访问当前设置对象时发生。[[Create]](origin, options, sameOriginWithAncestors) 和 [[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors) 内部方法由于是在并行执行（通过 [CREDENTIAL-MANAGEMENT-1] 中指定的算法），因此无法进行此类访问。

5.10. 在 iframe 元素中使用 Web Authentication

Web Authentication API 在跨源 iframe 中默认禁用。要覆盖此默认策略并指示允许跨源 iframe 调用 Web Authentication API 的 [[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors) 方法，请在 iframe 元素上指定 allow 属性，并在 allow 属性的值中包含 publickey-credentials-get 特征标识符标记。