BLUEPRINT

1 プロトコルの位置づけと境界

第1章：プロトコルの位置づけと境界

1.1 iFay 体系における CAP の役割

Control Authority Protocol（CAP）は、iFay 体系において単一かつ明確なコア責務を担う：Fay（iFay または coFay）がその人間ホスト（Natural_Person）または公式ポスト（Official_Post）から認可を得ているかを検証し、端末リソース（Terminal_Resource）への合法的なアクセスを可能にすること。

具体的には、CAP プロトコルは以下の業務を担当する：

  • 認可検証：Fay が端末上のソフトウェアまたはハードウェアリソースへのアクセスを要求した際、CAP プロトコルはその認可資格情報（Authorization_Descriptor または Trusted_Ticket）が合法的で、有効で、失効していないかを検証する。例えば、ユーザーの iFay がスマートフォンのカメラを起動して写真を撮ろうとする場合、端末はまずその iFay がユーザーからカメラの使用を認可されていることを検証する必要がある
  • セッション管理：認可検証を通過した Fay に対して制御セッション（Session）を確立し、セッションの完全なライフサイクルを管理する。例えば、iFay が認可を得てブラウザの操作を開始した場合、ブラウザを開いてから閉じるまでの全プロセスが1つの完全な制御セッションとなる
  • 制御権の調整：複数の Fay、または Fay と人間ユーザーの間で端末リソースの制御権の割り当てとハンドオーバーを調整する。例えば、手動操縦されているドローンを Fay に引き渡して自律飛行させる場合や、2つの iFay が同一のプリンターを順次使用する必要がある場合
  • リソースアクセスの階層化：操作タイプ（読み取り、書き込み、実行、設定）に基づいてリソースアクセスを階層的に管理する。例えば、iFay が温度センサーのデータを読み取るには read 権限のみが必要だが、エアコンの温度設定を変更するには write 権限が必要となる
  • 生存検知：アクティブセッションの生存状態を監視し、失効したセッションが占有するリソースを適時に回収する。例えば、iFay がネットワーク中断により接続を失った後、端末がハートビートタイムアウトを検知し、その iFay が占有していたカメラの制御権を自動的に解放して、リソースが「ゾンビセッション」に長期間ロックされることを防ぐ

CAP プロトコルは、iFay 体系においてインテリジェントエージェントと端末リソースを結ぶ重要な橋渡し役である——Fay が誰であるか、何ができるかには関与せず、Fay がある操作を行うことを許可されているかどうかのみに関与する。

1.2 CAP が担当しない責務範囲

責務境界を明確にするため、CAP プロトコルは以下の事項を明確に担当しない：

  1. Fay のアイデンティティ作成と管理：Fay エンティティの登録、アイデンティティ識別子の割り当て、アイデンティティ属性の維持などの業務は iFay 体系のアイデンティティ管理サブシステムが担当する。CAP は認可検証のためにアイデンティティ情報を利用するのみで、アイデンティティの作成や管理プロセスには関与しない。例えば、「この iFay の名前は何か、誰に属するか」はアイデンティティ管理システムが決定し、CAP は「この iFay がカメラの使用を許可されているか」のみに関心を持つ
  2. Fay のインテリジェント推論能力：Fay がユーザーの意図をどのように理解するか、操作手順をどのように計画するか、インテリジェント推論をどのように実行するかなどの能力は Fay 自身のインテリジェンス層に属し、CAP プロトコルとは無関係である。CAP は Fay のインテリジェンスレベルに対していかなる仮定も要件も設けない。例えば、iFay がまずブラウザを開いてから航空券を検索するという判断——この意思決定プロセスは CAP とは無関係であり、CAP は iFay が実際にブラウザを開くことを要求した時点でのみ認可検証を行う
  3. 端末リソースの具体的なビジネスロジック：端末上のソフトウェアが操作指令にどのように応答するか、ハードウェアが具体的な機能をどのように実行するかなどのビジネスロジックは端末リソース自身が実装する。CAP は認可検証とアクセス制御のみを担当し、リソースの具体的なビジネス処理には介入しない。例えば、プリンターがどのようにレイアウトするか、どのインクカートリッジで印刷するかはプリンター自身のビジネスロジックであり、CAP は iFay がプリンターを使用する権限を持っているかの検証のみを担当する
  4. ネットワーク通信プロトコルの実装：CAP は認可検証の論理フローとメッセージフォーマットを定義するが、下位ネットワーク転送プロトコルの具体的な実装方式は規定しない。例えば、端末と iFay_Runtime 間の通信に WebSocket を使用するか gRPC を使用するかについて、CAP は制限を設けない
  5. 端末オペレーティングシステムの内部セキュリティメカニズム：オペレーティングシステム自体のユーザー権限管理、サンドボックス分離、プロセスセキュリティなどのメカニズムは CAP の管轄範囲外であり、CAP はオペレーティングシステムとの統合インターフェースを通じて協調する。例えば、Android システム自体のアプリケーションサンドボックスメカニズムは Android が管理し、CAP は Android が提供するインターフェースを通じてアクセス制御指令を発行する

