要約

  • draft-zhang-dawn-agent-discovery-framework-01 は2026年9月6日付で、Datatrackerでは7日更新となっている。現状は個人提出のInternet-Draftであり、IETF標準化過程における正式な地位はない。
  • 構成案はサイト内の発見と組織間の連合を分ける。ゲートウェイが情報を選別・削除し、Federation Metadata Recordに署名して認証済みの相手へ送る。
  • 第01版はMDIとFMRの対応表を加えた。出所、能力、鮮度、来歴は運べる一方、許可された受け手、再配布の可否、適用した輸出ポリシーの版は含まれない。
  • Daniel Kadeは、レコードのハッシュに結び付く小さな配布エンベロープを提案する。これは配布条件を保つためのもので、エージェントの身元証明、信頼度評価、実行許可ではない。

文書の権威から確認する

Datatrackerは、Bin Zhangによる現行の個人草案として記録している。RFC streamも担当Area Directorもtelechatもなく、予定されるRFC statusも登録されていない。本文はInformationalを掲げる。新しい版が出たことは検討材料が増えたという意味であり、IETFがこの構成を採ったという意味ではない。

組織名の扱いにも注意が要る。草案はDAWNをworking groupと呼ぶが、DAWNの公式ページは現在もBoFとし、まだcharterはないと明記する。IETF 126の議事録も、working group設立を検討する会合であり、示されたcharterは合意済みではなく出発点だったと記録している。草案中の呼称だけで制度上の段階は進まない。

その前提で読むと、第01版の二層構成は明快だ。Local Discovery Planeは、mDNSやローカルのディレクトリーなどを使ってサイト内のエージェント公告を集める。行政境界にはFederation Gatewayを置く。Export Policy Engineが外に出せるエージェントを選び、機微な項目を落とし、外部連合用の軽量なFMRを作る。

詳しいCapability Cardは連合全体へ複製しない。発信元に残し、必要なときに認証済みunicastで取得する。情報量を抑えるだけでなく、詳細情報へのアクセス制御を発信元に残せる。相手によって異なるFMR集合を送ることも想定されている。この最初の出し分けが、草案のいうデータ主権の中心である。

対応表が示すもの、示さないもの

第00版との公式差分では、DAWNのMinimum Discoverable InformationをFMRの項目に落とす表が追加された。共有対象が具体化したため、統治上の主張も項目単位で検証できる。

FMRにはエンティティー識別子と種別、到達可能な場合のendpoint、能力の概要、Capability Cardへの参照が入る。認証の手掛かり、trust reference、公開時刻、TTL、provenance、Origin-GW-ID、Record-Flagもある。MDIのScope Hintは、おおまかなGeographic-Hintとして対応付けられる。

受信側は、どのゲートウェイが作ったか、まだ新しいか、詳しい情報をどこへ取りに行くかを判断できる。署名と来歴を保ちながら、重いCapability Cardをばらまかずに済む。

一方、最初の輸出後に誰が受け取ってよいかは表現されない。許可対象、機密区分、再配布フラグ、最大ホップ数、ポリシーIDやその世代がない。地理情報は所在のヒントであって認可境界ではない。TTLは期限であって、期限内ならどこへ複製してよいかを決める条件ではない。来歴も発信元を示すだけで、配布契約は示さない。

AがBにだけFMRを送り、Cには送らない最初の場面では問題が見えにくい。Aの設定に判断が残るからだ。しかしBが受け取ったFMRを自らのFederated Agent Directoryへ入れ、別の同期関係に参加した時点で、下流はAの意図をレコードから復元できない。

署名は配布許可証ではない

セキュリティーモデルでは、発信元ゲートウェイが送信FMRへ署名し、受信側は検証に失敗したレコードを破棄する。参加者が他のゲートウェイを装って情報を作ることを防ぎ、途中改変も見つけられる。もっとも、加入済みの悪意あるゲートウェイは自分のローカルエージェントについて虚偽を作れる。連合への加入審査はプロトコル外の行政判断とされている。

BがAの署名済みレコードを改変せずDへ送れば、DもAの署名を正しく検証できる。だが、その成功はAがDへの開示を認めたことを示さない。「本物である」と「この経路で配ってよい」は別の命題である。

閉じたstructured peeringなら、相手ごとのimport/export policyで不足を補いやすい。参加者とsessionが既知なら、設定と経路を追い、route reflectionの範囲も制限できる。

Gossipは規模と耐障害性を優先する。各ゲートウェイは少数の隣接先とディレクトリーのdigestを交換し、不足または更新されたFMRを送り合う。草案自身が、この方式ではレコード単位の厳密な配布ポリシーを施行しにくいと述べる。混合連合では、共通FMRをstructured peeringとgossipの間で橋渡しする。共通形式は相互運用を助けるが、最初のtransport設定だけに存在する制限は橋を自動では越えない。

問題はgossipそのものではない。発信元を確かめる仕組みに比べ、発信元の公開範囲を下流で確かめる仕組みが弱いことにある。

配布条件を別の薄い層にする

FMRを大きくする必要はない。正確なFMR digestへ暗号的に結び付くdistribution-envelopeを用意し、Origin-GW-ID、export policy ID、policy epochを持たせる。受け手のclassまたは名前付きのfederation segmentを示し、再配布不可、指定した次の一ホップだけ、境界付きsegment内で可、のいずれかを宣言する。

期限とwithdrawalまたはrevocationへの参照も必要だ。内部ルールを公開しない不透明なexport-decision receipt IDがあれば、発信元はPolicy Engineの出力を照合できる。プロトコルをまたぐbridgeはprevious-hop receiptを加え、どの部品が境界維持の責任を引き受けたか残せる。

これは不正な相手によるプロトコル外コピーを物理的に止める装置ではない。それでも、準拠実装は不正な再輸出を拒否でき、運用ログは適用ルールを示せる。監査では、許可された経路と、署名だけは正しい経路を区別できる。

用途を膨らませてはならない。安定識別子の発行、包括的なtrust評価、能力交渉、open Internet indexing、商業ルールは草案自身が範囲外としている。配布エンベロープは、エージェントが安全か、優秀か、呼び出してよいかを証明しない。このメタデータを、どのポリシーの下で誰まで渡せるかだけを残す。

出典