BLUEPRINT

2 コア能力マトリクス

第2章：コア能力マトリクス

本章では、CAP プロトコルの5つのコア能力について戦略レベルの記述を行う。オフライン認可、オンラインチケット、セッション管理、制御権ハンドオーバーポリシー、リソースアクセスモードを網羅する。各能力について設計動機、ライフサイクル、主要メカニズム、ポリシー設定などの観点から展開し、後続のプロトコル技術仕様策定のためのトップレベルガイダンスを提供する。

2.1 オフライン認可（Authorization_Descriptor）

設計動機

Authorization_Descriptor は CAP プロトコルの中核認可メカニズムである。その設計動機は基本的な判断に基づく：端末がオフラインの場合でも Fay の引き継ぎ権を完全に剥奪すべきではない。なぜなら Fay は事前に人間ホストから認可を受けている可能性があるからである。

現実のシナリオでは、端末デバイスはネットワークが利用できない、または不安定な状態に頻繁に置かれる——機内モード、地下空間、遠隔地、ネットワーク障害など。認可検証が完全にオンラインサービスに依存する場合、ネットワークが中断すると、人間ホスト（Natural_Person）または公式ポスト（Official_Post）が事前に明確に認可していたとしても、Fay は端末リソースに対するすべての制御権を即座に喪失する。例えば、野外カメラマンの iFay がドローンの操縦を支援して撮影中、山谷に飛び込んだ後にスマートフォンの電波が途切れた場合——オフライン認可メカニズムがなければ、iFay はドローンの制御権を即座に失い、ドローンが墜落する可能性がある。このような設計は Fay の可用性をネットワーク状態に深刻に依存させることになり、iFay 体系が追求する「インテリジェントエージェントによる端末のシームレスな引き継ぎ」というビジョンに反する。

Authorization_Descriptor は認可関係を暗号化ファイルの形式で端末ローカルに永続化することにより、端末がオフライン状態でも独立して認可検証を完了できるようにする。このファイルには Fay が認可されたリソース範囲、権限タイプ、有効期間が含まれ、端末側の Descriptor_Validator はネットワーク接続なしでその合法性と有効性を検証できる。

ライフサイクル概要

Authorization_Descriptor のライフサイクルは以下の5つのフェーズを含む：

  1. 発行（Issuance）：Descriptor_Issuer が認可者（Natural_Person または Official_Post）の明示的な認可を得た後、Authorization_Descriptor を生成し発行する。発行プロセスには認可範囲の決定、有効期間の設定、デジタル署名の生成などのステップが含まれる。発行完了後、Authorization_Descriptor は対応する Fay エンティティに渡される。例えば、ユーザー張三が認可管理インターフェースを通じて、iFay に今後30日間ノートパソコンのカメラとマイクの使用を認可し、Descriptor_Issuer がこれらの権限を含む Authorization_Descriptor を生成して iFay に渡す。

  2. ローカル保存（Local Storage）：Fay は取得した Authorization_Descriptor をターゲット端末に提出し、端末はそれを暗号化形式でローカルのセキュアストレージ領域に保存する。ローカル保存により端末はオフライン状態でも認可情報にアクセスでき、オフライン認可メカニズムの物理的基盤となる。例えば、iFay が上記の認可ファイルを張三のノートパソコンに提出し、パソコンがそれをローカルのセキュリティチップに暗号化して保存する。

  3. 検証（Validation）：Fay が端末リソースへのアクセスを要求した際、端末側の Descriptor_Validator がローカルに保存された Authorization_Descriptor の検証を行う。検証内容には、デジタル署名の合法性（Verification_Key を使用した検証）、有効期間の超過有無、認可範囲が要求されたリソースと操作タイプをカバーしているか、失効済みかどうかが含まれる。例えば、iFay がカメラの起動を要求した際、端末は認可ファイルの署名が合法か、30日の有効期間内か、カメラの使用権限が含まれているかを確認する。

  4. 失効（Revocation）：認可者が認可を取り消す決定をした場合、失効宣言を発行して対応する Authorization_Descriptor を無効化する。失効宣言は複数のチャネルを通じて端末に配布され（下記「失効宣言配布ポリシー」を参照）、端末は以降の検証で失効済みの Authorization_Descriptor を拒否する。例えば、張三が iFay の動作が期待に沿わないことを発見し、カメラ使用認可を即座に失効させると、端末は次回の検証時にその iFay のカメラアクセス要求を拒否する。

  5. 更新（Renewal）：Authorization_Descriptor が期限切れ間近、または認可範囲の調整が必要な場合、Descriptor_Issuer が新しい Authorization_Descriptor を発行して旧バージョンを置き換える。更新プロセスは本質的に新規発行であり、旧バージョンは新バージョンの発効後に自動的に無効化される。例えば、30日の有効期間が間もなく満了する際、張三が更新を決定し、さらに iFay にストレージデバイスの使用も追加認可する場合、Descriptor_Issuer が新しい認可ファイルを発行して旧バージョンを置き換える。

