SPECIFICATION

第 0 章：はじめにと適合性

0.1 ドキュメント状態

本ドキュメントは Control Authority Protocol（CAP）の規範的技術仕様書のドラフト版である。ドラフト版は後方互換性を保証せず、正式リリース前に任意の変更を行うことができる。本ドラフトが安定し、完全なテスト検証を経た後、初の正式バージョンとして specification/2025-10-25/ に公開される。

本ドキュメントは CAP アーキテクチャブループリント（docs/ja/blueprint/）と併せて使用する：

  • ブループリントは「何を、なぜ、何のために」に答える——プロトコルの設計意図、能力境界、コアメカニズムを定義する
  • 仕様は「どうやって、どう検証するか」に答える——プロトコルのメッセージ形式、フローステップ、エラー処理、適合性要件を定義する

ブループリントの非規範的記述と本仕様の規範的条項が衝突する場合、本仕様を優先する。

0.2 範囲

本仕様は CAP プロトコル v1 の技術詳細を定義し、ブループリント第 3 章 3.1 節に列挙された 6 つのコア能力をカバーする：

  1. オフライン認可（Authorization_Descriptor）の発行、保管、検証、失効、更新
  2. オンラインチケット（Trusted_Ticket）の発行、照会、オフライン認可への変換
  3. セッション管理（Session）の完全なライフサイクル
  4. 制御権ハンドオーバーポリシー（Handover_Policy）の 3 種類のポリシーと原子性保証
  5. 生存検知（Liveness_Detection）の二重判定メカニズム
  6. リソースアクセスモード（Resource_Access_Mode）の読み書きロックモデル

本仕様はブループリント第 3 章 3.2 節に列挙された機能を明確に除外する。これには端末横断セッション移行、複数端末協調認可、認可委任チェーン、ABAC、監査ログ標準形式、プロトコルメッセージ暗号化伝送仕様、分散失効合意、Session 内動的権限昇格が含まれる。

0.3 適合性用語

本仕様は RFC 2119 および RFC 8174 のキーワード規約に従う。以下のキーワードが全大文字で出現する場合、規範的意味を持つ：

  • MUST / しなければならない：絶対的要件。本要件を満たさない実装は本仕様に適合しない
  • MUST NOT / してはならない：絶対的禁止。本禁止に違反する実装は本仕様に適合しない
  • SHOULD / すべきである：強い推奨。結果を十分理解した上で、正当な理由があれば逸脱できる
  • SHOULD NOT / すべきではない：強い非推奨。結果を十分理解した上で、正当な理由があれば逸脱できる
  • MAY / してもよい：オプション。実装は提供するか否かを自ら決定できる

全大文字でない同一語彙は字義通りの意味のみを表し、規範的効力を持たない。

0.4 用語の整合

本仕様で使用する用語はブループリント 00-用語集.md と完全に一致する。本仕様がある用語を引用する際、ブループリントで定義された識別子（例：Authorization_Descriptor、Fay、Terminal_Resource）を使用する。

参照の便宜のため、本仕様は各章で重要用語を初出する際に太字で示し、ブループリント用語集の簡潔な定義を付記する。用語の完全な定義はブループリントを優先する。

0.5 適合性レベル

本仕様は 3 種類の実装適合性レベルを定義する。実装は MUST 少なくとも「端末適合性レベル」を満たすことで CAP v1 への適合を主張できる。

0.5.1 端末適合性レベル（Terminal Conformance）

Descriptor_Validator、Protocol_Engine およびセッション管理ロジックを実装する端末デバイスに適用される。端末実装は MUST：

  1. 第 3 章で定義された Authorization_Descriptor 検証フローを完全に実装する
  2. 第 5 章で定義された Session ライフサイクルおよび Liveness_Detection メカニズムを完全に実装する
  3. 第 7 章で定義された Resource_Access_Mode 読み書きロックセマンティクスを完全に実装する
  4. 検証を通過しないすべての要求を拒否し、第 9 章に従い標準化されたエラーコードを返却する
  5. ローカル失効リストを維持し、オンライン時に第 3 章で定義されたポリシーで同期する

0.5.2 発行者適合性レベル（Issuer Conformance）

Descriptor_Issuer または Ticket_Issuer を実装する信頼エンティティに適用される。発行者実装は MUST：

  1. 第 2 章で定義されたフィールド制約に従い、合法な Authorization_Descriptor および Trusted_Ticket を生成する
  2. 第 8 章で定義された暗号学要件に従い、クレデンシャルにデジタル署名を行う
  3. 発行済みクレデンシャルの状態記録を維持し、失効操作をサポートする
  4. 第 4 章で定義された Trusted_Ticket から Authorization_Descriptor への変換を実装する

0.5.3 ランタイム適合性レベル（Runtime Conformance）

iFay_Runtime を実装する Fay ランタイム環境に適用される。ランタイム実装は MUST：

  1. 第 1 章で定義されたインタフェース契約に従い、Protocol_Engine に認可検証要求を提出する
  2. 持続接続を維持し、第 5 章で定義された頻度でアプリケーション層ハートビートを送信する
  3. Protocol_Engine からプッシュされるセッション状態変更通知を受信・転送する
  4. Fay インスタンス終了時、Protocol_Engine に主動通知して関連 Session を解放する

実装は複数の適合性レベルを同時に満たすことができる。例えば、統合型端末は端末実装とランタイム実装を同時に担うことができる。

0.6 参照規範

本仕様は以下のドキュメントを規範的に参照する：

  • RFC 2119 / RFC 8174：本仕様で使用するキーワード規約
  • RFC 8949（CBOR）：Authorization_Descriptor のコンパクトバイナリシリアライゼーション用（第 2 章を参照）
  • RFC 8032（EdDSA）：デフォルトのデジタル署名アルゴリズム（第 8 章を参照）
  • RFC 7515（JWS）：Trusted_Ticket の JSON シリアライゼーションと署名（第 4 章を参照）
  • RFC 5280（X.509）：オプションの証明書形式（第 8 章を参照）

CAP Schema 定義ファイル（schema/{version}/schema.json）は本仕様第 2 章の形式化補足として、本仕様と同等の規範的効力を持つ。schema.json と本仕様のテキスト記述に衝突がある場合、schema.json を優先する。

0.7 ドキュメント構成

本仕様は以下の順序で構成される：

章主題主要内容
第 1 章アーキテクチャと役割プロトコル役割、信頼チェーン、外部インタフェース契約
第 2 章データモデルコアデータ構造のフィールドレベル定義
第 3 章オフライン認可プロトコルAuthorization_Descriptor 完全フロー
第 4 章オンラインチケットプロトコルTrusted_Ticket 完全フローとデグレード
第 5 章セッション管理と生存検知Session 状態機械とハートビート
第 6 章制御権ハンドオーバープロトコルHandover_Policy 3 種ポリシー
第 7 章リソースアクセスモードread/write/execute/configure セマンティクス
第 8 章暗号学と署名アルゴリズム集、鍵形式、配布
第 9 章エラーコードと適合性レベル標準エラーコード、レベル宣言
第 10 章セキュリティ考慮事項脅威モデル、既知のリスク

読者は第 0–2 章を順に読んで基礎を確立し、その後実装の関心事に応じて関連章へジャンプすることを推奨する。