仕様

Faying Protocol/1.0 — §11 Open Questions

プロトコル本文ナビ：章目次 ｜ 前章 §10 エラー処理 ｜ 次章 付録 A 用語アライメント早見表

§11 Open Questions

本章は、Phase 1 のプロトコル本文では必ずしも答える必要がなく、プロトコル委員会が RFC 段階で決議に委ねる課題を率直に並べる。各課題には現時点のプロトコルの傾向、代替案、決議ステータスを与え、後続の RFC 議論が構造化された出発点を持てるようにする。決議済みの項目（Q10 プロトコル命名など）は歴史記録として残す。

Q1 Rogue 期間中の端末の位置報告

  • 課題：iFay が Rogue Fay 状態の期間中、端末が物理位置の報告を続けることを許すか？「プライバシー vs 取り戻し可能性」の両面での綱引きが関わる。
  • 現時点のプロトコルの傾向：RevokeReason ごとに差別化する——human-initiated / task-completed は報告しない。fay-credential-invalid / regulatory-order / terminal-disconnected などは報告可。
  • 代替案：（a）一律禁止。（b）一律許可。（c）HP が BOOTSTRAP 時に明示的に事前選択する。
  • 決議ステータス：未決。ブループリント第 14 章はすでに明示的に結論を出さないとしている。

Q2 G0 Emergency Override の拒否不能な経路

  • 課題：IF がすでに攻撃者に制御された極端な情形において、G0 メッセージが依然として IF カーネルで実行されることをどう保証するか？
  • 現時点のプロトコルの傾向：プロトコル層は G0 メッセージが最優先を持つことを強制する（詳細は §7.2 / P12 G0 Override 優先度）が、IF カーネルがすでに攻略されているときは純粋なプロトコル層の手段では不十分であることを認める。
  • 代替案：（a）ハードウェアレベルの kill-switch 強制。（b）TPM-quote 二重署名確認。（c）プロトコル層の強制を維持し、ハードウェア経路はエコシステム実装の自由裁量に委ねる。
  • 決議ステータス：未決。Phase 2 / Phase 3 の端末接管と深く結合する。

Q3 PQC 既定のタイムテーブル

  • 課題：Ed25519 + ML-DSA-65 hybrid はいつ OPTIONAL から MUST へ引き上げるか？
  • 現時点のプロトコルの傾向：1.0 は OPTIONAL のみを宣言（PQC スイートの協商可能ビットは §6.1 参照）。NIST の最終標準がすべて公布された後にタイムテーブルを策定する。
  • 代替案：（a）NIST のすべての PQC 標準の確定を待つ。（b）最初に標準化された署名アルゴリズムに追従する。（c）grade ごとに差別化（高機微の場面が先行して MUST）。
  • 決議ステータス：未決。NIST PQC 標準化の進捗待ち。

Q4 人類原型をまたぐ iFay ↔ iFay 協働（Phase 4/5）

  • 課題：異なる HP に属する 2 つの iFay が協働するとき、責任の伝達方式をどう確定するか？
  • 現時点のプロトコルの傾向：1.0 はカバーしない。Phase 4 で coFay を導入する際に定める。
  • 代替案：（a）発起側が責任を負う。（b）受信側が責任を負う。（c）規則に従って分担する。（d）双方の HP の共同見証を必須とする。
  • 決議ステータス：未決。法務—プロトコルの二軌道での議論を要する。

Q5 Ego 逸脱の客観的判定

  • 課題：プロトコル層は ego-deviation の最低判定信号集合を規定すべきか？
  • 現時点のプロトコルの傾向：プロトコル層は RevokeReason="ego-deviation" の意味論とトリガー後の結果（§EH.1、§3.6 BBS）のみを定義する。具体的な判定信号集合は実装の自由裁量に委ねる。
  • 代替案：（a）プロトコル層が最低信号集合を規定する。（b）§3.6 Behavior Baseline Service が明示的に制約する。（c）現状の空白を維持する。
  • 決議ステータス：未決。Q13 行為ベースラインの標準化と結合する。

Q6 Mandate 更新の方針

  • 課題：プロトコルは「自動更新」のすべての形態を禁止すべきか？
  • 現時点のプロトコルの傾向：すべての自動更新の形態を禁止する。各更新は必ず HP の明示的見証を経る（ブループリント第 10 章の傾向）。
  • 代替案：（a）「HP の周期的事前署名を要する限定的な自動更新」を許す。（b）低リスク grade（G3/G4）の自動更新を許す。（c）禁止を維持する。
  • 決議ステータス：未決。プロトコル委員会の取捨待ち。

Q7 オフライン / 弱ネットワーク環境

  • 課題：RR が到達不能なエッジの場面（ドローンの連絡途絶）において、「期限付き自律 + 再接続後の強制照合」の弱化モードを許すか？
  • 現時点のプロトコルの傾向：Endorsed_Mandate（§7.5、§9.8、§4.3 Disconnected）を通じて「期限付き自律 + 再接続照合」を明示的にモデル化する。非 Endorsed 経路は厳格に Default-Deny（詳細は P17.2 悲観的推定）。
  • 代替案：（a）Endorsed_Mandate のみに頼る。（b）「リージョンレベルの RR キャッシュ」を導入する。（c）厳格な Default-Deny でいかなる例外も開かない。
  • 決議ステータス：部分決議（Endorsed_Mandate はすでに §7.5 で落とし込み済み）。オフライン戦略の上限は Q11 の決議待ち。