信頼チェーンモデル

オフライン認可の信頼性は完全な信頼チェーンに依存する。認可者から端末側検証器への信頼伝達パスは以下の通りである：

認可者（Natural_Person / Official_Post）
    │
    │ 認可委任
    ▼
Descriptor_Issuer（認可記述ファイル発行者）
    │
    │ Authorization_Descriptor の発行（デジタル署名付き）
    ▼
Fay（iFay / coFay）
    │
    │ Authorization_Descriptor の提出
    ▼
端末側 Descriptor_Validator
    │
    │ Verification_Key を使用した署名検証
    ▼
検証結果（通過 / 拒否）

信頼チェーンの重要な環節：

  • 認可者 → Descriptor_Issuer：認可者はセキュアな認可委任メカニズムを通じて発行権を Descriptor_Issuer に委任し、認可された発行者のみが合法的な Authorization_Descriptor を生成できることを保証する
  • Descriptor_Issuer → Fay：Descriptor_Issuer は秘密鍵を使用して Authorization_Descriptor にデジタル署名を行い、Fay は署名済みの認可ファイルを取得する
  • Fay → Descriptor_Validator：Fay は端末に Authorization_Descriptor を提出し、端末側の Descriptor_Validator は Registration_Authority が配布した Verification_Key を使用して署名の合法性を検証する
  • Registration_Authority → 端末：Registration_Authority は信頼基盤インフラストラクチャとして端末に Verification_Key を配布し、端末が Authorization_Descriptor の署名元を検証できることを保証する

失効宣言配布ポリシー

オフラインシナリオにおいて、失効宣言の適時な配布はコアとなる課題である。端末はオンライン失効サービスにリアルタイムで照会できない状況下で、可能な限り最新の失効情報を取得する必要がある。CAP プロトコルは以下の配布ポリシーを採用する：

  • ローカル失効リスト（Local Revocation List）：端末はローカル失効リストを維持し、既知の失効済み Authorization_Descriptor 識別子を記録する。端末がネットワークに接続するたびに、失効サービスから最新の失効リストを自動的に同期する
  • ネットワーク接続時の能動的同期：端末がオフライン状態からネットワーク接続状態に復帰した際、失効リストの同期を優先的に行い、ローカルの失効情報が可能な限り最新の状態に近づくことを保証する
  • 有効期間によるフォールバック：Authorization_Descriptor 自体が有効期間を持つため、失効宣言が適時に届かなくても、期限切れの Authorization_Descriptor は自動的に無効化され、失効遅延の最大影響ウィンドウが制限される
  • 次回検証時に有効化：端末は Authorization_Descriptor の検証のたびにローカル失効リストを確認し、失効宣言が端末に到達した後、以降の検証リクエストは失効済みの認可を即座に拒否する

