SPECIFICATION

第 1 章：アーキテクチャと役割

本章は CAP プロトコルにおける役割、それらの間の信頼関係、および外部システムとのインタフェース契約を定義する。本章の内容は後続章のための共通の用語基盤とアーキテクチャコンテキストを提供する。

1.1 プロトコル役割

CAP プロトコルには以下の規範的役割が含まれる。各役割はプロトコル相互作用において明確な責務を担い、他の役割と限定されたインタフェースを通じて相互作用する。

1.1.1 認可者役割

Natural_Person（自然人）と Official_Post（公式ポスト）は認可の最終的な発生源である。認可者はプロトコルメッセージ相互作用に直接参加しない——認可者は認可委任メカニズムを通じて発行権を Descriptor_Issuer に委任する。

認可者は MUST 安全な身元検証メカニズムを通じてその身元を証明する。認可者身元の具体的な検証メカニズムは本仕様の範囲外であるが、当該メカニズムは MUST 以下の要件を満たす：

  • 否認不可性：認可者は自身が下した認可決定を否認できない
  • 偽造防止性：第三者は認可者の認可決定を偽造できない

1.1.2 発行者役割

Descriptor_Issuer は Authorization_Descriptor の生成と発行を担当する。Ticket_Issuer は Trusted_Ticket の発行を担当する。1 つのエンティティは MAY 両方の発行者役割を同時に担う。

発行者は MUST：

  1. 合法な認可者から明示的な認可を受領した後にのみクレデンシャルを発行する
  2. 第 8 章で定義された署名アルゴリズムを使用してクレデンシャルにデジタル署名する
  3. 発行済みクレデンシャルの状態記録を維持する（最低限、発行時刻、有効期間、現在の状態を含む）
  4. 失効要求を受領した際、速やかに失効状態を更新し、失効声明を公開する

発行者は MUST NOT：

  1. 認可を得ずにクレデンシャルを発行する
  2. 認可者の認可範囲を超えるクレデンシャルを発行する
  3. 失効済みクレデンシャルの識別子を再利用する

1.1.3 保有者役割

Fay（iFay および coFay を含む）はクレデンシャルの保有者であり、リソースアクセスの要求者である。Fay は iFay_Runtime を介して間接的にプロトコル相互作用に参加する——Fay 自体はプロトコルメッセージを直接送信しない。

Fay は MUST 自身が所属する iFay_Runtime を通じて、端末とのすべてのプロトコル相互作用を完了する。Fay が保有するクレデンシャルは MUST iFay_Runtime を通じて端末に提出される。

1.1.4 ランタイム役割

iFay_Runtime は Fay インスタンスのランタイム環境であり、プロトコルメッセージの発信と受信を担う。1 つの iFay_Runtime インスタンスは MAY 複数の Fay インスタンスを管理する。

iFay_Runtime は MUST 第 0.5.3 節で定義されたランタイム適合性レベル要件を満たす。

1.1.5 端末役割

端末（Terminal）は Terminal_Resource の保有者であり、アクセス制御の実行者である。端末は以下の規範的コンポーネントを統合する：

  • Protocol_Engine：CAP プロトコルのコアロジックを実行するシステムコンポーネント
  • Descriptor_Validator：Authorization_Descriptor の合法性と有効性の検証を担当するコンポーネント
  • Session 管理器：Session 状態機械と Liveness_Detection メカニズムを維持する
  • ローカル失効リスト：既知の失効済みクレデンシャル識別子を保管する

端末は MUST 第 0.5.1 節で定義された端末適合性レベル要件を満たす。

1.1.6 信頼インフラ役割

Registration_Authority（登録機関）は端末の登録管理および Verification_Key の配布を担当する。Registration_Authority は CAP プロトコル信頼チェーンのルートアンカーである。

Registration_Authority は MUST：

  1. 身元検証を通過した端末にのみ Verification_Key を配布する
  2. 安全なチャネル（第 8 章を参照）を通じて鍵配布を完了する
  3. 鍵更新およびローテーションメカニズムを提供する
  4. 端末登録状態の権威ある記録を維持する

1.2 信頼チェーン

CAP プロトコルの信頼チェーンは認可者から端末の Descriptor_Validator に伝達され、独立しつつ協調する 2 本の信頼パスから構成される。

1.2.1 認可信頼パス

認可信頼パスはある Fay があるリソースへのアクセスを認可されているかを決定する：

認可者（Natural_Person / Official_Post）
    │
    │ ① 認可委任（否認不可な証拠付き）
    ▼
Descriptor_Issuer
    │
    │ ② Authorization_Descriptor の発行（デジタル署名付き）
    ▼
Fay
    │
    │ ③ Authorization_Descriptor の提出
    ▼
Descriptor_Validator

端末は MUST 認可信頼パス上の各環節の真正性を検証する：

  • ステップ ① の真正性は Descriptor_Issuer が発行時に検証し、端末は直接関与しない
  • ステップ ② の真正性は端末が Descriptor_Issuer のデジタル署名を検証することで確認する（鍵信頼パスに依存）
  • ステップ ③ の真正性は端末が Authorization_Descriptor と提出側 Fay 識別子のバインディング関係を検証することで確認する

1.2.2 鍵信頼パス

鍵信頼パスは端末がある Descriptor_Issuer の署名を信頼するかを決定する：

