要約

  • Steven Mihによる「Disclosure Envelope」の初版は9月27日に告知された個人Internet-Draftであり、IETFが採択した規格や実運用の報告ではない。
  • 提案では、署名済みのAgent Action Capsuleを変更せず、希望する入出力の原文を別の包みに添える。検証者は元の記録と開示された値を、それぞれ独立して確かめる必要がある。
  • 原文から再計算した要約値が記録と一致しても、原文の正しさ、行動の適切さ、受取人への開示権限までは立証されない。

同じエージェントの行動を二人が調べる。一方に渡るのは入力を表す要約値だけで、もう一方には入力の全文も渡される。これは実在する監査の報告ではなく、今回の提案が生む閲覧範囲の差を示す仮定だ。二人が参照する署名記録の識別子は同じでも、確認できる材料は同じではない。

9月27日に公表された draft-mih-agent-disclosure-envelope-00 は、Steven Mihが提案するAgent Action Capsuleの追加仕様である。Datatrackerはこれを有効な個人草案と表示し、IETFの支持を受けた文書でも正式な標準化上の地位を持つ文書でもないと明記する。元のカプセル案では、agent_input_digest と agent_output_digest に、RFC 8785に従って正規化したJSON値のSHA-256要約値を入れる。入力文や出力文そのものは、その要約値専用の欄に最初から収めない。

新しい草案は、元のカプセルを変えずに包み、その隣の disclosures に任意の値を置く。初版で対象となるのは agent_input と agent_output の二つだけだ。片方を入れない場合は「WITHHELD」、つまり開示されていない状態になる。それは入力が存在しなかったという意味ではない。この包み自体はSCITTの透明性サービスへ登録する署名済み声明ではない。後から加えた原文は元の署名に含まれず、カプセルの capsule_id 計算にも入らないため、異なる相手へ異なる原文を見せても基礎記録は変わらない。

だからこそ、表示する側の検証を省けない。草案はカプセルの検証と開示内容の検証を二段階に分ける。後者では、提示されたJSON値を全体として正規化し、要約値を計算し直し、以前のコミットメントと突き合わせる。対象外の項目、対応する要約値の欠落や不正な形式、値の不一致はそれぞれ区別する。開示が一致しても、元のカプセルに問題があればその問題は消えない。逆にカプセルが有効でも、追加された原文を未照合のまま「確認済み」と表示してはならない。署名されていない外側の情報に、内側の署名の信用を勝手に貸すことになるからだ。

別に提案されている選択的開示との違いも重要だ。そちらは本来ペイロードに平文で入る欄を署名時に隠す方式を扱う。今回の対象欄は最初から要約値だけで、後から出す原文は隠れた欄の復元ではない。一致が示すのは、その原文が先に示された要約値に対応するという限定的な事実である。エージェントが正しい判断をしたか、入力が現実を正確に記述していたかは、別の証拠を要する。

さらに、包みを受け取った人には原文が平文で見える。草案には受取人別の暗号化や、その後の再配布を止める仕組みはない。作成者は相手ごとに開示項目を選べるが、誰に渡す権限があるのか、受け取った後にどう保管するのかは別途決めなければならない。Daniel Kadeの読みでは、記録の改ざん防止と情報公開の統制は同じ仕事ではない。草案の公表だけで、実際の漏えい、普及、義務化を推測することもできない。

出典