2.2 オンラインチケット（Trusted_Ticket）

位置づけと使用シナリオ

Trusted_Ticket は、CAP プロトコルにおけるネットワーク接続環境下のオンライン認可補完メカニズムである。そのコアとなる位置づけは：ネットワーク接続環境下でリアルタイムの認可発行と失効状態照会機能を提供し、オフライン認可の即時性と失効応答速度の不足を補うことである。

Trusted_Ticket の典型的な使用シナリオには以下が含まれる：

  • 一時的認可：人間ホストが Fay に対して特定リソースへのアクセス権限を一時的に付与する必要がある場合、完全な Authorization_Descriptor 発行フローを経ることなく、オンラインサービスを通じて即座に Trusted_Ticket を発行する。例えば、ユーザーが一時的に iFay にドキュメントの印刷を手伝ってもらう必要がある場合、スマートフォンでワンタップ認可するだけで、オンラインサービスがプリンター使用のみに限定された一時チケットを即座に発行し、完全なオフライン認可発行フローを経る必要がない
  • リアルタイム失効検証：端末はネットワーク接続状態において Trusted_Ticket メカニズムを通じて認可の失効状態をリアルタイムに照会でき、ローカル失効リストよりも迅速な失効情報を取得できる。例えば、会社の管理者がある coFay の会議室機器の制御権を失効させたばかりの場合、ネットワーク接続中の端末はオンラインチケットメカニズムを通じてこの失効を即座に知ることができ、ローカル失効リストの次回同期を待つ必要がない
  • 動的権限調整：ネットワーク接続環境下で、認可範囲を Trusted_Ticket を通じて動的に調整でき、Authorization_Descriptor の再発行が不要となる。例えば、iFay が元々ファイルの読み取り権限のみを持っていた場合、ユーザーがスマートフォンで一時的に書き込み権限に昇格させると、オンラインチケットを通じて即座に有効になる

Authorization_Descriptor との関係

Trusted_Ticket と Authorization_Descriptor の間は補完関係であり、代替関係ではない：

  • Authorization_Descriptor が中核：オフライン認可は常に CAP プロトコルの基盤メカニズムであり、Trusted_Ticket は Authorization_Descriptor 体系から独立して存在することはできない
  • オンライン発行からオフラインフォーマットへの変換：オンラインで発行された Trusted_Ticket はオフライン使用のためにローカルの Authorization_Descriptor フォーマットに変換できる。これにより、Trusted_Ticket を通じて取得した認可はネットワーク中断によって即座に無効化されることはない
  • 優先順位関係：端末が Trusted_Ticket と Authorization_Descriptor の両方を保持している場合、Trusted_Ticket が提供するリアルタイム認可情報が優先的に使用される。その即時性がより高いためである

オンラインからオフラインへのデグレードポリシー

オンラインサービスが利用できない場合、CAP プロトコルはスムーズなデグレードポリシーを実行する：

  1. オンラインサービス状態の検知：端末はオンライン認可サービスとの接続状態を継続的に監視する
  2. 自動フォールバック：オンラインサービスが利用できない場合、端末は自動的にローカルの Authorization_Descriptor 検証にフォールバックし、Fay のリソースアクセスを中断しない
  3. Trusted_Ticket の変換：ネットワーク接続期間中に発行された Trusted_Ticket は既にローカルの Authorization_Descriptor フォーマットに変換して保存されており、デグレード後も引き続き使用できる
  4. 復旧後の同期：オンラインサービスが復旧した際、端末は自動的に Trusted_Ticket メカニズムの使用を再開し、オフライン期間中に見逃された可能性のある失効情報を同期する

デグレードプロセスは Fay に対して透過的である——Fay は端末が現在オンラインチケットとオフライン認可のどちらを使用しているかを認識する必要がなく、認可検証の結果は両方のモードで一貫性を保つ。

2.3 セッション管理（Session）

ライフサイクル

