LWS 1.0 认证套件:使用 did:key 的自签名身份

W3C 工作草案

关于本文档的更多详细信息
此版本:
https://www.w3.org/TR/2026/WD-lws10-authn-ssi-did-key-20260803/
最新发布版本:
https://www.w3.org/TR/lws10-authn-ssi-did-key/
最新编辑草案:
https://w3c.github.io/lws-protocol/lws10-authn-ssi-did-key/
历史:
https://www.w3.org/standards/history/lws10-authn-ssi-did-key/
提交历史
编辑:
Jesse Wright牛津大学
作者:
Aaron CoburnInrupt Inc.
反馈:
GitHub w3c/lws-protocol拉取请求新建议题未解决议题

摘要

本文档定义了链接式 Web 存储(LWS)协议的一种认证套件,使能够签署其自身身份令牌的客户端能够与 LWS 集成。

本文档状态

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

这是一项非官方提案。

本文档由 链接式 Web 存储工作组作为 工作草案发布,并使用 推荐标准 轨道

发布为 工作草案并不意味着 W3C 及其成员的认可。

这是一份草案文档,可能会在任何时候被其他文档更新、替换或废弃。 除作为进行中的工作外,不宜引用本文档。

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

本文档受 2025年8月18日 W3C 流程文档管辖。

1. 引言

自签发身份对于应用程序代表自身行事的情况很重要。 这包括自主机器人以及服务器端脚本等。 在这些情况下,代理能够 安全地管理密钥对的私有部分,并使用它生成已签名的 JSON Web Token (JWT)。 本规范描述了这类代理如何生成可用于链接式 Web 存储的 认证凭证, 同时使用带有 did:key: 方法的代理标识符。

2. 一致性

除了标记为非规范性的章节外,本规范中的所有编写指南、图表、示例和注释均为非规范性内容。 本规范中的其他所有内容均为规范性内容。

本文档中的关键词 MAYMUSTMUST NOT 在且仅在它们如这里所示以全部大写形式出现时,应按照 BCP 14 [RFC2119] [RFC8174] 中所述进行解释。

3. 术语

术语“authorization server”和“client”由 The OAuth 2.0 Authorization Framework [RFC6749] 定义。

术语“JSON Web Token (JWT)”和“claim”由 JSON Web Token [RFC7519] 定义。

术语“agent”、“authentication credential”和“authentication suite”由 Linked Web Storage Protocol [LWS10-CORE] 定义。

4. 认证凭证 序列化

自签发的认证凭证会被 序列化为已签名的 JSON Web Token (JWT)。为了将 JWT 用作 LWS 认证凭证, 适用以下附加要求。

下面包含一个同时也是 LWS 认证凭证的示例 JWT。

{
  "kty": "EC",
  "alg": "ES256",
  "typ": "JWT",
  "crv": "P-256"
}
.
{
  "sub": "did:key:zDnaerx9CtbPJ1q36T5Ln5wYt3MQYeGRG5ehnPAmxcf5mDZpv",
  "iss": "did:key:zDnaerx9CtbPJ1q36T5Ln5wYt3MQYeGRG5ehnPAmxcf5mDZpv",
  "client_id": "did:key:zDnaerx9CtbPJ1q36T5Ln5wYt3MQYeGRG5ehnPAmxcf5mDZpv",
  "aud": ["https://as.example"],
  "iat": 1761313600,
  "exp": 1761313900
}
.
signature

5. 认证凭证 验证

对于使用 did:key 方法的主体标识符,验证者将从标识符本身提取公钥, 如“The did:key Method”第 3.1.3 节 [did-key] 中所述。 使用此公钥时,JWT 的签名 MUST 按照 [RFC7515] 第 5.2 节中所述进行验证。

验证者 MUST 验证认证凭证 数据模型所描述的所有声明。

验证者 MUST 确保当前时间早于 exp 声明所表示的时间。实现者 MAY 提供一些较小的宽限时间, 以考虑时钟偏差。

6. 令牌类型标识符

用作认证凭证的自签发 JSON Web Token 在与授权服务器交互时 MUST 使用 urn:ietf:params:oauth:token-type:jwt URI。

7. 安全考量

本节为非规范性内容。

“Best Current Practice for OAuth 2.0 Security”[RFC9700] 中描述的所有安全考量以及“OpenID Connect Core 1.0”第 16 节 [OPENID-CONNECT-CORE] 中描述的安全考量均适用于 本规范。

8. 隐私考量

本节为非规范性内容。

使用 did:key 方法的自签发身份验证凭据 会将公钥直接嵌入主体标识符中。由于 subissclient_id 声明都使用 同一个 did:key: URI,验证方和存储服务器可以跨会话和资源关联 给定代理 的所有活动。

与其他身份验证套件不同,did:key 方法在验证期间不 需要解引用远程资源——公钥直接从标识符 派生。这避免了与基于网络的验证相关的元数据泄露, 因为在凭据验证过程中不会联系任何第三方 服务器。

但是,由于公钥编码在标识符本身中, did:key 标识符本质上是长期存在的,并且无法在不更改代理 身份的情况下轮换。需要在保持稳定身份的同时 轮换密钥的代理 应使用其他身份验证套件,例如基于受控标识符文档的 套件。

提交给存储服务器或授权服务器的自签发令牌可被 这些参与方读取。使用 TLS 对于在传输过程中保护身份验证 凭据至关重要。

A. 参考文献

A.1 规范性参考文献

[did-key]
did:key 方法 v0.9。W3C。 网址:https://w3c-ccg.github.io/did-key-spec/
[LWS10-CORE]
关联 Web 存储协议 1.0。W3C。 首次公开工作草案。网址:https://www.w3.org/TR/lws10-core/
[RFC2119]
用于在 RFC 中指出 要求级别的关键词。S. Bradner。IETF。1997 年 3 月。最佳当前实践。网址:https://www.rfc-editor.org/info/rfc2119/
[RFC6749]
OAuth 2.0 授权 框架。D. Hardt,编辑。IETF。2012 年 10 月。提议标准。网址:https://www.rfc-editor.org/info/rfc6749/
[RFC7515]
JSON Web 签名(JWS)。M. Jones;J. Bradley;N. Sakimura。IETF。2015 年 5 月。提议标准。网址:https://www.rfc-editor.org/info/rfc7515/
[RFC7519]
JSON Web 令牌(JWT)。M. Jones; J. Bradley;N. Sakimura。IETF。2015 年 5 月。提议标准。网址:https://www.rfc-editor.org/info/rfc7519/
[RFC8174]
RFC 2119 关键词中大写与小写的 歧义。B. Leiba。IETF。2017 年 5 月。最佳当前实践。网址:https://www.rfc-editor.org/info/rfc8174/

A.2 资料性参考文献

[OPENID-CONNECT-CORE]
OpenID Connect 核心 1.0 (纳入勘误集 2)。N. Sakimura;J. Bradley;M. Jones;B. de Medeiros;C. Mortimore。OpenID 基金会。2023 年 12 月 15 日。最终版。网址:https://openid.net/specs/openid-connect-core-1_0.html
[RFC9700]
OAuth 2.0 安全 最佳当前实践。T. Lodderstedt;J. Bradley;A. Labunets;D. Fett。IETF。2025 年 1 月。 最佳当前实践。网址:https://www.rfc-editor.org/info/rfc9700/