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] に記述されているとおりに解釈されます。
「認可サーバー」および「クライアント」という用語は、OAuth 2.0 認可フレームワーク [RFC6749] により定義される。
「OpenID Provider」、「ID Token」、「エンドユーザー」および「発行者」という用語は、OpenID Connect Core 1.0 [OPENID-CONNECT-CORE] により定義される。
「OpenID Connect Discovery」という用語は、OpenID Connect Discovery 1.0 [OPENID-CONNECT-DISCOVERY] により定義される。
「制御識別子文書」という用語は、W3C Controlled Identifiers 1.0 [CID-1.0] により定義される。
「JSON Web Token (JWT)」および「クレーム」という用語は、JSON Web Token [RFC7519] により定義される。
「JSON Web Key (JWK)」という用語は、JSON Web Key [RFC7517] により定義される。
「エージェント」、「認証 資格情報」および「認証 スイート」は、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
}
.
signature
ID TokenがLWSの認証資格情報として有効であるためには、 検証者と発行者との間に信頼関係がなければならない。
既存の信頼関係がない場合、検証者は 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 を使用しなければ
なりません。
このセクションは非規範的です。
「OAuth 2.0 セキュリティのためのベストカレントプラクティス」[RFC9700] および「OpenID Connect Core 1.0」セクション16 [OPENID-CONNECT-CORE] に記載されたすべてのセキュリティ上の考慮事項が、本仕様に適用される。
OpenID Providerは、認可サーバーを含む限られたエンティティの集合に認証資格情報の対象を制限する仕組みをサポートするべきである。 これを実現する1つの仕組みとして、OAuth 2.0のリソースインジケーター [RFC8707] を使用する方法がある。 対象制限のない認証資格情報を保有するクライアントは、 例えばOAuth 2.0トークン交換 [RFC8693] を使用して、このトークンを同等の対象制限付きトークンと 交換するべきである。
OpenID Providerは、「OAuth 2.0認可サーバー発行者識別」[RFC9207] をサポートし、OAuthフローの認可レスポンスに
iss パラメーターを含めるべきである。
OpenID Providerは、RP-Initiated Logout 1.0など、エンドユーザーのログアウトをサポートするべきである。
認証資格情報の発行者は、クライアント識別子を検証する責任を負う。 発行者は、OAuth Client ID Metadata Document、OAuth 2.0 Client ID Prefix、 またはOpenID Federationなどの仕組みを使用してもよい。
OpenID Providerは、ユーザーを認証する仕組みとしてWebAuthn [WEBAUTHN-3] をサポートすることが推奨される。
このセクションは非規範的です。
「OpenID Connect Core 1.0」セクション17 [OPENID-CONNECT-CORE] に記載されたすべてのプライバシー上の考慮事項が本仕様に 適用される。
ID Tokenを認証資格情報として使用する場合、クレームを
含むことがある。
エンドユーザーに関する個人を特定できる情報、例えばメールアドレス、
氏名、その他のプロファイル属性を明らかにするクレームを含む。OpenID Providerには、
LWS認証に必要なクレームのみを含むID Tokenを発行することが推奨される。具体的には、
sub、iss、azp、およびaudクレームのみを含め、
明示的に必要とされる場合を除き、追加の識別属性を含めないようにする。
sub(サブジェクト)クレームはLWSのサブジェクト識別子として使用され、
検証中に参照解除される可能性があるため、サブジェクト識別子の選択にはプライバシー上の
影響がある。永続的でグローバルに一意なサブジェクト識別子により、検証者および
ストレージサーバーは、セッションおよびリソースをまたいでエンドユーザーの活動を相関付けることができる。
ペアワイズサブジェクト識別子をサポートするOpenID Providerは、(次に示す
[OPENID-CONNECT-CORE] セクション
8) のとおり、プロバイダー間の
相関付けの可能性を低減できるが、LWSの検証モデルでは、サブジェクト識別子が
制御識別子文書に解決されることが要求される。
検証プロセスでは、サブジェクト識別子を参照解除して 制御識別子文書を取得する必要がある。この参照解除操作により、その文書をホストする サーバーに対して、特定のサブジェクトの資格情報をどの検証者が検証しているかが明らかになる可能性があり、 そのアクセスのタイミングや頻度も含まれる。検証者には、制御識別子文書をキャッシュすることが推奨される。 不要なネットワーク要求およびそれに伴うメタデータ 漏えいを低減するためである。
クライアントおよび依拠当事者は、ストレージ
サーバーまたは認可サーバーに提示されたID Tokenが、それらの当事者によって読み取られる可能性があることに留意すべきである。対象制限
(audクレームによる)は、トークンが意図される当事者を制限するが、
転送中に仲介者がトークンの内容を読み取ることを防ぐものではない。
TLSの使用は、転送中の認証資格情報を保護するために不可欠である。