Session（制御セッション）は認可検証の通過からアクセス終了までの完全なライフサイクルであり、以下の3つのフェーズを含む：

  1. 作成（Creation）：Fay の認可検証が通過した後、Protocol_Engine が Session インスタンスを作成する。Session 作成時に、関連する Fay 識別子、ターゲット Terminal_Resource、認可権限リスト、作成時刻が記録される。作成成功後、Fay はターゲットリソースの制御権を取得する。例えば、iFay がノートパソコンのブラウザの使用を要求し、認可検証が通過した後、システムがブラウザにバインドされた制御セッションを作成し、iFay はその時点からブラウザを操作できるようになる。

  2. アクティブ（Active）：Session 作成後、アクティブ状態に入り、Fay は認可権限の範囲内でバインドされた Terminal_Resource に対して操作を実行できる。アクティブ期間中、Liveness_Detection メカニズムがセッションの生存状態を継続的に監視し、Fay がまだ当該セッションを有効に使用していることを確認する。例えば、iFay がブラウザを通じてユーザーの航空便情報を検索中、その間継続的にハートビートを送信してまだアクティブに使用中であることを示す。

  3. 終了（Termination）：Session は以下の方法で終了できる：

    • 能動的解放：Fay が操作を完了した後、能動的に Session を解放し、Terminal_Resource の制御権を返却する。例えば、iFay が航空便検索を完了した後、能動的にブラウザの制御権を解放する
    • タイムアウト終了：Liveness_Detection が Fay セッションがもはやアクティブでないことを検知した場合（ハートビートタイムアウト）、自動的に Session を終了しリソースを回収する。例えば、iFay がランタイムクラッシュによりハートビートの送信を停止した場合、端末はタイムアウト後に自動的にブラウザの制御権を回収する
    • 失効終了：認可が失効した際、関連するアクティブ Session が強制終了される。例えば、ユーザーが iFay が不適切なコンテンツを閲覧していることを発見し、即座に認可を失効させると、ブラウザセッションが強制終了される

Session 終了後、Fay の当該 Terminal_Resource に対する制御権は即座に解除され、リソースは他の制御者が取得可能な状態に復帰する。

Terminal_Resource とのバインド関係

Session と Terminal_Resource の間には厳格なバインド関係が存在する：1つのアクティブ Session は1つの Terminal_Resource の制御権に対応する。

このバインド関係のコアルール：

  • 一対一バインド：各アクティブ Session は1つの具体的な Terminal_Resource にバインドされ、Fay は Session を通じて当該リソースに対して操作を実行する。例えば、iFay が「前面カメラ」にバインドされた Session を取得した場合、この Session を通じて前面カメラのみを操作でき、マイクの操作には使用できない
  • 排他的制御：排他アクセスが必要な操作モード（write、execute、configure）の場合、同一の Terminal_Resource は同一時点で最大1つのアクティブな排他 Session のみを持つ。例えば、iFay-A が write モードで SD カードにデータを書き込んでいる場合、iFay-B は同時に SD カードの write Session を取得できない
  • 複数読み取り並行：read モードの場合、同一の Terminal_Resource に複数のアクティブな読み取り専用 Session が同時に存在できる。例えば、iFay-A と iFay-B は同時に read モードで GPS モジュールの位置データを読み取ることができる
  • ライフサイクル連動：Terminal_Resource が利用不可になった場合（ハードウェア切断など）、当該リソースにバインドされたすべてのアクティブ Session が終了される。例えば、ユーザーが USB カメラを取り外した後、そのカメラにバインドされたすべての Session が自動的に終了される

生存検知メカニズム

Liveness_Detection（生存検知）は長時間接続とアプリケーション層ハートビートの組み合わせにより Fay セッションがまだアクティブであるかを検知する。その設計意図は失効したセッションが占有するリソースを適時に回収することである。

