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プルリクエスト新しいイシュー未解決のイシュー

概要

この文書は、Linked Web Storage (LWS) プロトコル向けの認証スイートを定義し、自身の アイデンティティトークンに署名できるクライアントがLWSと統合できるようにします。

この文書のステータス

このセクションは、この文書の公開時点における ステータスを説明します。現在のW3C 公開文書の一覧およびこの技術報告書の最新版は、 W3C標準および草案 インデックスで確認できます。

これは非公式な提案です。

この文書は、Linked Web Storageワーキング グループにより、 勧告 トラックを用いる作業草案として公開されました。

作業草案としての公開は、 W3Cおよびそのメンバーによる 承認を意味するものではありません。

これは草案文書であり、いつでも他の文書によって更新、置換、または廃止される可能性があります。 この文書を進行中の作業以外のものとして引用することは適切ではありません。

この文書は、 W3C 特許 ポリシーの下で活動するグループにより作成されました。 W3Cは、 そのグループの成果物に関連して行われた 特許開示の公開リストを管理しています。 そのページには、特許を開示するための 手順も含まれています。個人が、当該個人が 必須クレームを含むと考える特許について 実際の知識を有している場合、その個人は W3C特許ポリシー第6節に従って 情報を開示しなければなりません。

この文書は、 2025年8月18日のW3Cプロセス文書に準拠します。

1. 序論

自己発行アイデンティティは、アプリケーションが自身の代理として動作する場合に重要です。 これには、自律ボットやサーバーサイドスクリプトなどが含まれます。 これらの場合、エージェントは、 署名付きJSON Web Token (JWT)を生成するために使用する鍵ペアの秘密部分を安全に管理できます。 この仕様は、この種のエージェントが、did:key: メソッドを用いたエージェント識別子を使用しながら、Linked Web Storageで利用できる 認証クレデンシャルを生成する方法を説明します。

2. 適合性

非規範的と明示されたセクションに加え、この仕様内のすべての作成ガイドライン、図、例、および注記は 非規範的です。この仕様のその他すべては規範的です。

この文書におけるキーワードMAYMUST、およびMUST 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」[did-key]の セクション3.1.3で説明されているように、識別子自体から公開鍵を抽出します。 この公開鍵を使用して、JWTの署名は [RFC7515]のセクション5.2に記述されているとおりに 検証されなければなりません(MUST)。

検証者は、認証クレデンシャル データモデルで記述されているすべてのクレームを検証しなければなりません(MUST)。

検証者は、現在時刻がexpクレームで表される時刻より前であることを 確認しなければなりません(MUST)。実装者は、クロックスキューを考慮するために、 わずかな猶予を設けてもよいです(MAY)。

6. トークンタイプ識別子

認証クレデンシャルとして使用される 自己発行JSON Web Tokenは、認可サーバーとやり取りする際に urn:ietf:params:oauth:token-type:jwt URIを使用しなければなりません(MUST)。

7. セキュリティ上の考慮事項

このセクションは非規範的です。

「Best Current Practice for OAuth 2.0 Security」[RFC9700]および「OpenID Connect Core 1.0」セクション16 [OPENID-CONNECT-CORE]に記述されている すべてのセキュリティ上の考慮事項が、この仕様に適用されます。

8. プライバシー上の考慮事項

このセクションは非規範的です。

did:key メソッドを使用する自己発行型の認証クレデンシャルは、 公開鍵をサブジェクト識別子に直接埋め込みます。 subiss、および client_id クレームはすべて同じ did:key: URI を共有するため、検証者とストレージサーバーは、特定のエージェントによる すべての活動を、セッションやリソースをまたいで関連付けることができます。

他の認証スイートとは異なり、did:key メソッドでは、検証時に リモートリソースを参照解決する必要がありません。公開鍵は 識別子から直接導出されます。クレデンシャルの検証処理中に サードパーティーサーバーへ接続しないため、ネットワークベースの検証に伴う メタデータの漏えいを回避できます。

ただし、公開鍵は識別子自体に符号化されているため、 did:key 識別子は本質的に長期間存続し、 エージェントの 識別情報を変更せずにローテーションすることはできません。安定した識別情報を維持しながら 鍵をローテーションする必要があるエージェントには、 制御された識別子文書に基づくものなど、別の 認証スイートを使用することが推奨されます。

ストレージサーバーまたは認可サーバーに提示された自己発行型トークンは、 それらの当事者が読み取ることができます。転送中の認証 クレデンシャルを保護するには、TLS の使用が不可欠です。

A. 参考文献

A.1 規範的参考文献

[did-key]
did:key メソッド v0.9. W3C. URL: https://w3c-ccg.github.io/did-key-spec/
[LWS10-CORE]
Linked Web Storage プロトコル 1.0. W3C. 初回公開作業草案. URL: https://www.w3.org/TR/lws10-core/
[RFC2119]
RFC で要件レベルを示すために使用する キーワード. S. Bradner. IETF. 1997年3月. 現行の最良の慣行. URL: https://www.rfc-editor.org/info/rfc2119/
[RFC6749]
OAuth 2.0 認可 フレームワーク. D. Hardt, 編. IETF. 2012年10月. 標準化への提唱. URL: https://www.rfc-editor.org/info/rfc6749/
[RFC7515]
JSON Web Signature (JWS). M. Jones; J. Bradley; N. Sakimura. IETF. 2015年5月. 標準化への提唱. URL: https://www.rfc-editor.org/info/rfc7515/
[RFC7519]
JSON Web Token (JWT). M. Jones; J. Bradley; N. Sakimura. IETF. 2015年5月. 標準化への提唱. URL: https://www.rfc-editor.org/info/rfc7519/
[RFC8174]
RFC 2119 のキーワードにおける大文字と小文字の 曖昧さ. B. Leiba. IETF. 2017年5月. 現行の最良の慣行. URL: https://www.rfc-editor.org/info/rfc8174/

A.2 参考情報としての参考文献

[OPENID-CONNECT-CORE]
正誤表セット2を組み込んだ OpenID Connect Core 1.0 . 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/info/rfc9700/