Copyright © 2026 World Wide Web Consortium. W3C® liability, trademark and permissive document license rules apply.
この文書は、Linked Web Storage (LWS) プロトコル向けの認証スイートを定義し、自身の アイデンティティトークンに署名できるクライアントがLWSと統合できるようにします。
このセクションは、この文書の公開時点における ステータスを説明します。現在のW3C 公開文書の一覧およびこの技術報告書の最新版は、 W3C標準および草案 インデックスで確認できます。
これは非公式な提案です。
この文書は、Linked Web Storageワーキング グループにより、 勧告 トラックを用いる作業草案として公開されました。
作業草案としての公開は、 W3Cおよびそのメンバーによる 承認を意味するものではありません。
これは草案文書であり、いつでも他の文書によって更新、置換、または廃止される可能性があります。 この文書を進行中の作業以外のものとして引用することは適切ではありません。
この文書は、 W3C 特許 ポリシーの下で活動するグループにより作成されました。 W3Cは、 そのグループの成果物に関連して行われた 特許開示の公開リストを管理しています。 そのページには、特許を開示するための 手順も含まれています。個人が、当該個人が 必須クレームを含むと考える特許について 実際の知識を有している場合、その個人は W3C特許ポリシー第6節に従って 情報を開示しなければなりません。
この文書は、 2025年8月18日のW3Cプロセス文書に準拠します。
自己発行アイデンティティは、アプリケーションが自身の代理として動作する場合に重要です。
これには、自律ボットやサーバーサイドスクリプトなどが含まれます。
これらの場合、エージェントは、
署名付きJSON Web Token
(JWT)を生成するために使用する鍵ペアの秘密部分を安全に管理できます。
この仕様は、この種のエージェントが、did:key:
メソッドを用いたエージェント識別子を使用しながら、Linked Web Storageで利用できる
認証クレデンシャルを生成する方法を説明します。
非規範的と明示されたセクションに加え、この仕様内のすべての作成ガイドライン、図、例、および注記は 非規範的です。この仕様のその他すべては規範的です。
この文書におけるキーワードMAY、MUST、およびMUST NOTは、 ここに示すようにすべて大文字で出現する場合に限り、 BCP 14 [RFC2119] [RFC8174] に記述されているとおりに解釈されます。
用語「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]で定義されています。
自己発行の認証クレデンシャルは、 署名付きJSON Web Token (JWT)としてシリアライズされます。JWTをLWSの認証クレデンシャルとして使用するには、 次の追加要件が適用されます。
sub(subject)クレームを使用しなければなりません(MUST)。
サブジェクト識別子はdid:key: URIを使用しなければなりません(MUST)。
iss(issuer)クレームを使用しなければなりません(MUST)。
client_id(client ID)クレームを使用しなければなりません(MUST)。
sub、iss、およびclient_idは、すべて同じURI値を
使用しなければなりません(MUST)。
aud
(audience)クレームを使用しなければなりません(MUST)。audクレームは、対象の
認可サーバーを含まなければなりません(MUST)。
exp(expiration)クレームを
含まなければなりません(MUST)。
iat(issued at)クレームを
含まなければなりません(MUST)。
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
did:keyメソッドを使用するサブジェクト識別子について、検証者は
「The did:key Method」[did-key]の
セクション3.1.3で説明されているように、識別子自体から公開鍵を抽出します。
この公開鍵を使用して、JWTの署名は
[RFC7515]のセクション5.2に記述されているとおりに
検証されなければなりません(MUST)。
検証者は、認証クレデンシャル データモデルで記述されているすべてのクレームを検証しなければなりません(MUST)。
検証者は、現在時刻がexpクレームで表される時刻より前であることを
確認しなければなりません(MUST)。実装者は、クロックスキューを考慮するために、
わずかな猶予を設けてもよいです(MAY)。
認証クレデンシャルとして使用される
自己発行JSON Web Tokenは、認可サーバーとやり取りする際に
urn:ietf:params:oauth:token-type:jwt URIを使用しなければなりません(MUST)。
このセクションは非規範的です。
「Best Current Practice for OAuth 2.0 Security」[RFC9700]および「OpenID Connect Core 1.0」セクション16 [OPENID-CONNECT-CORE]に記述されている すべてのセキュリティ上の考慮事項が、この仕様に適用されます。
このセクションは非規範的です。
did:key
メソッドを使用する自己発行型の認証クレデンシャルは、
公開鍵をサブジェクト識別子に直接埋め込みます。
sub、iss、および client_id クレームはすべて同じ
did:key: URI を共有するため、検証者とストレージサーバーは、特定のエージェントによる
すべての活動を、セッションやリソースをまたいで関連付けることができます。
他の認証スイートとは異なり、did:key メソッドでは、検証時に
リモートリソースを参照解決する必要がありません。公開鍵は
識別子から直接導出されます。クレデンシャルの検証処理中に
サードパーティーサーバーへ接続しないため、ネットワークベースの検証に伴う
メタデータの漏えいを回避できます。
ただし、公開鍵は識別子自体に符号化されているため、
did:key 識別子は本質的に長期間存続し、
エージェントの
識別情報を変更せずにローテーションすることはできません。安定した識別情報を維持しながら
鍵をローテーションする必要があるエージェントには、
制御された識別子文書に基づくものなど、別の
認証スイートを使用することが推奨されます。
ストレージサーバーまたは認可サーバーに提示された自己発行型トークンは、 それらの当事者が読み取ることができます。転送中の認証 クレデンシャルを保護するには、TLS の使用が不可欠です。