生存検知の動作メカニズム：

  • 長時間接続の維持：Fay と端末の間で長時間接続を通じて通信チャネルを維持し、接続状態を生存検知の基礎シグナルとする
  • アプリケーション層ハートビート：長時間接続の上で、Fay が定期的にアプリケーション層ハートビートメッセージを送信し、現在の Session をまだ有効に使用していることを示す。ハートビート間隔とタイムアウト閾値は設定可能
  • 二重判定：長時間接続の切断とアプリケーション層ハートビートのタイムアウトが同時に満たされた場合にのみ、Session が失効したと判定する。この二重判定メカニズムにより、一時的なネットワーク変動による誤判定を回避する
  • リソース回収：Session が失効と判定された後、Protocol_Engine は自動的に当該 Session を終了し、占有していた Terminal_Resource を解放して、他の制御者がリソースを取得できるようにする

2.4 制御権ハンドオーバーポリシー（Handover_Policy）

コアシナリオ

制御権ハンドオーバーは、複数の制御者が同一の Terminal_Resource を順次使用する必要があるシナリオで発生する。CAP プロトコルは2種類のコアハンドオーバーシナリオを定義する：

  • Fay 間の制御権移転：ある Fay が保持する Terminal_Resource の制御権を別の Fay に移転する。例えば、データ収集を担当する iFay がタスクを完了した後、カメラの制御権をビデオ通話を担当する iFay にハンドオーバーする。また、スマートファクトリーにおいて、品質検査を担当する coFay が製品の撮影を完了した後、産業用カメラの制御権を梱包を担当する coFay にハンドオーバーする
  • Fay と人間ユーザー間の制御権移転：Fay が制御権を人間ユーザーに返却する、または人間ユーザーが制御権を Fay に委任する。例えば、ドローンが iFay により自律巡航中、パイロットが異常気象を発見して手動操縦に切り替える必要がある場合、iFay が即座に飛行制御権を譲渡する。天候が回復した後、パイロットが制御権を iFay に返却して自律飛行を継続させる。また、ユーザーが手動でドキュメントを編集中に iFay にレイアウトを手伝ってもらう必要がある場合、ドキュメントエディタの制御権を一時的に iFay に渡し、レイアウト完了後に iFay が制御権を返却する

ポリシー化設定機能

Handover_Policy はポリシー化された設定機能を提供し、以下の3種類のポリシータイプをサポートする：

  1. 優先度ルールスクリプト（Priority Rule Script）：事前定義されたルールスクリプトにより制御権ハンドオーバーの優先度を決定する。ルールスクリプトは Fay の役割、タスクの緊急度、リソースタイプなどの要素に基づいて優先度スコアを計算し、優先度の高い制御者がリソースの制御権を取得する。このポリシーはハンドオーバールールが明確で事前に定義可能なシナリオに適している。例えば、医療シナリオにおいて、緊急アラートを担当する iFay の優先度は日常データ収集を担当する iFay よりも常に高く、両者が同時に通信モジュールの使用を要求した場合、緊急アラート iFay が自動的に制御権を取得する。

  2. AI モデルリアルタイム判定（AI Model Real-time Decision）：AI モデルが現在のコンテキストに基づいて制御権の割り当てをリアルタイムに判定する。AI モデルは複数の制御者のタスク状態、リソース使用の緊急性、過去のハンドオーバーパターンなどの要素を総合的に考慮して意思決定を行う。このポリシーはハンドオーバールールが複雑で、静的ルールではカバーしきれない動的シナリオに適している。例えば、スマートホームにおいて、セキュリティ監視を担当する iFay とビデオ通話を担当する iFay が同時にカメラを要求した場合、AI モデルが現在セキュリティ上の脅威があるか、通話が緊急かなどのコンテキスト情報に基づいてリアルタイムに優先度を判定する。

  3. 人間ユーザー決定（Human User Decision）：制御権ハンドオーバーの意思決定権を人間ユーザーに委ねる。複数の制御者が同一リソースを競合する場合、端末が人間ユーザーに選択インターフェースを提示し、人間ユーザーがどの制御者に制御権を付与するかを決定する。このポリシーは高感度リソースや人間の判断が必要なシナリオに適している。例えば、2つの iFay が同時にユーザーの銀行アプリの使用を要求した場合、端末がプロンプトを表示してユーザーにどちらに認可するかを決定させる。金融操作には人間の最終確認が必要なためである。