1.3 他のサブプロジェクトとの関係

CAP プロトコルは iFay 体系において以下のサブプロジェクトと明確な相互関係を持つ：

サブプロジェクト関係の説明相互作用の境界
iFay_RuntimeCAP の主要な呼び出し元。iFay_Runtime は Fay インスタンスのライフサイクル管理とスケジューリングを担当し、Fay が端末リソースにアクセスする必要がある場合、iFay_Runtime が代わりに制御権リクエストを発行するiFay_Runtime → CAP：認可検証リクエストの発行；CAP → iFay_Runtime：検証結果とセッション情報の返却
Registration_AuthorityCAP の信頼基盤インフラストラクチャの依存先。Registration_Authority は端末ハードウェア、ソフトウェア、オペレーティングシステムの登録を担当し、端末に検証鍵（Verification_Key）を配布するRegistration_Authority → 端末：Verification_Key の配布；端末は Verification_Key を使用して Authorization_Descriptor の署名を検証する
Descriptor_IssuerCAP の認可資格情報の発行元。Descriptor_Issuer は Natural_Person または Official_Post の認可を受けて Authorization_Descriptor の生成と発行を担当するDescriptor_Issuer → Fay：Authorization_Descriptor の発行；Fay は Authorization_Descriptor を携帯して端末にアクセスリクエストを発行する
アイデンティティ管理サブシステムCAP のアイデンティティ情報の提供元。CAP は認可検証プロセスにおいて Fay のアイデンティティ識別子を参照する必要があるが、アイデンティティの作成や管理には関与しないアイデンティティ管理 → CAP：Fay アイデンティティ識別子情報の提供（一方向依存）

CAP プロトコルの設計原則は、自身の責務の凝集性を維持することである：認可検証と制御権管理のみを行い、アイデンティティ管理、インテリジェント推論、リソースビジネスロジックなどの責務は体系内の他のサブプロジェクトに委ねる。

1.4 適用シナリオ

CAP プロトコルのコア適用シナリオは：iFay が人間ホストの端末を引き継ぎ、人間と同様に端末上のソフトウェアを使用し、端末のハードウェアを呼び出すことである。

