SPECIFICATION

第 7 章：リソースアクセスモード

本章は Resource_Access_Mode のセマンティクス、読み書きロックマトリクス、制約条件適用および Session 権限との関係を定義する。本章はブループリント §2.5 の設計意図に対応する。

7.1 モード定義

CAP プロトコルは 4 種類のアクセスモードを定義する：

AccessMode = enum["read", "write", "execute", "configure"]

7.1.1 read

セマンティクス：Terminal_Resource に対し読み取り専用アクセスを行い、リソース状態を変更しない。

典型的操作：

センサーのリアルタイムデータ読み取り（温度、湿度、測位）
メディアファイルの閲覧（写真、動画）
デバイス状態属性の照会（電池残量、接続状態）

並行性：共有可能。複数の Session は MAY 同一リソースの read モードアクセス権を同時に保有できる。

7.1.2 write

セマンティクス：Terminal_Resource に対しデータ書き込みまたは状態変更を行う。

典型的操作：

ストレージデバイスへのファイル書き込み
デバイスの動作パラメータ変更（音量、明るさ、温度設定）
アプリケーションウィンドウへのコンテンツ入力送信

並行性：排他。同一リソースは同一時刻に最多 1 つの Session が write モードを保有する。

7.1.3 execute

セマンティクス：Terminal_Resource に対し操作指示の実行を発動する。

典型的操作：

アプリケーションプログラムの起動
ハードウェア操作指示の発動（撮影、離陸、印刷）
RPC インタフェースの呼び出し

並行性：排他。

write と execute の違い：write はデータ状態を変更し、execute はアクションを発動する（両者とも最終的に状態を変更する場合でも）。端末のアクセス制御粒度は両者を厳密に区別できない可能性があり、その場合実装は MAY execute を write のサブクラスとみなすことができる（write 権限を保有すると自動的に execute 能力を備える）。ただし本仕様のデフォルトセマンティクスは両者独立——execute 権限を保有しても自動的にwrite 権限を取得しないし、その逆も同様。

7.1.4 configure

セマンティクス：Terminal_Resource に対しシステムレベルの構成変更を行う。

典型的操作：

デバイスのハードウェアパラメータ変更（カメラ解像度、ネットワーク SSID）
セキュリティポリシーの調整（ファイアウォール規則、ペアリング設定）
リソースのアクセスポリシー変更（Handover_Policy 構成等）

並行性：排他かつ高権限。configure は通常、行使するためにより高レベルの認可を必要とする（§7.4.3 を参照）。

7.2 読み書きロックマトリクス

読み書きロックマトリクスは同一リソースの異なるモード下での互換性を定義する。新規要求と既存占有の互換性は以下：

既存占有 \ 新規要求	read	write	execute	configure
なし	✓	✓	✓	✓
read（≥1 個）	✓	✗	✗	✗
write	✗	✗	✗	✗
execute	✗	✗	✗	✗
configure	✗	✗	✗	✗

✓：互換、新規要求は直ちに Session を作成することが許可される。 ✗：非互換、新規要求は拒否される（E_RESOURCE_BUSY を返却）。

7.2.1 マトリクスセマンティクス説明

read 同士は相互互換：複数の読み取り専用 Session は並行存在可能
write/execute/configure の任意の 2 者は非互換：任意の排他モードがリソースを占有すると、他の排他モード要求は拒否される
read と排他モードは相互排他：read 占有時は排他要求を禁止；排他占有時は read 要求を禁止

7.2.2 端末の処理

端末は AuthRequest 処理時に MUST：

検証通過後、Session が creating に入る前に、マトリクスに従い互換性をチェック
非互換時は直ちに E_RESOURCE_BUSY を返却し、自動的にキューに入れて待機させない
iFay_Runtime はリトライまたはハンドオーバー要求発信を選択できる（第 6 章を参照）

7.3 Session 権限との関係

7.3.1 権限リスト

各 Session は作成時に granted_modes リストを携帯する（§2.5 を参照）。リスト内容は Authorization_Descriptor.grants または Trusted_Ticket.grants 中のマッチした Grant.modes に由来する。

Fay は当該 Session を通じてリソースを操作する際、granted_modes に含まれるモードのみ使用できる
iFay_Runtime が AuthRequest で指定する access_mode は MUST Grant 認可リストのサブセットである

7.3.2 最小権限原則

iFay_Runtime は SHOULD AuthRequest において現在のタスクに必要な最低権限モードのみを要求する。例えば、データを読み取るだけなら read を要求し、read + write ではない。

発行者は SHOULD Authorization_Descriptor 内で最小権限原則に従い認可し、不要な権限緩和を避ける。

7.3.3 モード間の階層包含なし

CAP v1 において各アクセスモードは相互独立で、階層包含関係なし：

configure を保有しても MUST NOT 自動的に read / write / execute 能力を取得する
write を保有しても MUST NOT 自動的に read 能力を取得する
各アクセスモードは MUST 独立して認可される

実装は MUST NOT 認可範囲を自動拡張する。

7.3.4 権限不可昇格

Session 作成後、その granted_modes は MUST NOT ライフサイクル内で昇格される。Fay がより高権限のモードを必要とする場合：

iFay_Runtime は現在の Session を主動的に解放
必要なモードを備えたクレデンシャルを使用し新しい AuthRequest を発信
端末は完全フローに従い新 Session を作成

実装は MUST NOT いかなる「権限昇格」のランタイムインタフェースも提供しない。

7.4 制約条件適用

Grant.constraints は発行者による認可への付加制限条件である。本仕様は以下の標準制約キーを定義し、実装は MUST サポートする。MAY カスタム制約をサポートする（カスタム制約のセマンティクスは発行者と端末で協議するが、MUST schema ドキュメントで宣言する）。