3種類のポリシータイプは Terminal_Resource の粒度で独立して設定でき、同一端末上の異なるリソースに異なるハンドオーバーポリシーを採用できる。

原子性保証

制御権ハンドオーバープロセスは原子性要件を満たす必要がある：任意の時点において、1つの Terminal_Resource は最大1つのアクティブな制御者のみを持つ。

原子性保証の実現原則：

  • 先に解放、後に取得：ハンドオーバープロセスにおいて、元の制御者の Session が先に終了し、新しい制御者の Session が後に作成される。これにより、2つの制御者が同時に同一リソースの制御権を保持する状態が発生しないことを保証する。例えば、ドローンの飛行制御権を iFay-A から iFay-B にハンドオーバーする際、iFay-A の制御セッションが先に終了し、その後 iFay-B の制御セッションが作成される——2つの iFay が同時にドローンの飛行を制御する状況は決して発生しない
  • 不可分：ハンドオーバー操作は一体として実行され、完全に成功する（元の制御者の解放 + 新しい制御者の取得）か、完全に失敗する（ハンドオーバー前の状態にロールバック）かのいずれかである
  • 中間状態の非公開：外部の観察者が任意の時点で見るリソース制御状態は一貫しており、ハンドオーバープロセス中の中間状態を観察することはない

タイムアウト処理原則

制御権ハンドオーバープロセスは、さまざまな理由（ネットワーク遅延、制御者の無応答など）により予定時間内に完了しない場合がある。CAP プロトコルのハンドオーバータイムアウトに対する処理原則は：タイムアウトにより完了しなかったハンドオーバーはハンドオーバー前の状態にロールバックし、元の制御者のセッションを変更しないことである。

具体的な処理ルール：

  • タイムアウト閾値は設定可能：各ハンドオーバーポリシーに独立したタイムアウト閾値を設定でき、異なるシナリオの時間要件に対応する
  • ロールバック保護：タイムアウトが発生した後、ハンドオーバー操作は自動的にロールバックし、元の制御者の Session はアクティブ状態を維持して影響を受けない。例えば、iFay-A がカメラを制御中に iFay-B への制御権ハンドオーバーを試みたが、iFay-B がネットワーク遅延により規定時間内に応答できなかった場合、ハンドオーバーは自動的にロールバックし、iFay-A がカメラの制御を継続する
  • 通知メカニズム：タイムアウトロールバック後、Protocol_Engine は関連する制御者にハンドオーバー失敗通知を送信し、タイムアウトの理由を説明する
  • リトライポリシー：ハンドオーバー失敗後、ポリシー設定に基づいて自動リトライするか、手動介入を待つかを決定できる

2.5 リソースアクセスモード（Resource_Access_Mode）

階層モデル

