Copyright © 2026 World Wide Web Consortium. W3C® liability, trademark and permissive document license rules apply.
この文書は、Linked Web Storage (LWS) プロトコルのための OpenID Connect ベースの認証スイートを定義し、LWS アプリケーションが OpenID プロバイダーと統合できるようにします。
このセクションでは、この文書の公開時点におけるステータスを説明します。現在の W3C 公開物の一覧と、この技術報告書の最新版は W3C 標準および草案 インデックスで確認できます。
これは非公式の提案です。
この文書は、Linked Web Storage Working Group により、 勧告 トラックを用いて作業草案として公開されました。
作業草案としての公開は、 W3C およびそのメンバーによる承認を 意味するものではありません。
これは草案文書であり、いつでも他の文書によって更新、置換、または廃止される可能性があります。この文書を 作業中の文書以外のものとして引用することは適切ではありません。
この文書は、 W3C 特許 ポリシーの下で運営されるグループによって作成されました。 W3C は、 このグループの成果物に関連して行われた 特許開示の公開リストを管理しています。 そのページには、特許を開示するための 手順も含まれています。ある個人が、当該個人の考えるところでは 必須クレームを含む 特許について実際の知識を有する場合、その個人は W3C 特許ポリシーのセクション 6に従って その情報を開示しなければなりません。
この文書は、 2025年8月18日版 W3C プロセス文書に準拠します。
OpenID Connect は、Web ベースの認証に広く使用されている仕組みです。この認証スイートは、 OpenID プロバイダーを Linked Web Storage 準拠アプリケーションでどのように使用できるかを説明します。
非規範的と明記されたセクションに加えて、この仕様に含まれるすべての作成ガイドライン、図、例、および注記は 非規範的です。この仕様に含まれるそれ以外のすべては規範的です。
この文書におけるキーワード MUST、MUST NOT、および SHOULD は、 ここに示すようにすべて大文字で出現する場合に限り、 BCP 14 [RFC2119] [RFC8174] に記述されているとおりに解釈されます。
「authorization server」および「client」という用語は、The OAuth 2.0 Authorization Framework [RFC6749] によって定義されます。
「OpenID provider」、「id token」、「end-user」、および「issuer」という用語は、OpenID Connect Core 1.0 [OPENID-CONNECT-CORE] によって定義されます。
「openid connect discovery」という用語は、OpenID Connect Discovery 1.0 [OPENID-CONNECT-DISCOVERY] によって定義されます。
「controlled identifier document」という用語は、W3C Controlled Identifiers 1.0 [CID-1.0] によって定義されます。
「JSON Web Token (JWT)」および「claim」という用語は、JSON Web Token [RFC7519] によって定義されます。
「JSON Web Key (JWK)」という用語は、JSON Web Key [RFC7517] によって定義されます。
「agent」、「authentication credential」、および「authentication suite」という用語は、Linked Web Storage Protocol [LWS10-CORE] によって定義されます。
OpenID Connect は、エンドユーザーを記述するために使用される署名付き ID Token を生成するプロトコルを定義します。 ID Token は、署名付き JSON Web Token (JWT) としてシリアル化されます。ID Token を LWS の authentication credential として使用するには、次の追加要件が適用されます。
sub (subject) クレームを使用しなければなりません。
iss (issuer) クレームを使用しなければなりません。
azp (authorized party) クレームを使用しなければなりません。
aud
(audience) クレームを使用しなければなりません。
aud クレームには、クライアント識別子と、認可サーバーなどの
追加の対象オーディエンスを含めるべきです。
LWS の authentication credential でもある ID Token の例を以下に示します。
{
"typ": "JWT",
"kid": "12dbe73a",
"kty": "EC",
"alg": "ES256",
"crv": "P-256"
}
.
{
"sub": "https://id.example/end-user",
"iss": "https://openid.example",
"azp": "https://client.example/17da1b",
"aud": ["https://client.example/17da1b", "https://as.example"],
"iat": 1761313600,
"exp": 1761313900
}
.
signatureID Token が LWS の authentication credential として検証されるためには、検証者と発行者の間に信頼関係が存在しなければなりません。
既存の信頼関係がない場合、検証者は authentication credential
内の sub (subject) クレームを逆参照しなければなりません。
その結果得られるリソースは、サブジェクト識別子と等しい id 値を持つ、
有効な controlled identifier document [CID-1.0] として整形されていなければ
なりません。
検証者は、サブジェクトの controlled identifier document を使用して、
serviceEndpoint 値が authentication credential
の iss クレームの値に等しく、かつ type 値が
https://www.w3.org/ns/lws#OpenIdProvider に等しい service オブジェクトを見つけなければ
なりません。
検証者は、authentication credential
に署名するために使用された JSON Web Key (JWK) の公開部分を特定するため、
OpenID Connect Discovery を実行しなければなりません。
JWT は、OpenID Connect Core Section 3.1.3.7
[OPENID-CONNECT-CORE]
に記述されているとおりに検証されなければなりません。
OpenID Connect を使用する agent の Controlled Identifier Document の例を以下に示します。
{
"@context": [
"https://www.w3.org/ns/cid/v1"
],
"id": "https://id.example/end-user",
"service": [{
"type": "https://www.w3.org/ns/lws#OpenIdProvider",
"serviceEndpoint": "https://openid.example"
}]
}
authentication credential
として使用される ID Token は、
認可サーバーとやり取りする際に、urn:ietf:params:oauth:token-type:id_token URI を使用しなければ
なりません。
このセクションは非規範的です。
「Best Current Practice for OAuth 2.0 Security」[RFC9700] および「OpenID Connect Core 1.0」Section 16 [OPENID-CONNECT-CORE] に記述されている すべてのセキュリティ考慮事項が、この仕様に適用されます。
OpenID プロバイダーは、authentication credential の オーディエンスを、認可サーバーを含む限定されたエンティティ集合に制限する仕組みをサポートすべきです。 これを実現する一つの仕組みは、Resource Indicators for OAuth 2.0 [RFC8707] を使用することです。 オーディエンス制限のない authentication credential を保持するクライアントは、たとえば OAuth 2.0 Token Exchange [RFC8693] を使用して、 このトークンを同等のオーディエンス制限付きトークンと交換すべきです。
OpenID プロバイダーは、OAuth フローの認可レスポンスに
iss パラメーターを含めることにより、
「OAuth 2.0 Authorization Server Issuer Identification」
[RFC9207] のサポートを提供すべきです。
OpenID プロバイダーは、RP-Initiated Logout 1.0 など、エンドユーザーのログアウトをサポートすべきです。
authentication credential の発行者は、 クライアント識別子を検証する責任を負います。 発行者は、OAuth Client ID Metadata Document、OAuth 2.0 Client ID Prefix、 または OpenID Federation などの仕組みを使用してもよいです。
OpenID プロバイダーは、ユーザーを認証する仕組みとして WebAuthn [WEBAUTHN-3] をサポートすることが推奨されます。
このセクションは非規範的です。
「OpenID Connect Core 1.0」の第17節 [OPENID-CONNECT-CORE] に記載されているすべてのプライバシー上の考慮事項が、 この仕様に適用されます。
認証資格情報として使用されるID Tokenには、
メールアドレス、氏名、その他のプロファイル属性など、
エンドユーザーの個人を特定できる情報を明らかにするクレームが含まれる可能性があります。OpenIDプロバイダーには、
LWS認証に必要なクレームのみ、具体的には
sub、iss、azp、およびaudクレームを含むID Tokenを発行し、
明示的に必要とされない限り、追加の識別属性を含めないことが推奨されます。
sub（サブジェクト）クレームはLWSサブジェクト識別子として使用され、
検証中に参照解決される可能性があるため、サブジェクト識別子の選択にはプライバシー上の
影響があります。永続的でグローバルに一意なサブジェクト識別子により、検証者と
ストレージサーバーは、セッションやリソースをまたいでエンドユーザーの活動を関連付けることができます。
（[OPENID-CONNECT-CORE] の第
8節に記載されている）ペアワイズサブジェクト識別子をサポートするOpenIDプロバイダーは、
プロバイダー間の相関の可能性を低減できますが、LWS検証モデルではサブジェクト識別子が
制御識別子文書へ解決される必要があります。
検証プロセスでは、制御識別子文書を取得するためにサブジェクト識別子を 参照解決する必要があります。この参照解決操作により、その文書のホスティング サーバーに対して、特定のサブジェクトの資格情報をどの検証者が検証しているかが、 アクセスの時刻や頻度を含めて明らかになる可能性があります。検証者には、不要なネットワーク要求と、 それに伴うメタデータ漏洩を減らすため、制御識別子文書をキャッシュすることが 推奨されます。
クライアントおよびリライングパーティは、ストレージサーバーまたは認可
サーバーに提示されたID Tokenが、それらの当事者によって読み取られる可能性があることに注意する必要があります。オーディエンス制限
（audクレームによる）は、トークンが意図されている当事者を制限しますが、
転送中に仲介者がトークンの内容を読み取ることを防ぐものではありません。
TLSの使用は、送信中の認証資格情報を保護するために不可欠です。