Protocol
Overview（概要）
Identity & Trust（L3）は、参加主体を識別し、正当な主体同士、かつ正当なリソースへの権限でのみデータ交換が成立する信頼の前提を提供する機能を提供する。
本プロトコルは以下の領域を対象とする：
認証（Authentication） 自然人（Human）およびシステム（Machine）を主体として識別・認証し、利用コンテキストに応じた認証を実現する。
認可（Authorization） リクエスト単位でポリシーベースの動的認可を行う。
トークンおよびクレデンシャル管理 アクセストークン・リフレッシュトークンを発行し、事業者識別（operator_id 等）などのビジネスコンテキストをクレームとして付与する。
Federation & Trust（トラスト連携） 異なる運営組織・異なるOpen Dataspaces間の相互信頼を確立する。
Abstract Normative Specification（抽象仕様）
Concepts and Roles（概念および役割）
Identity & Trust（L3）
アイデンティティに関連する機能を提供する主体の総称。 ユーザ等を認証する役割、ユーザ等の認可（権限委譲）を管理する役割、ユーザ等のアイデンティティ情報を提供する役割を持つ。 フェデレーション構成等、アーキテクチャによってはそれぞれの役割を別々の主体が実行することもある。
Client
Resource Serverが提供するAPIに対してユーザ等の認可（権限委譲）を受けてアクセスする主体。
Resource Server
APIを通じて機能やデータを提供する主体。 リソースの持ち主（ユーザ等）からの権限委譲を受けたClientに対して権限に応じたリソースを提供する。
Resource Owner
Clientに対して自身の代わりにResource Server（API Server）へのアクセス権限を認可（権限委譲）する主体。
Service Provider
Identity & Trust（L3）を運営する運営団体。
Operator（事業者）
Service Providerから権限移譲を受けて、システムを利用する団体。
PAP
認可ポリシーの定義および管理を担う。
PDP
PEP から送信される認可判断要求を受け取り、PAP により定義されたポリシーおよびリクエストコンテキストを評価し、当該リクエストに対するアクセス可否（Permit / Deny）を決定する。
PEP
クライアントからのリクエストを受信し、必要に応じて PDP に対して認可判断を要求する。
Scope（適用範囲）
認証（Authentication）
認可（Authorization）
トークン/クレデンシャル管理
Federation（Open Dataspacesを跨ぐ信頼連携）
Normative Requirements（規定要件）
Authentication（認証）
shall: Identity & Trust（L3） は自然人・システムの双方を識別できる仕組みを持たなければならない。
Rationale: ODS の業務要件では、人による操作とシステム間通信が混在するため、両者を明確に区別しなければならない。
shall: 認証・認可方式には OAuth 2.0 および OpenID Connect を使用しなければならない。 自然人主体の認証には OpenID Connect（Authorization Code Flow）を、 システム主体については OAuth 2.0（Client Credentials Flow）におけるクライアント認証によって行う。
Rationale: 国際的に広く普及しているため相互運用性を確保できる。
should: ユーザ認証には Authorization Code Flow（PKCE）を使用することを原則とする。
Rationale: 自然人を扱う ODS では不可欠。PKCE はセキュリティ水準を向上。
may: 追加クレデンシャル（例: Verifiable Credential）を利用してもよい。
Rationale: 将来の拡張性と他Open Dataspaceとの相互連携性を確保。
may: フィッシング体制の高い多要素での認証を利用してもよい。
Rationale: 多要素認証により、資格情報の窃取や再利用に起因する不正アクセスのリスク低減が可能。
Note (Future Consideration): 認証においては、将来的な検討事項として、 フィッシング耐性の高い認証方式（例：FIDO2 に基づくパスキー等）を 用いた多要素認証を採用することが考えられる。
Authorization（認可）
shall: 認可判断をネットワーク境界（FW/DMZ）に依存してはならない。
Rationale: ゼロトラストアーキテクチャの原則に従うため。
shall: 認可判定に用いるsubject識別子は、アクセストークン内の検証済みクレームに基づかなければならない。
Rationale: 認証と認可を論理的に接続し、主体のなりすましや識別不整合を防ぐため。
should: 認可は API Gateway（粗粒度）と Application（細粒度）の二層構造とすることを原則とする。API Gateway（粗粒度）ではResource ServerのAPI利用のアクセス制御、Application（細粒度）ではリソースレベルでのアクセス制御を原則とする。
Rationale: 基盤レイヤと業務アプリレイヤを分離し、拡張性を維持するため。
should: PAPおよびPEP,PDP は分離することを原則とする。
Rationale: 政策管理と評価ロジックの分離はセキュリティと性能に寄与。
should: PEP ↔ PDP の通信は AuthZEN モデルと整合することを原則とする。
Rationale: 標準化されたReBACアプローチにより認可判断の一貫性が向上。
should: PAPおよびPDPは、論理的にはIdentity & Trust（L3）と統合されることを原則とする。
Rational: 認可モデルおよび判定ロジックの一貫性を確保し、ポリシー管理の分散による複雑化を防ぐため。
should: 認可モデルはReBACを原則とする。ReBACを採用する場合、認可モデルは少なくとも主体・対象・関係性（subject, object, relation）を明示的に表現できる構造を備えなければならない。
Rational: 権限継承や共有関係をグラフとして自然に表現でき、ポリシーの可読性・拡張性に優れるため。
Tokens & Credentials（トークン管理）
should: アクセストークンは署名付き JWT を使用することを原則とする。
Rationale: 相互運用性と軽量性に優れる。
should: アクセストークンは必要最小限の短い時間にすることを原則とする。
Rationale: 漏洩時の影響を最小化するため。
should: operator_id / system_id などビジネスクレームを付与することを原則とする。
Rationale: Open Dataspacesにおける事業者主体の識別が必須。
may: Refresh Token を使用してよい。
Rationale: セッション維持を効率化するため。
Federation & Trust（連携）
should: 異なるOpen Dataspaces運営組織間の Identity Federation をサポートすることを原則とする。
Rationale: 将来的な相互運用性確保が不可欠。
should: フェデレーション環境においては、subject識別子は発行主体を識別可能な形式とすることを原則とする。
Rationale: Open Dataspace間連携時の主体衝突を防ぐため。
may: 第三者トラスト（PKI / DAPS 等）を使用してよい。
Rationale: 組織のポリシーに応じた選択肢を提供。
Message Types（メッセージ種類）
プロトコルが扱うメッセージの種類を以下に示します。
リクエスト
クライアント ⇒ サーバー（Identity & Trust（L3））
クライアントが認証や認可を要求するために送信するメッセージ。認証情報や要求パラメータを含む。
レスポンス
サーバー（Identity & Trust（L3）） ⇒ クライアント
サーバー（Identity & Trust（L3））がリクエストに対する結果を送信するメッセージ。認証結果、トークン、エラー情報などを含む。
コールバック
サーバー（Identity & Trust（L3）） ⇒ クライアント
サーバー（Identity & Trust（L3））のIdPが認可コードを発行する際のメッセージ。
Protocol Flow（プロトコルフロー）
認証における代表的なシナリオとして、自然人主体の認証である認可コードフローのメッセージ交換シーケンスを以下に示す。
クライアントがサーバー（Identity & Trust（L3））に認証画面URL（ログイン画面）のリクエストを送信する:
クライアント ⇒ サーバー（Identity & Trust（L3））: 認証画面URL取得リクエスト
サーバー（Identity & Trust（L3））がリクエストを解析し、認証画面URL（ログイン画面）をクライアントに返送する:
サーバー（Identity & Trust（L3）） ⇒ クライアント: 認証画面URL（ログイン画面）返却レスポンス
ユーザのブラウザで認証画面URL（ログイン画面）にアクセスし、認証情報（ユーザIDとパスワード）を入力する。
ユーザのブラウザ ⇒ サーバー（Identity & Trust（L3））: 認可コード取得リクエスト
ユーザIDとパスワードを解析し、認可コードをユーザのブラウザに返送する
サーバー（Identity & Trust（L3）） ⇒ ユーザのブラウザ: 認可コード返却レスポンス
クライアントがサーバー（Identity & Trust（L3））に認証リクエストを送信する:
クライアント ⇒ サーバー（Identity & Trust（L3））: 認可コードを使った認証リクエスト
サーバー（Identity & Trust（L3））がリクエストを解析し、アクセストークンをクライアントに返送する:
サーバー（Identity & Trust（L3）） ⇒ クライアント: 認証レスポンス
State Machine（状態遷移）
本プロトコルで扱う状態について記す。
States（状態）
UNAUTHENTICATED
トークンが存在しない状態。認証前。
AUTHENTICATING
Idp による認証処理中（/auth/token, /auth/token/clientエンドポイントによる認証）。
AUTHENTICATED
アクセストークンが有効な状態。通常の API 呼び出しが可能。
TOKEN_EXPIRED
アクセストークンが期限切れ。リフレッシュトークンによる更新もしくは再認証が必要。
TERMINATED
セッションまたはトークンが無効化された状態（ログアウト、失効、更新失敗など）。再認証が必要。
State Machine Diagram（状態遷移図）
Error Handling（エラー処理）
本プロトコルで使用されるエラー処理について記す。
リクエスト不正
パラメータ不正、必須項目欠落等において返却される。
入力内容を再確認し、正しい入力内容を設定し、再送信を行う。
トークン設定に関するエラー
アクセストークン未設定、無効等において返却される。
アクセストークンを再取得および再設定（必要に応じて再ログインまたはトークン更新）し、再送信を行う。
権限不足エラー
必要な権限不足等において返却される。
該当操作が許可されていない旨を通知する。なお、再送しても成功しないため再送信は行わない。
リソース存在エラー
該当リソースが存在しない等において返却される。
リソースが存在しない旨を通知する。なお、再送しても成功しないため再送信は行わない。
データ不整合エラー
重複データ、排他制御等において返却される。
最新のデータを再取得し、競合を解消させたうえで、再送信を行う。
リクエスト形式エラー
サポートされないリクエスト形式指定時において返却される。
正しいContent-Typeを設定し、再送信を行う。
システムエラー
サーバ内部において何らかの異常発生時に返却される。
継続的に発生する場合はシステム管理者へ通知を行う。なお、再送信については行った操作によって実行要否を行う。
外部システムエラー
サーバ外部において何らかの異常発生時に返却される。
一定時間ごとにリトライ（再送信）を行った後、解消しない場合は時間をおいて再操作を行うよう通知を行う。またシステム管理者へ通知を行う。
最終更新