用于依赖方通行密钥端点的知名 URL

W3C 工作草案

关于本文档的更多详细信息
此版本:
https://www.w3.org/TR/2026/WD-passkey-endpoints-1-20260114/
最新发布版本:
https://www.w3.org/TR/passkey-endpoints/
编辑草案:
https://w3c.github.io/webappsec-passkey-endpoints/
先前版本:
历史:
https://www.w3.org/standards/history/passkey-endpoints-1/
反馈:
public-webappsec@w3.org 主题行请写为“[passkey-endpoints] … 消息主题 …”(归档
GitHub
编辑:
Okta
Cisco

摘要

本规范定义了一个知名 URL,WebAuthn 依赖方(RP)可托管该 URL,以使 WebAuthn 客户端 和凭据管理器能够发现其创建、管理 和其他信息性端点。

本文档状态

本节描述本文档在发布时的状态。当前 W3C 出版物列表以及本技术报告的最新修订版 可在 W3C 技术报告 索引中找到。

本文档由 Web 应用安全工作组 作为工作草案,使用推荐标准 轨道发布。本文档旨在成为 W3C 推荐标准。

已归档的)公共邮件列表 public-webappsec@w3.org (参见说明) 是讨论本规范的首选方式。 发送电子邮件时, 请在主题中放入文本“passkey-endpoints”, 最好像这样: “[passkey-endpoints] …评论摘要…

作为工作草案发布并不意味着 W3C 及其成员认可。本文档是草案文档,可能随时 被更新、替换或 由其他文档废弃。除作为进行中的工作外,不宜引用 本文档。

本文档由 Web 应用安全工作组制作。

本文档由一个依据 W3C 专利政策运作的组织制作。 W3C 维护一个任何 专利披露的公开列表, 这些披露与该组织的交付物相关; 该页面还包含披露专利的说明。 实际知晓某项专利,且认为该专利包含必要权利要求的个人 必须根据 W3C 专利政策第 6 节披露该信息。

本文档受 2025 年 8 月 18 日 W3C 流程文档约束。

1. 引言

本节为非规范性内容。

WebAuthn 依赖方(RP)目前缺少一种方式来 以编程方式声明它们支持通行密钥,以及用户 可以在何处为该服务创建通行密钥、在何处可以管理该服务的现有 通行密钥。通行密钥也可用于登录之外的其他功能,例如 签名和加密。 通过提出一个定义一组通行密钥专用端点的知名 URL,本规范 使 WebAuthn 客户端和凭据管理器(认证器) 能够直接链接到特定工作流和信息性端点,而不是让用户必须深入 其账户设置和帮助页面中查找。

2. 基础设施

本规范依赖 Infra 标准。[INFRA]

本规范使用 Fetch、HTML、HTTP 和 URL 标准中的术语。[FETCH] [HTML] [HTTP-SEMANTICS] [URL]

3. 通行密钥端点 URL

为了声明支持通行密钥和/或提供用于通行密钥创建与管理的直接端点, 依赖方必须在如下路径托管一个 JSON 文档:根据 [WELL-KNOWN], 将字符串 .well-known/passkey-endpointshttps 方案依赖方标识符连接而成。 不得返回重定向。

RP ID "example.com" 的通行密钥端点 URL 是 "https://example.com/.well-known/passkey-endpoints"

3.1. 服务器响应

此上下文中的服务器是支持通行密钥WebAuthn 依赖方(RP)。

成功响应必须使用 200 OK HTTP 状态码,并使用 application/json 内容类型返回一个 JSON 对象。

返回的 JSON 对象可以包含以下定义的任意成员。

enroll

此可选成员包含一个指向用户账户通行密钥创建页面的直接 URL

manage

此可选成员包含一个指向用户账户通行密钥管理页面的直接 URL

prfUsageDetails

此可选成员包含一个信息性页面的 URL,该页面描述 RP 如何使用 WebAuthn 伪随机函数扩展(PRF)。

HTTP/1.1 200 OK
Content-Type: application/json

{
   "enroll": "https://example.com/account/manage/passkeys/create",
   "manage": "https://example.com/account/manage/passkeys",
   "prfUsageDetails": "https://example.com/help/passkeys#encryption"
}

可以返回一个空 JSON 对象,以表示支持通行密钥,但不声明具体端点。

HTTP/1.1 200 OK
Content-Type: application/json

{}

3.2. 客户端处理

此上下文中的客户端可以是 WebAuthn WebAuthn 客户端,也可以是凭据管理器(认证器)。

给定通行密钥的依赖方标识符,通过运行以下步骤生成通行密钥端点 URL:

  1. url 为一个新的 URL, 其值设置如下:

    方案

    "https"

    主机

    该通行密钥的依赖方标识符

    端口

    null

    路径

    « ".well-known", "passkey-endpoints" »。

  2. 返回 url

RP ID "example.com" 的通行密钥 端点 URL 是 "https://example.com/.well-known/passkey-endpoints"

