Summary

  • draft-sankarshan-agent-registry-protocol-04 は、しきい値、定足数、役割による集団判断を、一つの明示された構成員・管理者・行使規則スナップショットへ結び付けるよう求める。
  • ローカル構成では、BのS1承認とDのS2承認は個別には有効でも、S1とS2はそれぞれ一票しか持たず、どのスナップショットも2-of-3を満たさない。
  • スナップショットをまたぐ合算は、統治規則が明示的に許可し、証拠が許可された移行を示す場合に限られる。

監査時に失われていたもの

最初の状態S1では、構成員はA、B、Cで、正確に同じ操作について現任の異なる二人が承認することが条件だった。Bが承認した時点では一票である。

その後Bが離れ、Dが加わった。S2はA、C、Dで構成され、見かけ上は同じ2-of-3規則を使う。Dも承認したが、S2にも一票しかない。

操作だけで行をまとめる集計は、BとDという二人を数えて成功を返す。両方の署名が本物で、操作ダイジェストが一致し、各承認者がその時点で資格を持っていたとしても結論は変わらない。BはS2の構成員ではなく、DはS1の構成員ではなかった。二票を収容する一つの集団状態が存在しないからだ。

ローカル構成は操作を sha256:8b826aaafbce2a9ca1b653ba3ae6992074fff22fa3b261b49f27704b2afab5c3 に固定した。スナップショットを捨てた集計だけが許可を返し、S1とS2に分ければ各一票で不成立となる。これは有限集合による説明であり、ARPA実装、適合性試験、実運用障害の証拠ではない。

集団主体は名称ではなく状態で行為する

改訂04の第23.4節は、集団がしきい値、定足数、役割などの規則によって権限を行使する場合、評価者が現在の構成員または管理者集合、現在の行使規則、そして数える寄与を確立しなければならないとする。

構成員であることは集団権限の個人的な所有を意味しない。同一人物を重複して数えるには、独立して行使できる複数役割を規則が明示し、その役割を証拠が確立する必要がある。古い構成員情報や旧規則は、新しい重要操作を肯定できない。

第25.4節は、判断そのものを一つのスナップショットへ固定する。安定したチェックポイント、版、またはダイジェストで構成員・管理者と行使規則を識別し、数える承認はすべて同じ状態で有効でなければならない。除名と再加入、重大な役割変更、規則変更、古い構成員情報を既定で混ぜてはならず、判断証拠は使用したチェックポイントを保持する。

委員会の表示名は連続していても、権限を行使できる主体は変化する。名称だけを永続化し、状態を捨てると、時系列上の後継関係が同時存在する権限へ変換される。

署名検証の後に三つの問いが残る

真正性は、誰が記録を作ったかを問う。操作結合は、資源、金額、相手方、重要パラメータを含む同一操作を対象としているかを問う。個別資格は、その人が該当時点の構成員、役割、状態の下で承認できたかを問う。集団成立は、十分な数の異なる有資格寄与が一つの規則状態に共存したかを問う。

署名が真正性を支え、正規化した操作ダイジェストが操作結合を支え、権限解決が個別資格を支えても、定足数は自動的には成立しない。B@S1とD@S2は前三問に合格し、最後の問いで失敗できる。

そのため、承認レコードからチェックポイントを省くことは単なる監査品質の低下ではない。集団判断という主張を検証するための結合キーを消している。

役割変更でも同じ問題が起きる。人物の識別子が変わらなくても、財務役から技術役へ移ったなら、古い承認を後から都合のよい役割へ割り当てることはできない。2-of-3から3-of-4への規則変更も、二つの別の判断空間を作る。

例外は移行を自動化しない

改訂04は、統治規則が明示的に許し、証拠がその移行を立証するなら、スナップショット間の合算を認める。したがって必要なのは「継続できる」という一般論ではなく、どの変更でどの承認が残り、どの条件で失効し、誰が再確認するかを定めた規則である。

例えば、操作と無関係な席の交代なら24時間だけ承認を維持し、新しい集団が追認するという規則は設計できる。反対に、承認者の離脱、しきい値の増加、必須役割の変更で全承認を失効させる規則も可能だ。草案は一つの統治モデルを強制しない。実行直前に集計器が最も許容的な解釈を作ることを防ぐ。

同じ委員会名、記録の順序、同じ議長、後から得た構成員一覧は許可規則の代わりにならない。どの規則が持ち越しを認め、どの状態遷移が起き、旧承認が新判断で数えられる理由を証拠が示さなければならない。

除名後の再加入では、識別子が同じでも資格期間は連続しない。古い票が本人と一緒に自動復活する設計は、権限の空白を無視する。

チェックポイントは新鮮さの代用品ではない

スナップショットを記録しても、それが権威ある情報源から得られ、完全で、評価時に新鮮だったことは別に確認する必要がある。

改訂04の時間区間は valid_from <= evaluation_time < valid_until である。期限切れ、停止、失効、古い状態、競合、利用不能、検証不能などの重要状態は肯定結果を生まない。新しい状態を要求する方針の下では、古いキャッシュ応答も許可の根拠にならない。

RFC 3339は時刻表現を、RFC 9111はHTTPキャッシュを定義するが、どの構成員・規則が判断を支配したかは示さない。履歴解決では、要求対象時刻、評価時刻、当時有効な記録、後の関連イベント、再構成できない部分を分ける必要がある。

イベントの重複処理は権限を拡大してはならず、順序の欠落は検出可能でなければならない。Bの離脱イベントを取り逃した利用者はS1を保持しているのではなく、不完全な状態を保持している。

再現可能な判断証拠

重要操作では、正確な操作ダイジェスト、集団主体、構成員と規則のチェックポイント、評価時刻、各承認と検証時のスナップショット、異なる管理者と役割の計数、親権限、ライフサイクル、競合、新鮮さ、判断理由、実行へ渡した操作を一つの証拠連鎖として保持すべきだ。

例外を使う場合は、持ち越しを許す規則の識別子と移行証拠を追加する。これはDaniel Kadeによる運用上の提案であり、改訂04がそのまま定義するJSONフィールドではない。署名済み判断、版管理されたデータベース、追記型記録、アクセス制御された参照のいずれでも、不変条件を守れる。

Heng Luの現実層という見方では、委員会名、構成員、行使規則、承認、集団判断、実行、外部効果は別の事実である。実行コード優先の原則は、文書よりも実際の結合条件を見る。規程が「現任二名」と書いてあっても、実装が操作だけで署名を数えるなら、別の統治を実行している。

最小初期仕様はすべての組織を同じ制度にしない。異なる状態を無断で混ぜないための識別子と安全な失敗だけを共有する。チェックポイントが欠けるなら、肯定ではなく不確定が正しい。

Sources and limits

資料は2026年9月30日、上海時間で固定した。改訂04は活動中の個人Internet-Draftであり、RFC、IETF合意、採用実績、配備済み製品ではない。Datatrackerは正式な地位がないと明記している。S1/S2のローカル構成は規範上の境界を説明するだけで、攻撃、悪意、署名破壊、実装障害、現実の委員会判断や損失を示さない。文書は変更、置換、失効し得る。