はじめに
SIOPv2について、理解する必要があるのでついでに日本語訳します。
長いので随時更新します。現在3章まで翻訳済み。
注記
この記事で訳しているのは2024/2/17公開版です。（執筆時点の最新）
最新の仕様は下記のリンクで公開されています。
Self-Issued OpenID Provider v2 - draft 13
↓から本編です。
Abstract
OpenID Connectは、エンドユーザーがOpenIDプロバイダー（OP）を利用して、アイデンティティ情報（認証やクレームなど）をそれらの情報に従って行動するリライングパーティ（RP）に提供するメカニズムを定義します。このモデルでは、RPはOPによって行われた主張を信頼します。つまり、OPがこれらの主張の発行者となります。
この仕様は、エンドユーザーが制御するSelf-Issued OpenIDプロバイダー（Self-Issued OP）というコンセプトでOpenID Connectを拡張します。Self-Issued OP自体は、このエンドユーザーに関するアイデンティティ情報を主張しません。代わりに、エンドユーザーがアイデンティティ情報の発行者となります。Self-Issued OPを使用することで、エンドユーザーは自分の制御下にある暗号鍵で署名されたSelf-Issued IDトークンを用いて自身を認証し、自己証明クレームをRPに直接提示することができます。
[OpenID4VP]のような他の仕様とあわせて使用される場合や、[OpenID.Core]のセクション5.6.2で定義されている集約されたクレームや分散クレームなどとあわせて使用される場合に、Self-Issued OPは、RPが信頼する第三者によって発行された暗号的に検証可能なクレームも提示することができます。
これにより、エンドユーザーはRPと対話することができ、RPが直接クレーム発行者と対話することなく行うことができます。
1. Introduction
この仕様は、エンドユーザーの制御下にあるOpenIDプロバイダー（OP）、Self-Issued OpenIDプロバイダー（Self-Issued OP）というコンセプトでOpenID Connectを拡張します。Self-Issued OPを使用すると、エンドユーザーはSelf-Issued IDトークンで自身を認証し、自己証明クレームをRPに直接提示することができます。[OpenID4VP]のような他の仕様とあわせて使用される場合や、[OpenID.Core]のセクション5.6.2で定義されている集約されたクレームや分散クレームなどとあわせて使用される場合に、Self-Issued OPは、RPが信頼する第三者によって発行された暗号的に検証可能なクレームも提示することができます。
これにより、エンドユーザーはRPと対話することができ、RPが直接クレーム発行者と対話することなく行うことができます。
エンドユーザーの制御は、Self-Issued OPが完全にエンドユーザーのデバイス上でローカルにホストされていることを意味するものではありません。Self-Issued OPを実装する方法はいくつかあります。：Self-Issued OPはエンドユーザーのデバイス上で完結することもかのうですし、クラウドコンポーネントを利用することも可能です。また、完全にクラウド上で動作させることもできます。
従来のOPとSelf-Issued OPの重要な違いは、Self-Issued OPがエンドユーザーがRPに送出する識別子とクレームを決定することを許可することです。
[OpenID.Core]は、OPがIDトークンの形でエンドユーザーの認証情報を送出することを定義しています。RPは、RPとこのIDトークンの発行者との関係に基づいてIDトークンを信頼します。
この仕様で定義された拡張は、Self-Issued OpenIDプロバイダーモデルをサポートするために必要なプロトコルの変更を提供します。この仕様で定義されていない側面は、[OpenID.Core]に従うことが期待されます。中でも注目すべきなのは、Self-Issued OPは、そのデプロイメントモデルが許す限り、[OpenID.Core]で指定されたすべてのフローを実装することができます。[MAY]例えば、認証コードフロー、OpenID Connect拡張フロー、[OpenID.CIBA]などです。Self-Issued OPが完全にユーザーデバイス上で運用されている場合、RPに対して認証エンドポイントを超えるエンドポイントを公開することができないかもしれません。しかし、Self-Issued OPがクラウドベースのコンポーネントを持っている場合、トークンエンドポイントなどのさらなるエンドポイントを公開することができます。[MAY]これは、ダイナミッククライアント登録（[OpenID.Registration]）にも適用されます。
この仕様は、Self-Issued OpenID Connect Provider DID Profile v0.1を置き換えるもので、Decentralized Identity FoundationとOpenID Foundationの連絡先の作業項目として書かれました。(TODO ここよくわからない)
1.1. 要件表記と規約
この文書中のキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONAL」は、RFC 2119 [RFC2119]で説明されているように解釈されるべきです。
1.2. OpenID Connect CoreとSelf-Issued OPモデルの間の注目すべき違い
従来のOpenID Connectモデルでは、OPがIDトークン発行者として行動するとき、正確な情報を提供するためにOPがRPと法的な関係を持ち、RPとエンドユーザーの両方との評判に基づいた関係を持つことが一般的です。Self-Issued OPモデルでは、RPの信頼関係はエンドユーザーと直接的に結ばれています。Self-Issued OPは、エンドユーザーが第三者が提供したOPによってエンドユーザーに割り当てられた識別子の代わりに、エンドユーザーが制御する識別子でRPに対して認証することを許可します。エンドユーザーが制御する識別子は、公開鍵のフィンガープリントや分散識別子（[DID-Core]参照）である可能性があります。これは、従来のOpenID Connectモデルと比較すると、信頼モデルとSelf-Issued IDトークンの署名の検証方法の点で異なります。
従来のOpenID Connectでは、IDトークンはエンティティとしてのOPによって署名され、issクレームによって識別されます。RPは、この識別子を使用してIDトークンの署名を検証するためのキーマテリアルを取得します。この署名は、データがRPがその目的のために信頼するOPによって証明されていることを保証し、また、IDトークンを生成したサービスの証明でもあります（両者は同一のエンティティです）。
Self-Issued OPの場合、IDトークンは、ユーザーの制御下にある秘密鍵で自己署名され、subクレームによって識別されます。RPは、この識別子を使用してIDトークンの署名を検証するためのキーマテリアルを取得します。従来のOpenID Connectとは異なり、この署名はもはやIDトークンを作成したソフトウェアやサービスを暗号的に検証するために使用することはできません。自己発行IDトークンは、iss値がsubクレームで伝えられるユーザー識別子に設定されているときに検出することができます。なぜなら、概念的には、IDトークンの発行者はユーザーだからです。これはまた、Self-Issued OPと自己署名証明書やW3C Verifiable Presentationsがそのような証明書と主張の主題と発行者を扱う方法を一致させます。（TODO 日本語が変）
エンドユーザーの制御下にあるSelf-Issued OPは、従来のOPのような法的、あるいは評判による信頼がないため、Self-Issued IDトークンに含まれるエンドユーザーに関する主張（例えば、生年月日）は、デフォルトでは自己主張であり、検証不可能です。Self-Issued OPは、[OpenID4VP]のような他の仕様で定義されているクレームや[OpenID.Core]のセクション5.6.2で定義されている集約されたクレームや分散クレームなど、RPが信頼する第三者のソースによって発行された暗号的に検証可能なクレームも提示することができます。
1.3. 用語と定義
この仕様は、OAuth 2.0 [RFC6749]で定義された"Authorization Request"、"Authorization Response"、"Authorization Server"、"Client"、"Client Identifier"、"Response Type"、"Token Response"という用語、OpenID Connect Core [OpenID.Core]で定義された"End-User"、"Entity"、"Request Object"、"Request URI"という用語、JSON Web Token (JWT) [RFC7519]で定義された"JSON Web Token (JWT)"という用語、JSON Web Signature (JWS) [RFC7515]で定義された"JOSE Header"と"Base64url Encoding"という用語、およびOAuth 2.0 Multiple Response Type Encoding Practices [OAuth.Responses]で定義された"Response Mode"という用語を使用します。
この仕様はまた、以下の用語を定義します。用語が異なる定義を持つ場合、以下の定義が優先されます。
Self-Issued OpenID Provider (Self-Issued OP):暗号的に検証可能な識別子の制御を証明するOpenID Provider (OP)
Self-Issued Request:RPからSelf-Issued OPへのリクエスト
Self-Issued Response:Self-Issued OPからRPへのレスポンス
Self-Issued ID Token:エンドユーザーが制御するキーマテリアルを使用して署名されたIDトークン。Self-Issued OPによって発行される。
Cryptographically Verifiable Identifier:ID トークンまたは自己発行リクエストの署名を検証するために使用できる暗号鍵マテリアルに基づく、または暗号鍵マテリアルに解決される識別子。
Trust Framework:OIX で定義されているとおり、共通の目的のために設置されたマルチパーティーシステムを統制し、参加者のコミュニティの中野特定のタイプのトランザクションを指揮するようにデザインされ、そして一連の共通の要求によって拘束される法的強制力をもつ一連の仕様、ルール、協定。
Wallet:エンドユーザーのクレデンシャルと暗号鍵マテリアルを受け取り、保管し、提示し、管理するエンティティ。Walletのデプロイメントモデルは単一ではない。:クレデンシャルと暗号鍵をどちらもローカルに保管/管理する。または、遠隔の自己ホストサービスや第三者のサービスを使用する。本仕様の文脈ではWalletはRPに対する Self-Issued OpenID Provideとして振る舞う。
1.4. 略語
OP: OpenID Provider
RP: Relying Party
Self-Issued OP or SIOP: Self-Issued OpenID Provider
2. スコープ
2.1. スコープ内
この仕様は、以下の方法でOpenID Connect Coreを拡張します：
- Self-Issued OPの呼び出し：RPがSelf-Issued OPを呼び出す/開くメカニズム。
- Self-Issued OPメタデータの取得（静的および動的ディスカバリー）：RPがSelf-Issued OPのメタデータ（例：認証エンドポイント）を発見するメカニズム。
- RPメタデータの取得：Self-Issued OPがRPメタデータを取得するメカニズム。RPがSelf-Issued OPに事前登録する場合、しない場合のどちらとも。
- Self-Issued IDトークン：Self-Issued OPによって発行されるIDトークンの追加のクレームと処理要件。issとsubのクレームの値が同じ場合、IDトークンは自己発行される。
- 自己主張クレームのサポート：RPによって検証できないSelf-Issued IDトークン内のクレームの転送。
- 暗号的に検証可能な識別子のサポート：暗号鍵マテリアルに基づく、または暗号鍵マテリアルに解決できる識別子。ID トークンの署名に使用される暗号鍵の所有を証明するために、ID トークンのサブクレームでSelf-Issued OP によって使用される。このような識別子のタイプは、この仕様ではサブジェクト構文タイプとして定義される。
2.2. スコープ外
以下は、この文書のスコープ外と見なされます。
2.2.1. 第三者発行者からのクレームの提示
Self-Issued OPは、IDトークンで自己証明のクレームを提示できます。
信頼できる第三者のソースによって発行された暗号的に検証可能なクレームを提示する方法は、他の仕様で定義されています。例えば、[OpenID4VP]は、OAuth 2.0を拡張して検証可能な資格情報の提示を可能にし、W3C検証可能な資格情報とISO/IEC 18013-5:2021 mdocなどの他の資格情報形式をサポートしています。
検証可能なプレゼンテーション内の暗号鍵とSelf-Issued IDトークンに署名するための暗号鍵は必ずしも関連しているわけではなく、RPはこの点について仮定しないべきです。[SHOULD NOT]
2.3. [OpenID.Core]のセクション7とSelf-Issued OpenIDプロバイダーとの関係
この仕様は、以下の方法で[OpenID.Core]のセクション7 Self-Issued OpenIDプロバイダーを拡張します：
- Self-Issued OP v2で定義されたJWK指紋に加えて、[DID-Core]で定義された分散識別子を暗号的に検証可能な識別子としてサポートを追加。セクション8を参照。
- クロスデバイスSelf-Issued OPモデルのサポートを追加。セクション4を参照。
- 事前に登録されていないRPが認証リクエストでメタデータと認可リクエストを渡す方法を拡張。セクション7を参照。
- 動的Self-Issued OpenIDプロバイダーのディスカバリーのサポートを追加。セクション6.1を参照。
- カスタムURLスキームに加えて、Self-Issued OPの認証エンドポイントとしてのclaimed URLs（ユニバーサルリンク、アプリリンク）のサポートを追加。セクション6.2を参照。
- Self-Issued OPと動的クライアント登録のための任意のOpenID Connectフローの使用。
この仕様は[OpenID.Core] Self-Issued OpenIDプロバイダーの元のセクション7を拡張していますが、その一部のセクションはOpenID Connect Core仕様全体に一般的に適用可能である可能性があることに注意してください。
3. プロトコルフロー
Self-Issuedリクエストは、エンドユーザーの認証が成功し、エンドユーザーが必要な許可を提供した場合に、Self-Issued OPがIDトークンをRPに返します。IDトークンには常に認証イベントに関するクレームが含まれます。また。エンドユーザーに関する追加のクレームが含まれる場合もあります。[MAY]
+------+ +----------------+
| | | |
| |--(1) Self-Issued OpenID Providerリクエスト| |
| | (認可リクエスト) | |
| | | |
| | +----------+ | |
| | | | | |
| | エンドユーザー | |
| RP | | |<--(2) AuthN & AuthZ--->| Self-Issued OP |
| | | | | |
| | +----------+ | |
| | | |
| |<-(3)Self-Issued OpenID Providerレスポンス-| |
| | (Self-Issued IDトークン) | |
| | | |
+------+ +----------------+
図1: Self-Issued OP プロトコルフロー