このシナリオにおいて、人間ホスト（Natural_Person）は自身の端末デバイスの一部または全部の制御権を iFay に付与し、iFay が代わりに端末上のクライアントソフトウェア（ブラウザ、メールクライアント、オフィスソフトウェアなど）やハードウェアデバイス（カメラ、マイク、ストレージデバイスなど）を操作する。CAP プロトコルはこのプロセスにおいて以下を保証する：

  • 認可の合法性：端末は iFay が確かに人間ホストの認可を得ていることを検証でき、未認可の不正アクセスではないことを確認する。例えば、張三の iFay が李四のノートパソコンを操作しようとした場合、端末は李四が発行した認可資格情報がないためアクセスを拒否する
  • オフライン可用性：端末がオフライン状態であっても、iFay が有効な Authorization_Descriptor を保持していれば、認可されたリソースに合法的にアクセスできる。例えば、ユーザーが飛行機で機内モードを有効にしても、iFay は事前に保存されたオフライン認可ファイルを使用してノートパソコン上のオフィスソフトウェアの操作を継続できる
  • 多者間調整：複数の Fay、または Fay と人間ユーザーが同時に同一の端末リソースにアクセスする必要がある場合、CAP プロトコルは制御権ハンドオーバーとリソースアクセスモード管理機能を提供する。例えば、ユーザーがスマートフォンで写真を撮影中に iFay もドキュメントスキャンのためにカメラを使用する必要がある場合、CAP プロトコルが両者の使用順序を調整する
  • 安全かつ制御可能：すべての認可検証とリソースアクセス操作は監査可能であり、認可はいつでも失効させることができる。例えば、ユーザーが iFay の異常な動作を発見した場合、すべての端末リソースに対する認可を即座に失効させることができ、iFay のアクティブセッションは強制終了される

同様のプロトコルフレームワークは coFay シナリオにも適用される——協働型 Fay エンティティが公式ポスト（Official_Post）の認可を受けて、組織の端末デバイスを引き継ぎ協働タスクを実行する。

1.5 コア設計原則

CAP プロトコルはオフライン優先、オンライン補完のコア設計原則に従う。

オフライン認可（Authorization_Descriptor）が中核メカニズムである。 端末デバイスはネットワークが利用できないことを理由に Fay の引き継ぎ権を完全に剥奪すべきではない。Fay が事前に人間ホストの認可を得ている場合、この認可関係は暗号化ファイルの形式で端末ローカルに保存されるべきであり、端末がオフライン状態でも独立して認可検証を完了できるようにする。Authorization_Descriptor はまさにこの理念の具体的な実現である——端末ローカルに保存される暗号化認可記述ファイルであり、Fay が認可されたリソース範囲、権限タイプ、有効期間を含み、端末側の Descriptor_Validator がネットワーク接続なしで検証を完了できる。

オンラインチケット（Trusted_Ticket）は補完メカニズムである。 ネットワーク接続環境下で、Trusted_Ticket はリアルタイムの認可発行と失効状態照会機能を提供し、オフライン認可の即時性と失効応答速度の不足を補う。オンラインサービスが利用可能な場合、端末は Trusted_Ticket を通じて最新の認可状態を取得できる。オンラインサービスが利用できない場合、端末は自動的にローカルの Authorization_Descriptor 検証にフォールバックし、サービスの中断を防ぐ。

この設計原則のコアとなる考慮事項は：

  • 可用性優先：ネットワーク中断は Fay が動作できない理由にはならず、オフライン認可が基本的な可用性を保証する。例えば、ユーザーが地下鉄でスマートフォンの電波が途切れても、iFay はローカル認可ファイルを使用してスマートフォン上のオフラインアプリの操作を継続できる
  • セキュリティ強化：オンラインチケットはネットワーク接続時により強力なリアルタイムセキュリティ保証を提供し、即時失効や動的権限調整を含む
  • 段階的デグレード：オンラインからオフラインへの切り替えはスムーズであり、サービスの突然の中断を引き起こさない。オンラインで発行された Trusted_Ticket はオフライン使用のためにローカルの Authorization_Descriptor フォーマットに変換できる。例えば、ユーザーが Wi-Fi 環境下でオンラインチケットを通じて iFay にカメラの使用を認可し、ユーザーが Wi-Fi の範囲外に出た後、その認可は自動的にオフラインモードに降格して引き続き有効となる