Resource_Access_Mode は操作タイプに基づいてリソースアクセスを4種類のモードに分類し、低から高への権限階層を形成する：

  1. read（読み取り）：Terminal_Resource に対する読み取り専用アクセスで、リソース状態を変更しない。例えば温度センサーのリアルタイムデータの読み取り、ユーザーのフォトアルバム内の写真の閲覧、GPS モジュールの現在位置情報の取得など。read モードは共有可能であり、複数の Fay が同時に同一リソースに read モードでアクセスできる——例えば、複数の iFay が同一の温度センサーのデータを同時に読み取っても互いに干渉しない。

  2. write（書き込み）：Terminal_Resource に対するデータ書き込みまたは状態変更。例えば撮影した写真のストレージデバイスへの保存、スマートホームデバイスの温度設定値の変更、ドキュメントへの内容の書き込みなど。write モードは排他的であり、同一時点で1つの制御者のみが write モードでリソースにアクセスできる——例えば、2つの iFay が同一ファイルに同時にデータを書き込むことはできない。データ破損を引き起こすためである。

  3. execute（実行）：Terminal_Resource に対する操作指令の実行。例えばスマートフォンのナビゲーションアプリの起動、ドローンの離陸指令のトリガー、プリンターの印刷タスクの実行など。execute モードは排他的であり、操作指令の実行が他の制御者に干渉されないことを保証する——例えば、ある iFay がドローンの着陸手順を制御中に、別の iFay が同時に離陸指令を送信することはできない。

  4. configure（設定）：Terminal_Resource に対するシステムレベルの設定変更。例えばカメラの解像度とフレームレートパラメータの変更、ネットワークファイアウォールルールの調整、Bluetooth モジュールのペアリング設定の変更など。configure モードは排他的かつ高権限であり、通常はより高いレベルの認可が必要となる——例えば、ルーターのセキュリティポリシーの変更は、単にネットワーク状態を読み取るよりも高い認可レベルが必要である。

読み書きロックの本質

Resource_Access_Mode の並行制御は本質的に読み書きロック（Read-Write Lock）モデルである：

  • read 操作は複数の Fay による並行アクセスを許可する：複数の Fay が同一の Terminal_Resource の read モード Session を同時に保持でき、互いに干渉しない。これは読み書きロックにおける共有ロック（Shared Lock）に類似する。例えば、3つの iFay が同一の気象センサーの温湿度データを同時に読み取っても、互いにブロックしない
  • write、execute、configure 操作は排他制御を要求する：いずれかの Fay が write、execute、または configure モードでリソースにアクセスしている場合、他の Fay は同時にいかなる書き込み系モードでも当該リソースにアクセスできない。これは読み書きロックにおける排他ロック（Exclusive Lock）に類似する。例えば、ある iFay が SD カードにビデオファイルを書き込んでいる場合、別の iFay が同時に同じ SD カードに写真を書き込むことはできない
  • 読み書き相互排他：リソース上にアクティブな write、execute、または configure Session が存在する場合、新しい read リクエストも排他 Session が解放されるまでブロックされる。逆に、リソース上にアクティブな read Session が存在する場合、write、execute、configure リクエストはすべての read Session が終了するまで待機する。例えば、iFay が設定ファイルを変更中（write モード）の場合、別の iFay がそのファイルを読み取ろうとしても書き込みが完了するまで待つ必要がある。不整合な中間状態を読み取ることを避けるためである

この読み書きロックモデルは、データの一貫性と操作の安全性を保証しつつ、read 操作の並行性能を最大化する。

Session 権限との関係

Resource_Access_Mode と Session の認可権限は密接に関連する：Session の認可権限リストが Fay が実行可能な操作タイプを決定する。

具体的な関係は以下の通り：

  • 権限リストの制約：各 Session は作成時に認可権限リストを持ち、このリストは Authorization_Descriptor または Trusted_Ticket で定義された権限範囲に由来する。Fay は権限リストに含まれるモードでのみリソースにアクセスできる
  • 最小権限の原則：Session の権限リストは最小権限の原則に従い、Fay が現在のタスクを完了するために必要な最低限の権限モードのみを含むべきである
  • 権限の昇格不可：Session 作成後、そのセッションのライフサイクル内で権限リストを昇格させることはできない。Fay がより高い権限のアクセスモードを必要とする場合、新しい認可検証を通じて新しい Session を作成する必要がある
  • 権限階層の非包含：高権限モードは低権限モードの能力を自動的に包含しない。例えば、configure 権限を持つことは自動的に read 権限を持つことを意味せず、各アクセスモードは独立した認可が必要である