要約

  • IETF DatatrackerにおけるAUDIT BoF申請の現行状態は Declined である。8月31日に開設されたnon-WGリストは、BoFや提案チャーターを練り直す場であって、AUDIT Working Groupではない。
  • IESGはエージェント行動の監査という課題を否定せず、現案が広すぎるとして、OAuth、WIMSE、OpenTelemetryなど既存作業で埋まらない範囲を明確にするよう求めた。
  • 個人提出のアーキテクチャ案は、対話、行動、委任、認可遷移の記録を分ける。一方、記録拒否、全当事者の共謀、モデル整合性を解決せず、詳細な脅威モデルも今後の課題としている。
  • 議論の場、BoF判断、チャーター、文書採用、IETFレビュー、RFC発行、実運用を別々に示す「権限状態レシート」がなければ、活動実績が制度上の委任に見せ替えられる。

開かれた入口と閉じた判断は同時に成立する

IETF Secretariatは8月31日、AUDITリストの開設を告知した。提案者にとっては重要な前進だ。複数の信頼領域をまたぐエージェント監査について、チャーター案や既存技術との境界を継続的に検討できる。

ただし、先行する申請の状態は変わっていない。AUDIT BoF request version 02には「Declined BOF request」「Declined」と表示され、最終更新日は7月6日である。BoF requests一覧でも同様に分類される。Responsible leadership欄は空白だ。本文にSecurity Area Directorsが担当AD候補、Yaroslav Rosomakhoがchair候補として書かれていても、候補は任命済みの役職者ではない。

新しいリストの説明も将来形を崩していない。non-WGリスト一覧によれば、目的は「potential AUDIT BoF」の議論、提案チャーターの更新、そして新WGの形成に向けた作業である。9月1日の時点で公開アーカイブにあるのは開設告知だけだ。つまり、議論する制度上の住所はできたが、そこで検討する対象はまだ承認されていない。

これはIETFの通常の仕組みに沿う。non-WG mailing listのガイドラインは、WG形成を目指すリストも想定し、適切なArea Directorがリスト申請を承認すると定める。その承認が与えるのは通信の場である。BoF開催、チャーター、マイルストーン、chairsの任命まで一括して与えるものではない。

RFC 2418が示すWorking Groupは、限定されたチャーター、責任を負うADとchairs、明示的なプロセスを持つ。WGにはメーリングリストが必要だが、逆は成立しない。名簿があるから組織が成立するのではなく、権限を持つ手続きが組織を成立させ、その設備として名簿を持たせる。

6月の「deferred」と現在の「Declined」

6月3日のIESG回答では“deferred”という語が使われた。その内容は、提案者による6月5日の返信に残る。回答は、エージェント行動を監査する発想そのものを有益と評価した一方、現行の提案を広すぎると判断した。OAuthやWIMSEの関係者と議論し、既存作業やOpenTelemetry profileでは不足する理由を説明すること、対象を狭めることを求めた。また「意図」や「ポリシー」の一部は、IETFの技術枠組みより法的枠組みに適するのではないかと問いかけた。

提案者はdeferの意味と手続き、タイミングを問い、管理領域をまたぐ証拠連結の必要性を主張した。その後もスコープに関するやり取りが続いた。ここにあるのは、価値をめぐる全面否定ではなく、どの問題をIETFで所有するかという異議である。同時に、メール上の反論が承認手続きを代替したわけでもない。

したがって二つの語を一つに丸める必要はない。Deferredは6月の回答で用いられた表現、Declinedは締切時点のDatatracker状態である。両方を日時と出典付きで残せばよい。改訂申請が後に通る可能性も残る。現申請の却下は、課題の永久追放を意味しない。

状態を短縮しない理由は、Heng Luが論じたマルチステークホルダーの蜃気楼と重なる。参加資格や発言機会は、誰かを代表する委任状ではない。「IETFで議論されている」を「IETFが承認した」と書き換えると、venueがprincipalに化けてしまう。

監査対象を四つの記録に分解する

5月18日付の個人提出Audit Architecture draftは、分散ログを増やすだけの提案ではない。人がエージェントに指示し、エージェントが別の主体へ委任し、異なるポリシー下のサービスを呼び出し、途中で追加認可を得て結果を生む。この流れでは各サービスのログが正しくても、最初の意思、渡された権限、実行内容、権限変更を一体として検証できない。

そこで案は四つの記録群を置く。Interaction Recordsはユーザーのプロンプト、応答、確認、承認などの意思証拠を扱う。Action Recordsは実行境界で何が起きたかを記す。Delegation Recordsは誰が誰へ、どの範囲と制約で権限を渡したかを示す。Authorization Transition Recordsは初期付与、step-up、縮小、失効、期限切れを記録する。

共有audit contextが相関識別子や先行イベント参照を運び、複数主体がそれぞれの視点から記録を作る。部分的に信頼されるaudit storeが正規化し、必要に応じてattestationやtransparencyサービスを組み合わせる。この構造は、ユーザーが何かを言った事実と、システムがそれを行う権限と、実際に起きたことを別々に検証させる。

しかし、草案は万能性を主張しない。エージェントを信頼せず、audit storeも部分的にしか信頼しない。サービスが自らの境界で記録を拒否する問題、全役割が共謀する場合、背後のモデルのalignmentは解決対象外である。詳細なsecurity analysisとthreat modelも将来作業だ。署名の完全性は、出来事の網羅性を保証しない。