Registration_Authority（信頼アンカー）
    │
    │ ① Verification_Key の配布（安全なチャネル経由）
    ▼
端末ローカル鍵ストア
    │
    │ ② Verification_Key を Descriptor_Validator に提供
    ▼
Descriptor_Validator
    │
    │ ③ Verification_Key で Authorization_Descriptor の署名を検証
    ▼
検証通過 / 拒否

端末は MUST：

  1. Registration_Authority によって配布された Verification_Key のみを信頼する
  2. Verification_Key を安全に保管する（鍵保管要件は第 8 章を参照）
  3. Registration_Authority によって配布されていない鍵を使用した署名検証を拒否する

1.3 外部インタフェース契約

CAP プロトコル層は明確に定義されたインタフェースを通じて 4 つの外部システムと相互作用する。本節はこれらインタフェースの規範的契約を定義する。

1.3.1 iFay_Runtime とのインタフェース

iFay_Runtime と端末 Protocol_Engine の間のインタフェースは双方向メッセージインタフェースである。

メッセージ方向：iFay_Runtime → Protocol_Engine

メッセージ種別用途必須フィールド
AuthRequest認可検証要求の発信fay_id, resource_id, access_mode, credential
SessionReleaseセッションの主動解放session_id
Heartbeatアプリケーション層ハートビートsession_id, sequence_number
HandoverResponseハンドオーバー要求への応答handover_id, accept

メッセージ方向：Protocol_Engine → iFay_Runtime

メッセージ種別用途必須フィールド
AuthResult認可検証結果request_id, status, session_id（成功時）, error_code（失敗時）
SessionStateChangedセッション状態変更通知session_id, new_state, reason
HandoverRequestハンドオーバー要求通知handover_id, target_resource_id, deadline
HeartbeatAckハートビート確認session_id, sequence_number

インタフェース実装は MUST：

  1. Heartbeat および非同期プッシュメッセージを担うため、持続接続をサポートする
  2. TLS 暗号化伝送をサポートする
  3. シリアライゼーション形式は schema.json 定義に従う

インタフェース実装は MAY：

  1. 具体的な伝送プロトコル（WebSocket、gRPC、HTTP/2 等）を選択する

1.3.2 端末オペレーティングシステムとのインタフェース

Protocol_Engine と端末オペレーティングシステムの間のインタフェースはローカル双方向インタフェースである。

オペレーティングシステムは MUST 以下の能力を Protocol_Engine に公開する：

  1. リソースアクセス制御の下発：Protocol_Engine が「Fay X がリソース Z にモード Y でアクセスすることを許可」する指示を下発する
  2. リソース状態照会：Protocol_Engine がリソースの現在の可用性と占有状態を照会する
  3. リソースイベント購読：Protocol_Engine がリソース状態変化イベント（ハードウェア切断、ソフトウェアクラッシュ等）を購読する

インタフェースの具体的実装方式はオペレーティングシステムプラットフォーム（Unix Domain Socket、Named Pipe、D-Bus 等）に依存する。本仕様は具体的実装方式を規定しないが、MUST 以下を満たす：

  1. アクセス制御指示は同期方式で実行され、実行結果を返却する
  2. リソースイベントは非同期プッシュ方式で通知される
  3. インタフェースはオペレーティングシステムネイティブのセキュリティモデルにより保護され、認可された Protocol_Engine プロセスのみが呼び出せる

1.3.3 ハードウェアドライバとのインタフェース（間接）

Protocol_Engine は MUST NOT ハードウェアドライバと直接通信する。すべてのハードウェア制御はオペレーティングシステムを介して転送される。

ハードウェアドライバから Protocol_Engine への状態報告経路：

ハードウェアドライバ → オペレーティングシステム → Protocol_Engine

ハードウェアドライバは SHOULD ハードウェアレベルのアクセスロックメカニズムを実装し、オペレーティングシステム層のアクセス制御がバイパスされた場合でも、ハードウェア自体が未認可アクセスを拒否できることを保証する。

1.3.4 Registration_Authority とのインタフェース

Registration_Authority と端末の間のインタフェースは単方向インタフェースである（RA → 端末）。

Registration_Authority は MUST 以下のメッセージを端末にプッシュする：

メッセージ種別用途必須フィールド
VerificationKeyDistribution新しい検証鍵の配布key_id, key_material, valid_from, issuer_id
VerificationKeyRevocation検証鍵の失効key_id, revocation_time, reason
RegistrationStatusUpdate端末登録状態の更新terminal_id, new_status

端末は MUST：

  1. TLS/mTLS の安全なチャネルを通じてメッセージを受信する
  2. メッセージの署名元が信頼されている Registration_Authority であることを検証する
  3. 新しい鍵を受信した後、Registration_Authority に確認を返却する

端末は Registration_Authority に対してプロトコルメッセージを主動的に発信しない（端末の初期登録フローは CAP プロトコルランタイムの常態相互作用に属さず、本仕様の範囲外）。

1.4 役割と適合性レベルの対応表

実装する役割必ず満たすべき適合性レベル
端末（Protocol_Engine と Descriptor_Validator を含む）端末適合性レベル（§0.5.1）
Descriptor_Issuer または Ticket_Issuer発行者適合性レベル（§0.5.2）
iFay_Runtimeランタイム適合性レベル（§0.5.3）
Registration_Authority本仕様の適合性範囲外（登録フローは CAP プロトコルランタイムを超える）