4. WebAuthn 客户端和凭据管理器的使用

本节为非规范性内容。

enroll

通行密钥注册通常由 RP 的业务逻辑和会话上下文驱动。有时它可能在 用户成功使用密码登录之后或经历密码重置流程之后发生,其他时候则发生在用户访问 专用的“通行密钥创建”页面时。

这些通行密钥创建入口点可能难以被用户找到,因为它们通常深藏在 账户设置或帮助页面之中。

当此成员存在时的示例用法:

manage

凭据管理通常深藏在账户设置中,这可能难以被用户找到。

当此成员存在时,凭据管理器可以显示指向 RP 通行密钥(或 通用凭据管理)页面的直接链接。

prfUsageDetails

某些依赖方(RP)使用 WebAuthn 伪随机 函数(PRF)扩展来签名或加密用户数据。由于通行密钥主要设计用于 认证,用户可能不知道删除启用 PRF 的通行密钥可能会影响其保存的数据 或其他功能。

利用 PRF 的 RP 应提供一个专用信息性页面,详细说明其通行密钥如何用于 认证之外的用途,以及删除的影响。该页面的 URL 应为 prfUsageDetails 键的值。

当此成员存在时,凭据管理器应在通行密钥删除 流程中显示警告,包括指向 RP 信息性页面的链接。

5. IANA 考虑事项

5.1. passkey-endpoints 知名 URI

本文档定义了“.well-known”URI passkey-endpoints。 此注册将提交给 IESG 进行审查、批准,并使用 [WELL-KNOWN] 中定义的 模板向 IANA 注册,如下所示:

URI 后缀

passkey-endpoints

变更控制者

W3C

规范文档

本文档是相关规范。(参见 § 3.1 服务器响应

相关信息:

无。

致谢

感谢 Arnar Birgisson、Rew Islam、Adam Langley、René Léveillé、Matthew Miller、Ricky Mondello 和 Dan Veditz 对本提案提供的反馈。

一致性

文档 约定

一致性要求通过描述性断言 与 RFC 2119 术语的组合来表达。 规范性部分中的关键词“MUST”、“MUST NOT”、“REQUIRED”、“SHALL”、“SHALL NOT”、“SHOULD”、“SHOULD NOT”、“RECOMMENDED”、 “MAY”和“OPTIONAL” 应按照 RFC 2119 中的描述进行解释。 然而,为了可读性, 这些词在本规范中并非全都以大写字母出现。

除明确标记为非规范性的节、示例和注记之外, 本规范的全部文本都是规范性的。[RFC2119]

本规范中的示例用“for example”一词引入, 或者使用 class="example" 与规范性文本分开, 如下所示:

这是一个信息性示例的例子。

信息性注记以“Note”一词开头, 并使用 class="note" 与规范性文本分开, 如下所示:

Note,这是一个信息性注记。

一致性 算法

作为算法一部分以命令式措辞表达的要求 (例如“strip any leading space characters” 或“return false and abort these steps”) 应解释为具有引入该算法时所使用的关键词 (“must”、“should”、“may”等)的含义。

以算法或特定步骤形式表述的一致性要求 可以用任何方式实现, 只要最终结果等价即可。 特别是,本规范中定义的算法旨在易于理解, 并不旨在具有高性能。 鼓励实现者进行优化。

索引

由引用 定义的术语

参考文献

规范性参考文献

[FETCH]
Anne van Kesteren。Fetch 标准。现行标准。URL:https://fetch.spec.whatwg.org/
[HTML]
Anne van Kesteren;等。HTML 标准。 现行标准。URL:https://html.spec.whatwg.org/multipage/
[HTTP-SEMANTICS]
R. Fielding,编;M. Nottingham,编;J. Reschke,编。HTTP 语义。2022 年 6 月。互联网 标准。URL:https://httpwg.org/specs/rfc9110.html
[INFRA]
Anne van Kesteren;Domenic Denicola。Infra 标准。现行标准。URL:https://infra.spec.whatwg.org/
[RFC2119]
S. Bradner。用于在 RFC 中 表示要求等级的关键词。1997 年 3 月。当前最佳实践。URL:https://datatracker.ietf.org/doc/html/rfc2119
[URL]
Anne van Kesteren。URL 标准。现行标准。 URL:https://url.spec.whatwg.org/
[WEBAUTHN-2]
Jeff Hodges;等。Web 认证:用于 访问公钥凭据的 API - 第 2 级。2021 年 4 月 8 日。REC。URL:https://www.w3.org/TR/webauthn-2/
[WEBAUTHN-3]
Tim Cappalli;等。Web 认证:用于 访问公钥凭据的 API - 第 3 级。2025 年 1 月 27 日。WD。URL:https://www.w3.org/TR/webauthn-3/
[WELL-KNOWN]
M. Nottingham。知名统一资源 标识符(URI)。2019 年 5 月。拟议标准。URL:https://www.rfc-editor.org/rfc/rfc8615