凭证管理 一级

1. 简介

本节为非规范性内容。

登录网站比应有的要困难得多。用户代理处于一个独特的位置，能够在多方面改善这种体验，大多数现代用户代理已经通过在浏览器中原生提供某种程度的 credential management 来认识到这一点。例如，用户可以为网站保存用户名和密码；那些 凭证 随后会自动填充到登录表单中，尽管成功率各不相同。

属性 autocomplete 提供了一种声明性机制，网站可以通过它与用户代理协作——通过将特定字段标记为 "username" 或 "password"——以提高后者检测并填写登录表单的能力；用户代理还实现了各种检测启发式方法，以便与那些没有花时间在标记中提供这些细节的网站配合。

虽然这种启发式与声明式检测的组合运行得相对较好，但现状仍然存在一些检测困难的重大空白。具有不常见登录机制的网站（例如通过 XMLHttpRequest 提交凭证）很难可靠检测，用户希望使用联合身份提供者进行认证的情况也越来越常见。允许网站更直接地与用户代理的 凭证管理器 交互，一方面可以使 凭证管理器 更加准确，另一方面也能帮助用户进行联合登录。

这些用例在 § 1.1 Use Cases 和 Credential Management: Use Cases and Requirements 中有更详细的探讨；本规范通过定义一个凭证管理器 API（Credential Manager API），尝试解决该文档概述的许多需求，网站可以使用该 API 为用户请求 凭证，并在用户成功登录时请求用户代理持久化这些凭证。

注意： 这里定义的 API 有意保持小而简单：它并不打算自身提供认证功能，而仅限于向现有用户代理实现的 凭证管理器 提供一个接口。该功能在 现在 就已很有价值，而不需要供应商或作者付出大量额外努力。当然，仍有许多可以做的事情。参见 § 9 Future Work，其中列出了一些我们暂时搁置、但可在未来 API 迭代中继续探讨的想法。

1.1. 使用场景

现代用户代理通常都为用户在登录网站时提供保存密码的能力，并且在用户再次访问网站时能全自动或半自动地填充这些密码。从网站的角度来看，这一行为完全不可见：网站不知道密码已被存储，也不会收到密码被填充的通知。这既有好处，也有不足。一方面，用户代理的密码管理器无论网站是否配合都能工作，这对用户来说非常好。另一方面，密码管理器的行为是一套脆弱且专有的启发式组合，旨在检测和填充登录表单、密码更改表单等。

现状中有几个突出问题值得关注：

• 用户代理在帮助用户使用联合身份提供者方面非常吃力。检测用户名/密码表单提交较为直接，但检测第三方登录则很难做到可靠。若网站能帮助用户代理理解联合登录相关的重定向意图，将会非常有益。

• 同样，用户代理在检测比普通用户名/密码表单更复杂的登录机制时也很困难。作者越来越多地通过 XMLHttpRequest 或类似机制异步登录用户，以改善体验并提升展示控制。对用户来说这很好，但用户代理却难以将其集成到密码管理器中。若网站能帮助用户代理理解他们选择的登录机制，将会非常有益。

• 最后，如果网站能明确告知用户代理凭证已更改，密码更改的支持也会更好。

2. 核心 API

从开发者的角度来看，凭证是一个对象，允许开发者为特定操作做出认证决策。本节定义了一个通用且可扩展的 Credential 接口，作为本规范及其他文档中定义的凭证的基类，并提供一组挂载在 navigator.credentials.* 上的 API，供开发者获取凭证。

不同的 凭证类型 都以接口的形式呈现给 JavaScript，这些接口直接或间接地继承自 Credential 接口。本规范定义了两个此类接口：PasswordCredential 和 FederatedCredential。其他规范，如 [WEBAUTHN]，定义了其他凭证类型。

某个 凭证对于特定 源（origin） 是“有效”的，指的是该凭证可被该源接受用于认证。即使某一时刻的凭证有效，UA 也不能假定未来该凭证仍然有效，原因有以下几点：

1. 如果账户持有人更改了密码，密码凭证可能会变为无效。

2. 通过短信收到的令牌生成的凭证通常只在一次使用时有效。

一次性 凭证由 凭证源生成，凭证源可能是私钥、访问联合账户、或某个手机号接收短信的能力等。凭证源不会暴露给 Javascript，也不会在本规范中明确表示。为统一模型，我们把密码视为一种凭证源，通过复制生成密码凭证。

虽然 UA 不能假定一个有效凭证再次使用时仍然有效，也不能假定生成过有效凭证的凭证源未来能够再次生成有效凭证，但后者的可能性更大。通过记录（使用 store()） 过去哪些凭证是有效的，UA 能更好地在将来为用户提供有效的凭证源选择。

2.1. 基础设施

凭证管理器是一种应用程序、硬件设备或服务，用于存储、组织、管理并允许选择凭证。典型的凭证管理器包括数字钱包、密码管理器，以及passkey管理器。

用户代理必须在内部提供一个凭证存储，它是一种供应商特定的不透明存储机制，用于记录哪些凭证已被激活。它为凭证的访问和持久化提供以下功能：

1. 存储凭证以便后续检索。此操作接受一个凭证，并将其插入凭证存储中。

2. 检索凭证列表。此操作接受任意筛选条件，并返回与筛选条件匹配的一组凭证。

3. 修改凭证。此操作接受一个凭证，并覆盖已有凭证在凭证存储中的状态。

此外，凭证存储应为源维护一个prevent silent access 标志（除非另有说明，默认设为true）。如果该标志为true，则该源需要用户介入。

Note: 关于用户介入的重要性，详见§ 5 用户介入。

Note: 凭证存储是用户代理实现本文档所述 API 的内部实现细节，不会直接暴露给 Web。其他文档可能会为特定凭证类型规定更多能力。

本文档在其算法和正文中使用的一些基础概念依赖 Infra Standard [INFRA]。

每个环境设置对象都有一个相关联的激活凭证类型，它是一个最初为空的集合。

2.1.1. 基础设施算法

2.1.1.1. 与其祖先同源

当 环境设置对象 (settings) 满足以下算法返回 true 时， 称其为 与其祖先同源：

1. 如果 settings 的 相关全局对象没有 关联的 Document，返回 false。

2. 令 document 为 settings 的 相关全局对象的 关联的 Document。

3. 如果 document 没有 浏览上下文，返回 false。

4. 令 origin 为 settings 的 源。

5. 令 navigable 为 document 的 节点可导航对象。

6. 当 navigable 有非空 父级 时：

   1. 令 navigable 为 navigable 的 父级。

   2. 如果 navigable 的 活动文档的 源与 origin 不同源，返回 false。

7. 返回 true。