7.4.1 時間ウィンドウ制約

constraints["time_window"] = "08:00-22:00"           // 毎日 8:00-22:00 有効
constraints["time_window_tz"] = "Asia/Shanghai"     // タイムゾーン、デフォルト UTC

検証タイミング：§3.3.2 ステップ 6 で各 Grant が制約を満たすかチェックする。現在時刻がウィンドウ内にない → Grant マッチしない。

7.4.2 頻度制限制約

constraints["max_calls_per_hour"] = "60"
constraints["max_calls_per_day"]  = "1000"

端末は SHOULD 各 (descriptor_id, fay_id, resource_id) 組み合わせの呼び出しカウントを維持する。制限超過時 → Grant マッチしない（E_RATE_LIMIT_EXCEEDED を返却）。

7.4.3 高機微モード制約

constraints["require_human_confirmation"] = "true"

access_mode == "configure" または当該制約を満たすその他のシナリオで、端末は MUST Session 作成前に人間ユーザーに 1 回限りの確認を要求する。確認 UI は §6.4.3 と同一チャネルを共有する。

7.4.4 地理フェンス制約

constraints["geo_fence"] = "geohash:wx4g0bm"        // 指定された地理範囲内でのみ有効
constraints["geo_fence_radius_m"] = "1000"

端末の位置情報の出所は SHOULD 較正済みの GPS またはネットワーク測位を使用する。位置情報利用不可時 → Grant マッチしない（保守的に拒否）。

7.4.5 未識別制約の処理

端末は未識別の constraints キーに遭遇した場合 MUST：

デフォルトで当該 Grant を拒否（保守原則）
E_UNSUPPORTED_CONSTRAINT を返却し、未識別のキー名を付帯

発行者はカスタム制約使用時、SHOULD 他のチャネルを通じて端末に制約セマンティクスを告知し、認可失敗を回避する。

7.5 モードと OS アクセス制御のマッピング

端末はオペレーティングシステムのアクセス制御インタフェースを通じて access_mode の実行を実施する。本節はモードから OS 制御への推奨マッピングを定義する。具体的実装はプラットフォームによって差異があり得るが、MUST セマンティクス等価性を維持する。

リソース種別	read	write	execute	configure
ファイル/ディレクトリ	ファイルシステム読み取り権限	ファイルシステム書き込み権限	実行権限	メタデータ変更権限
デバイスファイル	デバイス読み取り	デバイス書き込み	ioctl/制御インタフェース	デバイス構成レジスタ
アプリプロセス	状態照会	入力注入	起動/呼び出し	起動パラメータ変更
ネットワークリソース	データ受信	データ送信	接続確立	ルート/ファイアウォール変更
カメラ	画面読み取り	適用なし	撮影/録画制御	解像度/フレームレート調整

プラットフォーム固有のアクセス制御メカニズム（SELinux、AppArmor、macOS Sandbox、Android Permission 等）は端末実装が選択し統合する。

7.6 モード変更の制約

同一 (Session, Resource) は MUST ライフサイクル内で初期の access_mode を維持し変更しない。モード変更は新 Session で実現する：

現在の Session を解放
新 Session 作成時に新 access_mode を指定
端末はマトリクスに従いリソース占有互換性を再評価

端末は MUST NOT「モード切り替え」のランタイムインタフェースを提供しない。

7.7 リソースアクセスの可観測性

端末は SHOULD 各リソースアクセスの重要情報を記録する（監査用）：

session_id
fay_id
resource_id
access_mode
操作種別（読み取りサイズ、書き込みバイト数等）
タイムスタンプ

具体的な監査ログ形式は本仕様の範囲外（ブループリント §3.2 除外項「監査ログ標準形式」を参照）。

7.8 モードセマンティクスの境界

7.8.1 read モードはリソースが並行変更されることを阻止しない

read モードは「読み取り」権限のみを認可し、読み取りプロセス中にリソースが他の制御者によって変更されないことは保証しない：

複数の read Session 間は相互干渉しないが、リソースが「アクティブ Session なし」状態で人間ユーザーが直接操作した場合（CAP プロトコルをバイパス）、read Session は依然変化したデータを読み取る可能性がある
read モードはトランザクション一貫性保証を提供しない

7.8.2 write モードの原子性

write モードはプロトコル層で「同一時刻最多 1 つの write Session」の保証のみを提供する。具体的書き込み操作の原子性（部分書き込み失敗等）はリソースの基底セマンティクスに依存し、CAP プロトコル範囲外。

7.8.3 execute モードの副作用

execute モードが発動する操作は MAY リソース状態を変更する。Fay が execute を通じて発動する副作用は当該 Fay が責任を負う。CAP プロトコルは execute 操作のロールバック能力を提供しない。

7.9 完全決定フロー

端末がリソースアクセスを処理する完全決定フロー：

[AuthRequest 到達]
        │
        ▼
  ┌─────────────────────┐
  │ §3 / §4 クレデンシャル検証 │
  └──────┬──────────────┘
         │ 通過
         ▼
  ┌─────────────────────┐
  │ §7.4 制約条件評価   │
  │ （constraints）     │
  └──────┬──────────────┘
         │ 通過
         ▼
  ┌─────────────────────┐
  │ §7.2 読み書きロックマトリクス検査 │
  └──────┬──────────────┘
         │ 互換
         ▼
  ┌─────────────────────┐
  │ §5.2 Session 作成   │
  └──────┬──────────────┘
         │
         ▼
  ┌─────────────────────┐
  │ §7.5 OS アクセス制御 │
  │     下発            │
  └──────┬──────────────┘
         │
         ▼
  [AuthResult granted を返却]

任一ステップ失敗時は対応するエラーコードを返却し、後続ステップに進まない。