要約

  • 10月26日付の個人草案は、決定記録と行動連結の添付記録を、別々の型付きハッシュ参照で配布声明やエージェントの行動記録につなぐ。
  • 添付記録は承認した仕様と実行を比べる。承認者の署名があっても、その人に承認権があったかは独立した権限記録で調べる。

配布の監査で、まず見つかるのは製品のハッシュだ。何を作ったかはビルド記録が語る。SCITTの透明性サービスに署名付き声明を登録すれば、受領証で登録を確認できる。だが利用者に渡すという判断は、製品のハッシュからは出てこない。誰の判断で、どの権限に基づき、どの版を許したのかが別に必要になる。

Laurent Lemonnierの提案は、その別紙を二つ用意する。文書の地位は個人によるInternet-Draftだ。一つは決定記録で、選んだ案と理由を記す。もう一つは、提案した仕様から審査、承認、実行要求、直前の権限再確認、試行、結果へと進む行動連結の添付記録だ。配布声明は二つを異なる型とハッシュで参照する。参照先のバイト列を確かめる作業と、中身の主張を審査する作業を混ぜない構造になっている。

草案には架空のサービスのバージョン2.3.1を出す例がある。承認される仕様には成果物と部品表のハッシュ、移行処理、切り戻しが書かれる。承認後、配布ジョブが別の成果物を持って来れば、どの段階でハッシュが食い違ったか分かる。成功を示す実行ログがあっても、承認されたのがその成果物だったかは、この照合が決める。

署名も万能の札ではない。承認段階に署名が付いていれば、検証者は自分の信頼方針で鍵を特定の人に結びつけられる。その人が組織の規程で承認権を持つという記述は発行者側の申告だ。権限管理システムなど別の根拠を当たる必要がある。審査者に何を見せたかも、添付記録がそう主張する範囲でしか分からない。

証人のチェックポイントを台帳に登録した受領証は、ある木の大きさで記録されたことを示す。草案の現行版は、その受領証から登録時刻や記録の連続性まで読み取らない。結論は一枚の「承認済み」札より面倒だ。署名、権限、同じ成果物、実行結果を別々に示す。その面倒さこそ、あとで責任を追える形である。