記録が豊かになるほどプライバシー負担も増す。Interaction Recordsにはプロンプトや個人の目的、Action Recordsには業務や取引相手が含まれ得る。全世界で共有するcorrelation IDは、組織をまたいで個人の行動を追跡する鍵になる。透明台帳にハッシュだけを登録しても、ある時刻に関係が存在したことは漏れる。accountabilityを掲げれば無期限収集が許されるわけではない。

Verifiable Agent Conversation Recordsの個人draftは、ユーザー側の対話証拠候補を示す。しかしAUDIT WG採用文書ではない。そもそもWGが存在しない。また会話への署名だけでは、内容最小化、編集・秘匿、選択的開示、保存期限、後続行動との安全な結合を決められない。

既存技術は証拠を補うが、権限を代行しない

IESGが求めた隣接作業の分析は、範囲を狭める実質的な設計作業である。

RFC 8693 OAuth Token Exchangeは、トークン交換における委任やactor chainを表現できる。主体間で運ばれた権限を示す一部の証拠にはなる。しかし、最初の人間の指示、その後の認可変更、実行結果、監査者の判断を一つに説明しない。基本プロトコルは詳細なtoken semantics、security properties、trust modelを範囲外に置く。

W3C Trace Contextは分散リクエストの識別子を伝播し、複数サービスの処理を関連付ける。だがtrace IDはpermission statementではない。委任が縮小されたか、ユーザーが危険な操作を認めたか、その行為が正当だったかを語らない。時系列のつながりは権限のつながりではない。

RFC 9334 RATS architectureでは、VerifierがEvidenceを評価し、Relying PartyがAttestation Resultにポリシーを適用する。機器や実行環境の状態評価には役立つが、法律上の権限や人の意図への意味的忠実性は保証しない。正規のソフトウェアも、無権限の命令を正確に実行できる。

RFC 9943 SCITT architectureは署名付きstatement、追記型transparency service、registrationやinclusionのreceiptを扱う。後からの削除や書き換えを見つけやすくする一方、登録された主張を真にせず、全関連イベントの提出を証明せず、receiptをpermissionに変えない。

従って将来のスコープは、OAuth、WIMSE、Trace Context、RATS、SCITTなどが所有する機能と、なお所有者のいない跨領域接合部を表にすべきだ。隣接技術を列挙するだけではarchitectureにならない。重複を避け、残余問題に責任を持つことが必要である。

標準化プロセスにも権限の履歴が要る

AUDITはエージェント実行の権限履歴を設計しようとしている。同じ論理で、標準化の過程にも公開のauthority-state receiptを持たせられる。誰が会議に出たかではなく、どの主体が何の状態を変更する権限を持っていたかを残す。

最初の項目は問題の安定した識別子と提案の正確なversionである。現在状態はproposal、declined/deferred BoF、non-WG discussion、approved BoF、chartering、active WG、concludedなどから選ぶ。状態を作った権限主体、決定日、原文URL、誇張しないdispositionを添える。

次の版ではscope deltaを必須にする。何を削り、何を既存WGに任せ、何が残ったのか。ADやchairは任命されるまでproposedとする。Venueとauthorityは別欄に置く。承認済みcharterがなければnull。文書はindividualかWG-adoptedかを明記し、採用記録を付ける。

WG Last Call、IETF Last Call、IESG evaluation、未解決の異議もそれぞれ異なる。PublicationはInternet-Draft、RFC stream、categoryを記し、単一の“standard”という語で済ませない。実装と運用ポリシーはdeploymentとして切り離す。発行されたRFCが直ちに運用を示すわけではなく、導入例が標準化状態を先取りするわけでもない。

このreceiptは過去を上書きしない。新しいBoFが承認されたら、却下された旧申請へリンクし、どの変更が判断を変えたかを記す。WG採用後も初期の個人版は個人版のまま残す。古い判断が不変であってこそ、後の委任がどのように獲得されたかを監査できる。

現在のAUDITを記せばこうなる。個人draftがある。version 02のBoF申請に対し、IESGは問題を評価しながら広すぎると応答した。DatatrackerはDeclined。non-WGリストは将来のBoFと提案charterを検討する場所として成立した。責任者任命、承認charter、WG、文書採用、IETF consensusはいずれもまだない。

欠落を見える状態にする

監査設計が先に決めるべきなのは、何を集めないかである。記録種類ごとに最小化し、領域外へ本文を運ぶ必要がないときはdetached payload、ハッシュ、selective disclosureを使う。全体相関が不要ならpairwiseまたはopaque identifierを選ぶ。技術的にリンクできることは、リンクする権限を意味しない。

Auditorの閲覧には独立した許可が必要だ。障害解析、契約証拠、セキュリティ調査、規制記録では目的も保存期間も違う。記録拒否、取得不能、空白を明示し、もっともらしい連続履歴を捏造しない。receiptは結び付けたrecordだけを証明し、関連する全出来事を網羅したとは主張しない。

新しいリストが担うべき仕事はここにある。大きな理念を、プロトコル要件、実装profile、組織ポリシー、法的判断に分ける。プライバシーとthreat modelを将来課題ではなくcharterの成果物候補にする。その結論が十分狭くなったとき、次の正式判断が意味を持つ。