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

W3C 工作草案

关于本文档的更多详细信息
此版本:
https://www.w3.org/TR/2026/WD-lws10-authn-ssi-did-key-20260609/
最新发布版本:
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. 隐私考量

本节为非规范性内容。

议题 119:向认证套件添加隐私考量 章节

本节需要完成。

A. 参考文献

A.1 规范性参考文献

[did-key]
The did:key Method v0.9. W3C. URL: https://w3c-ccg.github.io/did-key-spec/
[LWS10-CORE]
链接式 Web 存储协议 1.0. W3C. FPWD. URL: https://www.w3.org/TR/lws10-core/
[RFC2119]
用于 RFC 中表示 要求级别的关键词. S. Bradner. IETF. 1997年3月. 最佳当前实践. URL: https://www.rfc-editor.org/rfc/rfc2119
[RFC6749]
OAuth 2.0 授权 框架. D. Hardt, Ed. IETF. 2012年10月. 提议标准. URL: https://www.rfc-editor.org/rfc/rfc6749
[RFC7515]
JSON Web Signature (JWS). M. Jones; J. Bradley; N. Sakimura. IETF. 2015年5月. 提议标准. URL: https://www.rfc-editor.org/rfc/rfc7515
[RFC7519]
JSON Web Token (JWT). M. Jones; J. Bradley; N. Sakimura. IETF. 2015年5月. 提议标准. URL: https://www.rfc-editor.org/rfc/rfc7519
[RFC8174]
RFC 2119 关键词中大小写的歧义. B. Leiba. IETF. 2017年5月. 最佳当前实践. URL: https://www.rfc-editor.org/rfc/rfc8174

A.2 资料性参考文献

[OPENID-CONNECT-CORE]
OpenID Connect Core 1.0 incorporating errata set 2. N. Sakimura; J. Bradley; M. Jones; B. de Medeiros; C. Mortimore. OpenID Foundation. 2023年12月15日. 最终版. URL: 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月. 最佳当前实践. URL: https://www.rfc-editor.org/rfc/rfc9700