Q8 サブエージェントの「補足グレード」

  • 課題：G0 Emergency_Override と G1 Strict / G2 Moderate / G3 Loose / G4 Autonomous の 5 段階体系で十分か？
  • 現時点のプロトコルの傾向：1.0 は 5 段階を維持（§7.1）。G2.5 などの中間段位を導入しない。
  • 代替案：（a）「半自律 + 介入可能」の中間段位を導入する。（b）実装が独自の子グレードを定義することを許すが、5 段階のいずれかへマッピングして戻す。（c）直交した Endorsement Grades 子グレードを導入する（すでに §7.5 で落とし込み済み）。
  • 決議ステータス：部分決議（Endorsement Grades はすでに G1–G4 へ直交的に重ねられている）。中間段位は Open を維持。

Q9 撤回連鎖の境界

  • 課題：DELEGATE の連鎖撤回の既定値（cascade=true）について、多層派生時の可視性をどう保証するか？
  • 現時点のプロトコルの傾向：既定 cascade=true（§5.3.5）。可視性は RevocationVisibilityBudget が制約する（§9.7、P14 派生横断の連鎖撤回）。
  • 代替案：（a）派生ツリーの深さごとに予算を差別化する。（b）単一の予算 + push / pull の二重経路を維持する。
  • 決議ステータス：未決。conformance テストが深い派生ツリーの実測可視性を探るのを待つ。

Q10 プロトコル命名（決議済み）

  • 課題：プロトコルの正式な命名。
  • 決議の結論：プロトコルは正式に Faying Protocol（独立した略称なし）と命名し、バージョン番号は Faying Protocol/1.0。
  • 決議ステータス：決議済み。本課題は歴史記録として残し、再び議論を開かない。

Q11 Endorsement 最大寿命の上限

  • 課題：プロトコル層は endorsement.endorsed_lifetime のハード上限（≤12h など）を規定すべきか？さらに grade ごとに締めるべきか？
  • 現時点のプロトコルの傾向：付録 B が推奨値（既定 4h、ソフト上限 12h、かつ Mandate.not_after − Mandate.not_before を超えてはならない、詳細は P16.3 / P16.4）を与える。ハード上限は RFC の決議に委ねる。
  • 代替案：（a）プロトコル層が 12h 上限をハードコードする。（b）grade ごとに差別化（G1 ≤ 1h、G4 ≤ 24h など）。（c）推奨値を維持し強制しない。
  • 決議ステータス：未決。Q7 オフライン戦略と結合する。

Q12 双方向 Faying の濫用防護

  • 課題：iFay が能動的に発起した FAYING_REQUEST は、プロトコル層でレート制限（各 (HP, IF) ペアにつき毎分最大 N 回）を強制すべきか？レート制限は ConfirmationRateLimit と同一の予算に組み入れるか？
  • 現時点のプロトコルの傾向：FAYING_REQUEST の頻度は ConfirmationRateLimit と同一の予算に組み入れる（詳細は §5.3.6、§9.10.7、P18.6）。超過すれば §9.10.7 に従って自動降格 / 一時停止。
  • 代替案：（a）独立した予算 FayingRequestRateLimit。（b）grade ごとに予算を差別化する。（c）現状の ConfirmationRateLimit との共有を維持する。
  • 決議ステータス：部分決議（既定の共有予算はすでに §9.10.7 で落とし込み済み）。閾値の上限と独立予算とするかは RFC の決議待ち。

Q13 Behavior_Baseline の標準化

  • 課題：行為ベースラインの算出基準の粒度（action / scope_used / risk_level / affected_resources、または多次元の結合）をプロトコル層で統一して規定すべきか？それとも実装の自由裁量を許しつつ、ベースライン算出基準そのものを Attestation Chain へ書き込むことを要求するか？
  • 現時点のプロトコルの傾向：実装の自由裁量 + ベースライン算出基準そのものを Attestation Chain へ書き込み、基準の変更を監査イベントとみなす（§3.6 I-BBS-3 / P18.5）。
  • 代替案：（a）プロトコル層が強制する（action / scope_used / risk_level / affected_resources の多次元結合による）。（b）自由裁量 + 監査を維持する。（c）「ベースライン schema レジストリ」を導入して基準を統一する。
  • 決議ステータス：未決。Q5 ego-deviation の判定と結合する。

Q14 Atomic_Action 最小粒度の客観的判定基準

  • 課題：「最小の不可分な action」とは何かのプロトコル層での客観的判定は？「action lattice」を導入して、scope.actions と RP 側のアクション集合との間に形式化して整合できる最小粒度の規約を持たせるべきか？
  • 現時点のプロトコルの傾向：プロトコル層は「1 回の呼び出しでちょうど 1 つの Atomic_Action / scope.actions はワイルドカードを許さない」のみを強制する（P18.2 Atomic_Action_Strict）。最小粒度の客観的判定は RP とプロトコル委員会が業界ドメインに応じて規約することに委ねる。
  • 代替案：（a）RP 横断の汎用 action lattice を導入する。（b）RP 業界（金融 / 医療 / IoT）ごとに別々の lattice とする。（c）現状の空白を維持する。
  • 決議ステータス：未決。§9.10.8 T7 拡張スロットと併せて議論する。