2.1.2. 凭证类型注册表

该注册表将凭证类型（即 [[type]] 的值）映射为与指定凭证类型相关的各种值。例如：选项成员标识符 （正式来说，是 字典成员的标识符），用于 CredentialCreationOptions 和 CredentialRequestOptions （即“选项字典”）的规范。

注意： 此注册表被 相关凭证接口对象算法使用。

2.1.2.1. 注册项要求与更新流程

• 每个凭证类型在所有凭证类型集合中必须唯一。

• 每一注册项必须声明凭证规范扩展 CredentialCreationOptions 和 CredentialRequestOptions 时使用的字典成员标识符（在注册表中称为选项成员标识符）。

• 每一注册项必须声明该凭证类型所对应的适用接口对象标识符。

• 每一注册项必须声明在为某一凭证类型执行请求凭证时所用的获取权限策略权限，如未指定权限策略则为 null。

• 每一注册项必须声明在为某一凭证类型执行创建凭证时所用的创建权限策略权限，如未指定权限策略则为 null。

• 每一注册项必须包含一个公开规范的链接，规范需定义凭证类型及字典成员标识符。

• 每一注册项的规范必须包含申请者的联系方式。

对本注册表的更新包括对某一凭证类型注册项的新增、修改或删除。任何人都可以通过向 webappsec-credential-management 仓库提交 pull request 的方式申请更新。 Web 应用安全工作组会将其列入即将召开的会议议程并通知申请者。 申请的审议和处理由 W3C Web 应用安全工作组协商决定。 主席随后会通知申请者结果并相应地更新注册表。

2.2. Credential 接口

[Exposed=Window, SecureContext]
interface Credential {
  readonly attribute USVString id;
  readonly attribute DOMString type;
  static Promise<boolean> isConditionalMediationAvailable();
  static Promise<undefined> willRequestConditionalCreation();
};

和 Tobie/Dominic 讨论一下 接口对象相关内容，这里以及 § 2.5.1 请求凭证 等部分。我不确定术语是否正确。也许是 接口原型对象？

部分 Credential 对象是 绑定源的：它们包含一个名为 [[origin]] 的内部槽， 用于存储该 Credential 可能在其上有效的 源。

2.2.1. Credential 内部方法

Credential 接口对象包含多个内部方法，用于检索和存储 Credential 对象，默认实现为本节所述的“空操作”。

除非另有说明，为继承自 Credential 的接口创建的每个 接口对象，都必须为这些内部方法至少提供一种实现，并根据 凭证类型的需要，覆盖 Credential 的默认实现。例如，见 § 3.2 PasswordCredential 接口、§ 4.1 FederatedCredential 接口，以及 [WEBAUTHN]。

2.2.1.1. [[CollectFromCredentialStore]] 内部方法

Credential 的默认实现 [[CollectFromCredentialStore]](origin, options, sameOriginWithAncestors)：

1. 返回空集合。

2.2.1.2. [[DiscoverFromExternalSource]] 内部方法

Credential 的默认实现 [[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors)：

1. 返回 null。

2.2.1.3. [[Store]] 内部方法

Credential 的默认实现 [[Store]](credential, sameOriginWithAncestors)：

1. 抛出 NotSupportedError。

2.2.1.4. [[Create]] 内部方法

• 创建一个 Credential，或

• 未创建凭证并返回 null，或

• 若因异常情况创建失败则抛出错误（例如选项不正确会导致抛出 TypeError）。

创建 Credential 时，将返回一个接受 全局对象并返回一个继承自 Credential 的 接口对象的算法。该算法必须由 任务调用。

注意： 此算法的步骤按每种 凭证类型分别定义。

Credential 的默认实现 [[Create]](origin, options, sameOriginWithAncestors)：

1. 返回 null。

2.2.2. CredentialUserData 混入

部分 Credential 对象包含旨在为用户在 凭证选择器中提供友好名称和图标，以便用户更易于区分的数据显示：

[SecureContext]
interface mixin CredentialUserData {
  readonly attribute USVString name;
  readonly attribute USVString iconURL;
};

2.3. navigator.credentials

开发者通过挂载在 CredentialsContainer 接口上的方法检索 Credential 并与用户代理的 凭证存储交互，该接口作为 Navigator 对象上的 navigator.credentials 属性。

partial interface Navigator {
  [SecureContext, SameObject] readonly attribute CredentialsContainer credentials;
};

credentials 属性必须返回与 活动文档的 浏览上下文关联的 CredentialsContainer。

注意：如 § 6.3 不安全的站点所述，凭证管理 API 仅在 安全上下文中暴露。

[Exposed=Window, SecureContext]
interface CredentialsContainer {
  Promise<Credential?> get(optional CredentialRequestOptions options = {});
  Promise<undefined> store(Credential credential);
  Promise<Credential?> create(optional CredentialCreationOptions options = {});
  Promise<undefined> preventSilentAccess();
};

dictionary CredentialData {
  required USVString id;
};

2.3.1. CredentialRequestOptions 字典

为了通过 Credential 的 get() 方法检索凭证， 调用方需要在 CredentialRequestOptions 对象中指定一些参数。

注意： CredentialRequestOptions 字典是一个扩展点。当有新的凭证类型引入且需要选项时，这些字典类型将会添加到该字典中，以便可以传递给请求。参见 § 8.2 扩展点。

dictionary CredentialRequestOptions {
  CredentialMediationRequirement mediation = "optional";
  AbortSignal signal;
};

2.3.2. 调解要求

通过 get(options) 或 create(options) 发起请求时， 开发者可通过选择合适的 CredentialMediationRequirement 枚举值，为每次请求设置 用户介入的要求。

注意：§ 5 用户介入章节有更多关于该概念的介绍，以及其对用户代理处理特定源请求的影响。

enum CredentialMediationRequirement {
  "silent",
  "optional",
  "conditional",
  "required"
};

2.3.2.1. 示例

window.addEventListener('load', async () => {
  const credentials = await navigator.credentials.get({
    ...,
    mediation: 'silent'
  });
  if (credentials) {
    // 太棒了！用这些凭证让用户登录吧！
  }
});

document.querySelector('#sign-in').addEventListener('click', async () => {
  const credentials = await navigator.credentials.get({
    ...,
    mediation: 'optional'
  });
  if (credentials) {
    // 太棒了！用这些凭证让用户登录吧！
  }
});

document.querySelector('#important-form').addEventListener('submit', async () => {
  const credentials = await navigator.credentials.get({
    ...,
    mediation: 'required'
  });
  if (credentials) {
    // 验证凭证是否允许访问，无效则取消提交。
  } else {
    e.preventDefault();
  }
});

document.querySelector('#switch-button').addEventListener('click', e => {
  var c = await navigator.credentials.get({
    ...,
    mediation: 'required'
  });
  if (c) {
    // 用 |c| 登录用户。
  }
});

2.4. CredentialCreationOptions 字典

为了通过 Credential 的 create() 方法创建凭证， 调用方需要在 CredentialCreationOptions 对象中指定一些参数。

注意： CredentialCreationOptions 字典是一个扩展点。当有新的凭证类型引入时，它们会添加到该字典中，以便可以传递给创建方法。参见 § 8.2 扩展点，以及本文档中的扩展：§ 3.2 PasswordCredential 接口 和 § 4.1 FederatedCredential 接口。

dictionary CredentialCreationOptions {
  CredentialMediationRequirement mediation = "optional";
  AbortSignal signal;
};

2.5. 算法

2.5.1. 请求 Credential

请求凭证算法接受一个 CredentialRequestOptions （options），并返回一个 Promise ，如果能明确获取凭证则解析为 Credential，否则解析为 null。

1. 令 settings 为 当前设置对象。

2. 断言：settings 是 安全上下文。

3. 令 document 为 settings 的 相关全局对象的 关联文档。

4. 如果 document 不是 完全激活状态，则返回 一个被拒绝的 promise，原因为 "InvalidStateError" DOMException。

5. 如果 options.signal 已被 中止， 则返回 一个被拒绝的 promise， 原因为 options.signal 的 中止原因。

6. 令 interfaces 为 options 的 相关凭证接口对象。

7. 如果 interfaces 是 空集合，则返回 一个被拒绝的 promise，原因为 "NotSupportedError" DOMException。

8. 遍历 interfaces 的每个 interface：

   1. 如果 options.mediation 为 conditional 且 interface 不支持 conditional 用户介入，则返回 一个被拒绝的 promise，原因为 "TypeError" DOMException。

   2. 如果 settings 的 激活凭证类型 包含 interface 的 [[type]]， 则返回 一个被拒绝的 promise，原因为 "NotAllowedError" DOMException。

   3. 将 interface 的 [[type]] 添加到 settings 的 激活凭证类型中。

9. 令 origin 为 settings 的 源。

10. 令 sameOriginWithAncestors 为 true，如果 settings 与其祖先同源，否则为 false。

11. 遍历 options 的 相关凭证接口对象：

    1. 令 permission 为 interface 的 [[type]] 获取权限策略。

    2. 如果 permission 为 null，跳过。

    3. 如果 document 不允许 使用 permission，则返回 一个被拒绝的 promise，原因为 "NotAllowedError" DOMException。

12. 令 p 为 一个新的 promise。

13. 并行运行以下步骤：

    1. 令 credentials 为 从凭证存储收集凭证的结果，参数为 origin、options 和 sameOriginWithAncestors。

    2. 如果 credentials 是 异常，拒绝 p，原因为 credentials。

    3. 如果以下所有条件成立，则解析 p 为 credentials[0] 并跳过剩余步骤：

       1. credentials 的 长度为 1

       2. origin 不 需要用户介入

       3. options 可先验匹配

       4. options.mediation 不是 "required"。

       5. options.mediation 不是 "conditional"。

       这也许不是最佳模型。如果一个网站希望同时接受用户名/密码和 webauthn 类型凭证，但不想强制使用选择器，对于只用前者且希望保持登录状态的用户会更友好。

    4. 如果 options 的 mediation 为 "silent"， 解析 p 为 null，并跳过剩余所有步骤。

    5. 令 result 为 请求用户选择凭证的结果，参数为 options 和 credentials。

    6. 如果 result 是 接口对象：

       1. 将 result 设为执行 result 的 [[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors) 结果， 参数为 origin、options 和 sameOriginWithAncestors。

          如果抛出 异常：

          1. 令 e 为抛出的 异常。

          2. 在 global 的 DOM 操作任务源 上排队一个任务以运行以下子步骤：

             1. 拒绝 p，原因为 e。

          3. 终止这些子步骤。

    7. 断言：result 为 null，或为 Credential。

    8. 如果 result 是 Credential， 解析 p 为 result。

    9. 如果 result 为 null 且 options.mediation 不是 conditional， 解析 p 为 result。

       注意：如果 options.mediation 为 conditional 且发现凭证为 null， promise p 不会被解析。

14. 当 p 被解决时，执行：

    1. 遍历 interfaces 的每个 interface：

       1. 移除 interface 的 [[type]] 从 settings 的 激活凭证类型中。

15. 返回 p。

2.5.2. 从凭证存储收集 Credential

给定一个 origin（origin）， 一个 CredentialRequestOptions （options），以及一个仅当调用上下文 与其祖先同源时为 true 的布尔值 （sameOriginWithAncestors），用户代理可以 从凭证存储收集 Credential， 返回一组本地存储且与 options 的筛选条件匹配的 Credential 对象。如果没有可用的 Credential 对象，返回集合为空：

1. 令 possible matches 为一个空集合。

2. 遍历 options 的 相关凭证接口对象 的每个 interface：

   1. 令 r 为执行 interface 的 [[CollectFromCredentialStore]](origin, options, sameOriginWithAncestors) 内部方法，参数为 origin、options 和 sameOriginWithAncestors 的结果。如果抛出 异常，则重新抛出该异常。

   2. 断言：r 是一组 接口对象列表。

   3. 遍历 r 的每个 c：

      1. 将 c 添加到 possible matches。

3. 返回 possible matches。

2.5.3. 存储 Credential

存储 Credential 算法接受一个 Credential （credential），并返回一个 Promise ，该 Promise 在对象持久化到 凭证存储后解析。

1. 令 settings 为 当前设置对象。

2. 断言：settings 是 安全上下文。

3. 如果 settings 的 相关全局对象的 关联文档不是 完全激活状态， 则返回 一个被拒绝的 promise，原因为 "InvalidStateError" DOMException。

4. 令 sameOriginWithAncestors 为 true，如果 当前设置对象 与其祖先同源，否则为 false。

5. 令 p 为 一个新的 promise。

6. 如果 settings 的 激活凭证类型 包含 credential 的 [[type]]， 则返回 一个被拒绝的 promise，原因为 "NotAllowedError" DOMException。

7. 将 credential 的 [[type]] 添加到 settings 的 激活凭证类型中。

8. 并行运行以下步骤：

   1. 执行 credential 的 接口对象的 [[Store]](credential, sameOriginWithAncestors) 内部方法，参数为 credential 和 sameOriginWithAncestors。

      如果抛出 异常：

      1. 令 e 为抛出的 异常。

      2. 在 global 的 DOM 操作任务源 上排队一个任务以运行以下子步骤：

         1. 拒绝 p，原因为 e。

      否则，解析 p 为 undefined。

9. 当 p 被解决时，执行：

   1. 移除 credential 的 [[type]] 从 settings 的 激活凭证类型中。

10. 返回 p。

2.5.4. 创建 Credential

创建 Credential算法接受一个 CredentialCreationOptions （options），并返回一个 Promise ，如果可以根据所提供的选项创建凭证，则解析为 Credential，否则解析为 null。在异常情况下， Promise 可能会因相应异常而拒绝：

1. 令 settings 为 当前设置对象。

2. 断言：settings 是 安全上下文。

3. 令 global 为 settings 的 全局对象。

4. 令 document 为 相关全局对象的 关联文档。

5. 如果 document 不是 完全激活状态，则返回 一个被拒绝的 promise，原因为 "InvalidStateError" DOMException。

6. 令 sameOriginWithAncestors 为 true，如果 当前设置对象 与其祖先同源，否则为 false。

7. 令 interfaces 为 集合，其中元素为 options 的 相关凭证接口对象。

8. 如果出现如下任一情况，则返回 一个被拒绝的 promise NotSupportedError：

   1. global 没有 关联文档。

   2. interfaces 的 长度大于 1。

      注意：未来可能会放宽此限制，让用户代理帮助用户在多种凭证类型中选择，支持“注册”场景。当前仅限字典为单一条目。

9. 遍历 interfaces 的每个 interface：

   1. 令 permission 为 interface 的 [[type]] 创建权限策略。

   2. 如果 permission 为 null，跳过。

   3. 如果 document 不允许 使用 permission，则返回 一个被拒绝的 promise，原因为 "NotAllowedError" DOMException。

10. 如果 options.signal 已被 中止， 则返回 一个被拒绝的 promise， 原因为 options.signal 的 中止原因。

11. 令 type 为 interfaces[0] 的 [[type]]。

12. 如果 settings 的 激活凭证类型 包含 type，则返回 一个被拒绝的 promise，原因为 "NotAllowedError" DOMException。

13. 将 type 添加到 settings 的 激活凭证类型中。

14. 令 origin 为 settings 的 源。

15. 令 p 为 一个新的 promise。

16. 并行运行以下步骤：

    1. 令 r 为执行 interfaces[0] 的 [[Create]](origin, options, sameOriginWithAncestors) 内部方法，参数为 origin、options 和 sameOriginWithAncestors 的结果。

       如果抛出 异常：

       1. 令 e 为抛出的 异常。

       2. 在 global 的 DOM 操作任务源 上排队一个任务以运行以下子步骤：

          1. 拒绝（Reject） p，原因为 e。

       3. 终止这些子步骤。

    2. 如果 r 是 Credential 或 null，解析 p，值为 r，并终止这些子步骤。

    3. 断言：r 为一个算法（见 § 2.2.1.4 [[Create]] 内部方法）。

    4. 在 global 的 DOM 操作任务源 上排队一个任务以运行以下子步骤：

       1. 解析（Resolve） p，其结果为在 global 上对 promise-calling r 的调用。

17. 当 p 被解决时，执行：

    1. 移除 type 从 settings 的 激活凭证类型中。

18. 返回 p。

2.5.5. 防止静默访问

防止静默访问算法接受一个环境设置对象（settings），并返回一个 Promise ，该 Promise 在 防止静默访问标志持久化到凭证存储后解析。

1. 令 origin 为 settings 的 源。

2. 如果 settings 的 相关全局对象的 关联文档不是 完全激活状态， 则返回 一个被拒绝的 promise，原因为 "InvalidStateError" DOMException。

3. 令 p 为 一个新的 promise。

4. 并行运行以下步骤：

   1. 在凭证存储中设置 origin 的 防止静默访问标志。

   2. 解析 p，值为 undefined。

5. 返回 p。

3. 密码凭证

无论好坏，许多网站都依赖用户名/密码对作为认证机制。 PasswordCredential 接口是一种凭证，用于实现该场景，既可以存储用户名和密码，也可以存储有助于用户在凭证选择器中选中正确账号的元数据。

3.1. 示例

3.1.1. 基于密码的登录

navigator.credentials
  .get({ 'password': true })
  .then(credential => {
    if (!credential) {
      // 用户没有为此站点保存凭证，或拒绝分享。此处可以回退到普通登录表单。
      return;
    }
    if (credential.type == 'password') {
      var form = new FormData();
      form.append('username_field', credential.id);
      form.append('password_field', credential.password);
      var opt = {
        method: 'POST',
        body: form,
        credentials: 'include'  // 发送 cookie。
      };
      fetch('https://example.com/loginEndpoint', opt)
        .then(function (response) {
          if (/* |response| 表示登录成功 */) {
            // 记录凭证有效。见下方说明。
            navigator.credentials.store(credential);
            // 通知用户登录成功！执行登录后操作，比如跳转到登陆页面 location.href = '/signed-in-experience'。
          } else {
            // 回退到普通登录表单。
          }
        });
    }
  });

navigator.credentials
  .get({ 'password': true })
  .then(credential => {
    if (!credential) {
      return; // 同上...
    }
    if (credential.type === 'password') {
      document.querySelector('input[name=username_field]').value =
        credential.id;
      document.querySelector('input[name=password_field]').value =
        credential.password;
      document.getElementById('myform').submit();
    }
  });

注意：用户代理展示的凭证选择器可能允许用户选择实际上并未为当前源保存的凭证。例如，在登录 https://www.example.com 时，可能会展示 https://m.example.com 的凭证（见 § 6.1 跨域凭证访问），或者允许用户现场创建新凭证。开发者可以通过每次成功使用凭证后都调用 store() ，即使刚刚通过 get() 获取了凭证，也可以优雅处理这种不确定性：如果该凭证尚未为当前源存储，用户将有机会进行存储；如果已存储，则不会弹窗提示用户。

3.1.2. 登录后确认

为了确保用户在成功登录后能够保存新凭证，可以将凭证传递给 store()。

<form action="https://example.com/login" method="POST" id="theForm">
  <label for="username">用户名</label>
  <input type="text" id="username" name="username" autocomplete="username">
  <label for="password">密码</label>
  <input type="password" id="password" name="password" autocomplete="current-password">
  <input type="submit">
</form>

document.querySelector('#theForm').addEventListener('submit', e => {
    if (window.PasswordCredential) {
      e.preventDefault();

      // 用触发 "submit" 事件的 PasswordCredential 构造一个新的 HTMLFormElement，
      // 会自动抓取带有 "username" 和 "current-password" autocomplete 属性的字段值：
      var c = new PasswordCredential(e.target);

      // fetch 表单的 action URL，并将新凭证对象作为 FormData 传递。如果响应表示登录成功，通知用户代理以便后续存储密码：
      var opt = {
        method: 'POST',
        body: new FormData(e.target),
        credentials: 'include'  // 发送 cookie。
      };
      fetch(e.target.action, opt).then(r => {
        if (/* |r| 是 "成功" Response */)
          navigator.credentials.store(c);
      });
    }
});

3.1.3. 修改密码

同样的存储机制可用于“修改密码”，无需任何修改：当用户更改凭证时，网站可通知用户代理用户已用新凭证成功登录。用户代理随后可以更新其存储的凭证：

<form action="https://example.com/changePassword" method="POST" id="theForm">
  <input type="hidden" name="username" autocomplete="username" value="user">
  <label for="password">新密码</label>
  <input type="password" id="password" name="password" autocomplete="new-password">
  <input type="submit">
</form>

document.querySelector('#theForm').addEventListener('submit', e => {
  if (window.PasswordCredential) {
    e.preventDefault();

    // 用触发 "submit" 事件的 PasswordCredential 构造一个新的 HTMLFormElement，
    // 会自动抓取带有 "username" 和 "new-password" autocomplete 属性的字段值：
    var c = new PasswordCredential(e.target);

    // fetch 表单的 action URL，并将新凭证对象作为 FormData 传递。如果响应表示成功，通知用户代理以便后续存储密码：
    var opt = {
      method: 'POST',
      body: new FormData(e.target),
      credentials: 'include'  // 发送 cookie。
    };
    fetch(e.target.action, opt).then(r => {
      if (/* |r| 是 "成功" Response */)
        navigator.credentials.store(c);
    });
  }
});

3.2. PasswordCredential 接口

[Exposed=Window,
 SecureContext]
interface PasswordCredential : Credential {
  constructor(HTMLFormElement form);
  constructor(PasswordCredentialData data);
  readonly attribute USVString password;
};
PasswordCredential includes CredentialUserData;

partial dictionary CredentialRequestOptions {
  boolean password = false;
};

PasswordCredential 对象可通过 navigator.credentials.create() 显式传入 PasswordCredentialData 字典或根据 HTMLFormElement 的可提交元素内容创建。

dictionary PasswordCredentialData : CredentialData {
  USVString name;
  USVString iconURL;
  required USVString origin;
  required USVString password;
};

typedef (PasswordCredentialData or HTMLFormElement) PasswordCredentialInit;

partial dictionary CredentialCreationOptions {
  PasswordCredentialInit password;
};

PasswordCredential 对象是源绑定的。

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

3.3. 算法

3.3.1. PasswordCredential 的 [[CollectFromCredentialStore]](origin, options, sameOriginWithAncestors)

[[CollectFromCredentialStore]](origin, options, sameOriginWithAncestors) 被调用时，参数为 origin（origin）、CredentialRequestOptions （options）， 以及一个仅当调用上下文与其祖先同源时为 true 的布尔值（sameOriginWithAncestors）。 该算法会从 凭证存储返回一组 Credential 对象。如果没有匹配的 Credential 对象可用，则返回集合为空。

如果 sameOriginWithAncestors 不是 true，算法将抛出 NotAllowedError。

1. 断言：options["password"] 存在。

2. 如果 sameOriginWithAncestors 为 false，则抛出 "NotAllowedError" DOMException。

   注意：此限制旨在解决 § 6.4 源混淆中提出的问题。

3. 如果 options["password"] 不为 true，则返回空集合。

4. 返回 检索自 凭证存储、且满足以下筛选条件的凭证列表：

   1. 凭证是 PasswordCredential

   2. 凭证的 [[origin]] 与 origin 同源。

3.3.2. PasswordCredential 的 [[Create]](origin, options, sameOriginWithAncestors)

[[Create]](origin, options, sameOriginWithAncestors) 被调用时，参数为 origin（origin）、CredentialCreationOptions （options），以及一个仅当调用上下文 与其祖先同源时为 true 的布尔值（sameOriginWithAncestors）。 该算法在可以创建时返回一个 PasswordCredential，否则返回 null。 CredentialCreationOptions 字典必须有一个 password 成员， 其值要么为 HTMLFormElement， 要么为 PasswordCredentialData。 如果该成员的值无法用于创建 PasswordCredential， 此算法将抛出 TypeError 异常。

1. 断言：options["password"] 存在，且 sameOriginWithAncestors 未使用。

2. 如果 options["password"] 是 HTMLFormElement， 返回执行 通过 HTMLFormElement 创建 PasswordCredential，参数为 options["password"] 和 origin 的结果。 重新抛出任何异常。

3. 如果 options["password"] 是 PasswordCredentialData， 返回执行 通过 PasswordCredentialData 创建 PasswordCredential，参数为 options["password"] 的结果。 重新抛出任何异常。

4. 抛出 TypeError 异常。

3.3.3. PasswordCredential 的 [[Store]](credential, sameOriginWithAncestors)

[[Store]](credential, sameOriginWithAncestors) 被调用时，传入一个 PasswordCredential （credential），以及一个仅当调用上下文与其祖先同源时为 true 的布尔值 （sameOriginWithAncestors）。当 credential 持久化到 凭证存储后，该算法返回 undefined。

如果 sameOriginWithAncestors 不是 true，算法将返回 NotAllowedError。

1. 如果 sameOriginWithAncestors 为 false，则抛出 "NotAllowedError" DOMException， 并且不修改用户代理的 凭证存储。

   注意：此限制旨在解决 § 6.4 源混淆中提出的问题。

2. 如果用户代理的 凭证存储中已包含一个 PasswordCredential （stored），其 id 属性等于 credential 的 id， 且其 [[origin]] 槽与 credential 的 [[origin]] 同源，则：

   1. 如果用户允许更新凭证（见 用户介入 的定义），则：

      1. 设置 stored 的 password 为 credential 的 password。

      2. 设置 stored 的 name 为 credential 的 name。

      3. 设置 stored 的 iconURL 为 credential 的 iconURL。

   否则，如果用户允许存储凭证（见 用户介入 的定义），则：

   1. 在 凭证存储中存储一个 PasswordCredential ，其属性如下：

      id

      credential 的 id

      name

      credential 的 name

      iconURL

      credential 的 iconURL

      [[origin]]

      credential 的 [[origin]]

      password

      credential 的 password

3.3.4. 通过 HTMLFormElement 创建 PasswordCredential

要通过 HTMLFormElement 创建 PasswordCredential，传入一个 HTMLFormElement （form）和一个 origin（origin），运行如下步骤。

注意： § 3.1.2 登录后确认 和 § 3.1.3 修改密码 提供了推荐用法示例。

1. 令 data 为一个新的 PasswordCredentialData 字典。

2. 设置 data 的 origin 成员值为 origin 的值。

3. 令 formData 为执行 FormData 构造器，参数为 form 的结果。

4. 令 elements 为所有 可提交元素，其 表单拥有者为 form，按 树顺序排列。

5. 令 newPasswordObserved 为 false。

6. 遍历 elements 的每个 field，执行如下步骤：

   1. 如果 field 没有 autocomplete 属性，则跳过至下一个 field。

   2. 令 name 为 field 的 name 属性值。

   3. 如果 formData 的 has() 方法在 name 上执行结果为 false，则跳过至下一个 field。

   4. 如果 field 的 autocomplete 属性值包含一个或多个 自动填充细节标记（tokens），则：

      1. 遍历 tokens 的每个 token：

         1. 如果 token 是以下字符串之一的 ASCII 不区分大小写匹配，则执行相关步骤：

            "new-password"

            设置 data 的 password 成员值为执行 formData 的 get() 方法，参数为 name 的结果，并将 newPasswordObserved 设为 true。

            "current-password"

            如果 newPasswordObserved 为 false， 设置 data 的 password 成员值为执行 formData 的 get() 方法，参数为 name 的结果。

            注意：如果 newPasswordObserved 为 false，则 new-password 字段优先于 current-password 字段。

            "photo"

            设置 data 的 iconURL 成员值为执行 formData 的 get() 方法，参数为 name 的结果。

            "name"

            "nickname"

            设置 data 的 name 成员值为执行 formData 的 get() 方法，参数为 name 的结果。

            "username"

            设置 data 的 id 成员值为执行 formData 的 get() 方法，参数为 name 的结果。

7. 令 c 为执行 通过 PasswordCredentialData 创建 PasswordCredential，参数为 data 的结果。如果抛出 异常，则重新抛出该异常。

8. 断言：c 为 PasswordCredential。

9. 返回 c。

3.3.5. 通过 PasswordCredentialData 创建 PasswordCredential

要通过 PasswordCredentialData 创建 PasswordCredential，给定一个 PasswordCredentialData （data），运行如下步骤。

1. 令 c 为一个新的 PasswordCredential 对象。

2. 如果以下任意项是空字符串，则抛出 TypeError 异常：

   • data 的 id 成员值

   • data 的 origin 成员值

   • data 的 password 成员值

3. 设置 c 的属性如下：

   password

   data 的 password 成员值

   id

   data 的 id 成员值

   iconURL

   data 的 iconURL 成员值

   name

   data 的 name 成员值

   [[origin]]

   data 的 origin 成员值。

4. 返回 c。

3.3.6. CredentialRequestOptions 与 PasswordCredential 的匹配

给定一个 CredentialRequestOptions （options），下述算法如果应将 PasswordCredential 作为 get() 请求的返回结果，则返回 "Matches"，否则返回 "Does Not Match"。

1. 如果 options 拥有 password 成员且其值为 true，则返回 "Matches"。

2. 返回 "Does Not Match"。

4. 联合凭证

4.1. FederatedCredential 接口

[Exposed=Window,
 SecureContext]
interface FederatedCredential : Credential {
  constructor(FederatedCredentialInit data);
  readonly attribute USVString provider;
  readonly attribute DOMString? protocol;
};
FederatedCredential includes CredentialUserData;

dictionary FederatedCredentialRequestOptions {
  sequence<USVString> providers;
  sequence<DOMString> protocols;
};

partial dictionary CredentialRequestOptions {
  FederatedCredentialRequestOptions federated;
};

FederatedCredential 对象可通过向 navigator.credentials.create() 传递一个 FederatedCredentialInit 字典进行创建。

dictionary FederatedCredentialInit : CredentialData {
  USVString name;
  USVString iconURL;
  required USVString origin;
  required USVString provider;
  DOMString protocol;
};

partial dictionary CredentialCreationOptions {
  FederatedCredentialInit federated;
};

FederatedCredential 对象是源绑定的。

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

注意：如果未来我们让用户代理为用户获取身份认证令牌，可以通过实现 [[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors) 来实现。

4.1.1. 身份提供者标识

每个网站在引用某个特定联合身份提供者时应使用相同的标识符。例如，Facebook Login 不应被称为 "Facebook"、"Facebook Login"、"FB"、"FBL"、"Facebook.com" 等等。应有一个规范标识符供所有人使用，因为一致的标识有助于用户代理提供帮助。

为保持一致，传递到本文档定义的 API（如 FederatedCredentialRequestOptions 的 providers 数组或 FederatedCredential 的 provider 属性）必须用该提供者用于登录的 origin 的 ASCII 序列化来标识。也就是说，Facebook 用 https://www.facebook.com，Google 用 https://accounts.google.com。

这种 origin 的序列化不包括结尾的 U+002F 斜杠（"/"），但用户代理应默默接受它：https://accounts.google.com/ 显然与 https://accounts.google.com 相同。

4.2. 算法

4.2.1. FederatedCredential 的 [[CollectFromCredentialStore]](origin, options, sameOriginWithAncestors)

[[CollectFromCredentialStore]](origin, options, sameOriginWithAncestors) 被调用时，参数为 origin（origin）、CredentialRequestOptions （options）， 以及一个仅当调用上下文与其祖先同源时为 true 的布尔值（sameOriginWithAncestors）。 该算法会从 凭证存储返回一组 Credential 对象。如果没有匹配的 Credential 对象可用，则返回集合为空。

1. 断言：options["federated"] 存在。

2. 如果 sameOriginWithAncestors 为 false，则抛出 "NotAllowedError" DOMException。

   注意：此限制旨在解决 § 6.4 源混淆中提出的问题。

3. 如果 options["federated"] 不为 true，则返回空集合。

4. 返回 检索自 凭证存储、且满足以下筛选条件的凭证列表：

   1. 凭证是 FederatedCredential

   2. 凭证的 [[origin]] 与 origin 同源。

   3. 如果 options["federated"]["providers"] 存在，其值 包含凭证的 provider。

   4. 如果 options["federated"]["protocols"] 存在，其值 包含凭证的 protocol。

4.2.2. FederatedCredential 的 [[Create]](origin, options, sameOriginWithAncestors)

[[Create]](origin, options, sameOriginWithAncestors) 被调用时，参数为 origin（origin）、CredentialCreationOptions （options），以及一个仅当调用上下文与其祖先同源时为 true 的布尔值（sameOriginWithAncestors）。 该算法在可以创建时返回一个 FederatedCredential，否则返回 null，异常情况下抛出 异常：

1. 断言：options["federated"] 存在，且 sameOriginWithAncestors 未使用。

2. 设置 options["federated"] 的 origin 成员值为 origin 的值。

3. 返回执行 通过 FederatedCredentialInit 创建 FederatedCredential， 参数为 options["federated"] 的结果。如果抛出 异常，则重新抛出该异常。

4.2.3. FederatedCredential 的 [[Store]](credential, sameOriginWithAncestors)

[[Store]](credential, sameOriginWithAncestors) 被调用时，传入一个 FederatedCredential （credential），以及一个仅当调用上下文与其祖先同源时为 true 的布尔值 （sameOriginWithAncestors）。当 credential 持久化到 凭证存储后，该算法返回 undefined。

如果 sameOriginWithAncestors 不是 true，算法将返回 NotAllowedError。

1. 如果 sameOriginWithAncestors 为 false，则抛出 "NotAllowedError" DOMException， 并且不修改用户代理的 凭证存储。

   注意：此限制旨在解决 § 6.4 源混淆中提出的问题。

2. 如果用户代理的 凭证存储中已包含一个 FederatedCredential， 其 id 属性等于 credential 的 id， 且其 [[origin]] 槽与 credential 的 [[origin]]同源， 且其 provider 等于 credential 的 provider， 则直接返回。

3. 如果用户允许存储凭证（见 用户介入 的定义），则在 凭证存储中存储一个 FederatedCredential， 其属性如下：

   id

   credential 的 id

   name

   credential 的 name

   iconURL

   credential 的 iconURL

   [[origin]]

   credential 的 [[origin]]

   provider

   credential 的 provider

   protocol

   credential 的 protocol

4.2.4. 通过 FederatedCredentialInit 创建 FederatedCredential

要 通过 FederatedCredentialInit 创建 FederatedCredential，给定一个 FederatedCredentialInit （init），运行如下步骤。

1. 令 c 为一个新的 FederatedCredential 对象。

2. 如果以下任意项是空字符串，则抛出 TypeError 异常：

   • init.id 的值

   • init.provider 的值

3. 设置 c 的属性如下：

   id

   init.id 的值

   provider

   init.provider 的值

   iconURL

   init.iconURL 的值

   name

   init.name 的值

   [[origin]]

   init.origin 的值。

4. 返回 c。

5. 用户介入

通过 API 向网页暴露凭证信息会对用户隐私产生诸多潜在影响。因此，用户代理必须在多个情景下让用户介入，以确保用户清楚地了解发生了什么，以及自己的凭证将与谁共享。

如果某个动作是在获得用户明确同意后发生的，我们称之为用户介入。同意可以通过用户直接与凭证选择器界面交互等方式表达。一般来说，用户介入动作会涉及向用户展示某种界面，要求他们做出决定。

如果某个动作是静默发生的，没有获得用户明确同意，则称为“无介入”。例如，如果用户将浏览器配置为对特定源持久授予凭证访问权限，则凭证可能会在未向用户展示请求界面的情况下被提供。

这里我们列出所有凭证类型通用的部分要求，但请注意，用户代理还有较大的自由度（它处于帮助用户的特权位置）。此外，特定的凭证类型可能有超出这里通用要求的额外要求。

5.1. 存储和更新凭证

凭证信息是敏感数据，用户必须能一直掌控这些信息的存储。意外存储凭证可能会导致用户本地设备上的个人资料意外地与某个在线身份关联。为降低意外风险：

1. 凭证信息不应在没有用户介入的情况下被存储或更新。例如，用户代理可以在每次调用 store() 时弹出 “保存此凭证？” 对话框。

   如果用户代理选择以 “始终保存密码” 的方式为用户提供持久授权，则可以推断用户同意（不过我们建议用户代理应谨慎，可以只提供“始终保存生成的密码”或“始终保存此网站的密码”等更窄范围的选项）。

2. 用户代理应在凭证被存储时通知用户。通知方式可以是地址栏中的图标或类似的位置。

3. 用户代理必须允许用户手动移除已存储的凭证。此功能可以通过设置页面实现，也可以通过与上述通知交互实现。

5.2. 强制用户介入

默认情况下，所有用户介入都要求对所有源进行，因为防止静默访问标志在凭证存储中被设为 true。用户可以选择授予某个源对凭证的持久访问权限（例如“保持登录此网站”的选项），这会将该标志设为 false。这样，用户就会一直保持登录状态，这对可用性和便利性很有利，但也可能带来意外影响（比如用户代理在设备间同步该标志状态）。

为降低意外风险：

1. 用户代理必须允许用户为指定的源或所有源要求用户介入。此功能可以作为全局开关实现，从而覆盖每个源的防止静默访问标志，使其返回false，也可以通过更细粒度的设置实现，仅针对特定源（或特定源上的特定凭证）。

2. 用户代理在没有用户介入的情况下，绝不能将源的防止静默访问标志设置为false。例如，凭证选择器（见§ 5.3 凭证选择）可以有一个复选框，用户可以切换以将某个凭证标记为该源下无需介入即可使用，或者用户代理可以在其凭证管理器的引导流程中询问用户默认设置。

3. 用户代理在向某个源提供凭证时，必须通知用户。这可以采用地址栏中的图标或类似的位置显示。

4. 如果用户清除了某个源的浏览数据（如 cookies、localStorage 等），用户代理必须为该源设置防止静默访问标志为true。

5.3. 凭证选择

当对一个需要用户介入的源调用get()方法时，用户代理必须请求用户授权才能分享凭证信息。这个过程应当以凭证选择器的形式展示给用户，提供一组当前网站可用的凭证，允许用户选择一个要提供给网站的凭证，或直接中止请求。

选择器的用户界面应以网站无法伪造的方式实现。例如，选择器可以用某种不可伪造的方式覆盖用户代理自身的界面。

选择器的用户界面必须包含正在请求凭证的源的指示信息。

选择器的用户界面应当包含与请求凭证的源关联的所有Credential对象。

用户代理可以在内部为每个Credential对象关联除本文档属性外的其它信息，以增强选择器的实用性。例如，网站图标可以帮助区分不同的身份提供方等。任何额外存储的信息都不得直接暴露给 Web。

选择器的行为在此未作规定：鼓励用户代理在界面设计上进行探索，以帮助用户了解其认证选项，并引导其完成凭证选择流程。其选择器的接口如下：

6. 安全注意事项

以下各节为各种安全和隐私注意事项的指导原则。不同凭证类型可能会强制执行更严格或更宽松的版本。

6.1. 跨域凭证访问

凭证属于敏感信息，用户代理在确定何时可以安全地与网站共享时需谨慎。最安全的做法是仅与保存凭证的精确源共享凭证。然而，这对 Web 来说可能过于严格：请考虑将功能分布在子域名上的网站，如 example.com 和 admin.example.com。

为在减少用户不便与增强凭证安全之间折中，用户代理：

1. 不得在 scheme 降级时在不同源之间共享凭证。例如，允许将 http://example.com/ 上保存的凭证用于 https://example.com/（鼓励开发者迁移到安全传输），但反过来则很危险。

2. 可以使用 Public Suffix List [PSL]，通过比较凭证的 可注册域名和调用 get() 的源，确定凭证的有效作用范围。即：在 https://www.example.com/ 调用 get() 时，可以向用户提供 https://admin.example.com/ 和 https://example.com/ 上保存的凭证，反之亦然。

3. 在凭证的源与调用源不完全匹配时，不得在响应 get() 时直接提供凭证，除非经过用户介入。即 Credential 对象仅在源精确匹配时直接返回，否则通过选择器提供给用户。

6.2. 凭证泄露

开发者应当采取一些预防措施，通过设置合理的内容安全策略（Content Security Policy，[CSP]），限制数据可以发送到的端点，从而降低跨站脚本攻击演变为对用户账户的持久访问的风险。特别是，开发者应确保在页面策略中显式或隐式地设置以下指令：

• script-src 和 object-src 都限制了页面上的脚本执行，从而降低跨站脚本攻击最初成功的可能性。如果站点正在填充 form 元素，还应设置 form-action 指令。

• connect-src 限制 fetch() 可以提交数据的源（这有助于防止凭证被泄露到 evil.com）。

• child-src 限制可以嵌入到页面中的嵌套浏览上下文，从而使得注入恶意 postMessage() 目标更加困难。[HTML]

当然，开发者还应正确转义输入输出，并考虑使用其他防护措施，比如 Subresource Integrity [SRI] 进一步降低风险。

定义具体凭证类型时，应充分考虑凭证数据的传输方式。例如，可以定义仅限同源端点的传输机制。

6.3. 不安全站点

用户代理不得在非安全环境中暴露此处定义的 API。用户代理可能实现自动填充机制，在非潜在可信URL上存储用户凭证并填充登录表单，但这些站点无法被信任以任何有意义的方式直接与凭证管理器交互，并且这些站点不得访问存储在安全环境中的凭证。

6.4. 源混淆

如果被嵌入的页面能够访问本规范定义的 API，可能会导致用户被误导，将凭证授权给非顶级浏览上下文的源，而用户只能合理理解顶级上下文的安全源。

本规范将凭证管理 API 暴露给这些上下文，因为某些凭证类型在用户代理给予足够 UI 支持和上下文提示后，可以安全地暴露。

但某些具体凭证类型很难在这些上下文安全暴露，因此通过在 [[Create]](origin, options, sameOriginWithAncestors)、 [[CollectFromCredentialStore]](origin, options, sameOriginWithAncestors)、 [[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors) 和 [[Store]](credential, sameOriginWithAncestors) 方法中进行检查来加以限制。

例如，PasswordCredential 的 [[CollectFromCredentialStore]](origin, options, sameOriginWithAncestors) 方法如果在 Worker 或非 顶级浏览上下文中调用，会立即返回空集合。

6.5. 注销

如 § 5.2 强制用户介入 所述，如果用户选择自动登录网站，则用户代理会在网站请求时提供凭证。网站可通过调用 CredentialsContainer 的 preventSilentAccess() 方法，关闭某源的自动登录行为。

用户代理依赖网站正确操作；若网站疏忽或恶意，未调用此方法，用户代理仍会继续提供凭证，这比网站在用户点击“注销”时不清理凭证更糟，因为用户代理也参与了认证过程。

用户必须能够控制此行为。如 § 5.2 强制用户介入 所述，清除某源的 Cookie 也会将该源在 凭证存储中的防止静默访问标志重置为 true。此外，用户代理应为禁用某源自动登录提供 UI 控件，比如与凭证已被提供通知绑定的选项。

7. 隐私注意事项

7.1. 计时攻击

如果用户没有针对某个源的凭证，调用 get() 时会非常快速地返回结果。恶意网站可能据此区分“没有凭证”与“有凭证但用户选择不分享”的用户。

用户代理也应对凭证请求进行速率限制。短时间内多次请求凭证几乎肯定属于滥用行为。

7.2. 选择器泄露

如果用户代理的凭证选择器显示由源提供的图片（例如 Credential 显示网站 favicon），则这些图片的请求不得与实例化选择器直接关联，以避免泄露选择器的使用。可以选择在保存或更新 Credential 时后台获取图片，并在该 Credential 生命周期内缓存它们。

这些图片必须以 credentials mode 为 "omit"、service-workers mode 为 "none"、client 为 null、initiator 为空字符串、destination 为 "subresource" 进行获取。

此外，如果用户代理允许用户更改凭证关联的名称或图标，则对数据的更改不应暴露给网站（例如用户将两个凭证命名为“我的假账号”和“我的真账号”）。

7.3. 本地存储数据

该 API 允许某个 源将数据与用户的个人资料持久存储。由于大多数用户代理对凭证数据和“浏览数据”（如 cookie 等）处理方式不同，这可能导致用户在清除 cookie 时以为所有来源痕迹都被清除，实际仍有凭证数据保留而感到意外。

用户代理应提供 UI，清楚地向用户展示某个源已存储凭证数据，并应让用户易于移除这些数据。

9. 未来工作

本节为非规范内容。

此处定义的 API 仅以极简方式将用户代理的凭证管理器暴露给 Web，并允许 Web 协助这些凭证管理器识别何时正在使用联合身份提供者。下一步的合理方向，将会类似于[WEB-LOGIN]等文档中描绘的内容（以及在某种程度上，Mozilla 的 BrowserID [BROWSERID]）。

用户代理处于一个独特位置，可以有效调解用户、身份提供者和网站之间的关系。如果用户代理能减少典型认证流程中的风险和困惑，用户的处境将比现在大为改善。

一种自然的信息暴露方式可能是扩展 FederatedCredential 接口，增加如认证令牌等属性，或添加某种声明提供者支持认证类型的 manifest 格式属性。

此处描述的 API 设计为足够可扩展，以支持需要用户交互的用例，甚至可能涉及除了请求凭证的网站之外的其他网站。我们希望我们采用的基于 Promise 的系统，足够扩展以支持此类异步流程，这些流程可能需要多个浏览上下文之间的某种交互（例如 idp.com 上的调解活动可解析传回给 rp.com 的 Promise），或者未来支持设备与用户代理之间的交互（例如 [WEBAUTHN]），而无需从零重新设计 API。

循序渐进。