IETF 126 Web Bot Auth WG セッションまとめ（識別ベース / 匿名認証 / Crawler Best Practices）

IETF 126（2026年7月22日、ウィーン）の Web Bot Auth WG セッションについて、スライド・アジェンダ・投票結果・録画の文字起こしをもとにまとめたもの。

セッション概要

• 日時: 2026-07-22 09:00（120分）／担当AD: Mike Bishop、Chairs: Rifaat Shekh-Yusef, David Schinazi
• 前提: 2026年4月のinterimとMLでの合意により、WGは 「識別ベース認証」と「匿名認証」の2つを並行して進める ことが決定済み
• チャーター上のbotの定義: データセンター等、誰かのインフラ上で動くエージェント（検索クローラ、AI学習用クローラ等）。ローカル端末上で動くエージェントは対象外
• EKRの提案が依存する MoLE については前日にside meetingが開催され、次回IETFでのBoF化が視野に入っている旨がChairsから共有された

1. HTTP Message Signatures for automated traffic（Thibault Meunier / Sandor Major）

draft-meunier-webbotauth-httpsig-protocol-00

提案内容

• 従来の識別手段（IPアドレス、User-Agent、逆引きDNS、フィンガープリント、事前共有鍵）はサーバ・bot双方にとって不十分という問題設定
• 目的は「リクエストをまたいだbot信頼の継続性」と「ドメイン等の別アンカーへのオプショナルなバインディング」。制約として botとサイト双方の運用の単純さの維持 と 事前関係の不要性
• 仕組みは RFC 9421（HTTP Message Signatures）による署名付きリクエスト。Signature-Agent（sf-dictionary）／Signature-Input／Signature の3ヘッダを使い、MUSTパラメータは @authority または @target-uri、created、expires、keyid（JWKサムプリント）、tag="web-bot-auth"
• 構造を リクエスト認証／鍵のディスカバリ／バインディング の3層に分離。「ディスカバリは信頼を与えない」ことを明示
• 2つのモード:

• 実装状況として、TypeScript / Rust / Go / Swift / Python / C / PHP / Ruby など複数のOSS実装、Caddy・Apache・WordPress向けプラグインの存在を報告。HTTP層での署名によりTLSスタック変更が不要でCDN・プロキシ越しでも機能した点をデプロイ上の利点として挙げた。一方 Signature-Agent の sf-string → sf-dictionary 変更（-04以降）は非互換変更で、いまだ両方が実運用に現れていると注意喚起

主な議論

• EKR: 2つのモードは技術的にはほぼ同一で、どちらも「URIをTLSで取りに行く」だけ。違いは最終的に「ドメインが裏書きしたと主張できるか」だけであり、プロトコル的含意はなく評判(reputation)の問題。opaqueモードでも URIを識別子として扱えばローテーションは普通に機能する と指摘。なおdata URIモードは最新PRで削除済みとのこと
• Justin Richer: EKRに同意。本質は「取得可能な鍵ディスカバリ機構を署名に結びつける」ことで、これはHTTP Message Signatures側で意図的に外した部分であり、レイヤとして有用。ただし RFC 9421の使い方にかなり悪い穴がある（特に「署名値そのものに署名してはいけない」）と指摘し、採択されればレビューを提供すると申し出。また鍵をby-valueで提示するユースケースが自分にはあり、by-referenceとは信頼セマンティクスが大きく異なるため明確に別文書にすべきと主張
• Dick Hardt: 方向性には賛成しつつ、これはWeb Bot Auth固有ではなく HTTPにおけるクライアント識別の一般問題 であり、HTTPbisでの汎用機構との整合が望ましいとコメント。Chairsは「チャーター内で本WGは進め、HTTPbis側は並行して進め、将来汎用解が十分なら乗り換えればよい。それを待って足止めはしない」と応答
• Mirja Kühlewind: opaqueモードは妥当だが、バインディングは選択肢が複数ありうるので別文書に切り出してはどうか
• Richard Barnes: URL周りの調整で統合的なスキームにはなりうるが、永続的識別子に依存し続ける点が残念。ユースケースが匿名機構で満たせるならそちらを選好
• content-digest / content-length に署名しない理由を問われ、性能上の理由と実運用での普及度の低さを挙げた

ハムアップ投票

「これは一般的な方向性／出発点として妥当か」: Yes 22 / No 6 / 意見なし 5（投票終了時の参加者75名）

Noに投じた理由として挙がったもの:

• Richard Barnes: 識別子バインディングなしで要件を満たせるならそうすべき
• Eric（Google）: 「voluntaryだと言うが、コンテンツアクセスに実質必須化すればWebのossification・アクセス阻害になりうる」。実験を続けつつ判断は保留したい（noではなくmaybeの意）
• Martin Thomson と思われる発言者: 採択議論の前にドラフトの目的と意図をもっと明確にすべき

Chairsが「4月の合意は今日は再訪しない」と述べた場面で、EKRが「合意があっても採択には別途コンセンサスが必要で、その理由での反対は正当」と反論。Alyssa Cooperからは「理由を聞いておいて合意済みと返すのは仕込みに見える」という指摘も出た。また Marwan から「この道を探索しないこと自体が閉鎖的なシステムに向かう。サイト運営者は認識できないものをブロックできるのだから、これはむしろアクセス維持の手段になりうる」という反論も出ている。

結論: 本日は採択コールを行わず作業継続。十分な査読時間を取ったうえでML上で採択コールを実施する。

2. Anonymous Bot Authentication（Eric Rescorla / Richard Barnes）

draft-rescorla-anonymous-webbotauth-01

提案内容

• draft-nottinghamのユースケースの多くは bot個体の識別を必要としない という立場
• Anchor が第三者としてbotを審査しポリシー適合を確認、適合botに Endorsement を発行。サイト側の Moderator がEndorsementと引き換えに Credential を発行し、Credentialには budget が付随。リクエストごとに残budgetの証明が必要で、Moderatorは挙動に応じてbudgetを増減できる
• Endorsementは時間窓ごとに1つ、各Moderatorに対して時間窓ごとに1回だけ提示してCredentialを得る
• 中身はほぼ MoLE（draft-jms-mole-architecture-00）をそのまま利用。EKR自身「MoLEを丸ごと借用している」「Thibault案より熟していないのはMoLE側が未成熟だから」と説明
• できること: 大量アクセス抑制、bot/非botでの出し分け、IPモビリティ・IP共有、Moderator単位での評判蓄積と監査
• 設計上できないこと: bot個体の認証、同一Anchor配下のクライアント間での差別化
• Next steps: 採択にはまだ早い。まずMoLEのcharter化が必要で、その間にMoLEへの要求事項の洗い出しとWeb Bot Auth固有の課題・バインディングの文書化を進める

主な議論

技術面

• Richard Barnes: opaque URL＋使い捨て鍵で同等の効果は得られないか → EKR「得られない。サイトが挙動カタログを蓄積するのを防ぐこと、識別子と実世界IDの対応が漏れて差別・ブロックにつながるのを防ぐことが目的」
• Pablo: MoLEはCredential取得に往復と検証コストがかかるが、botは高速に大量リクエストを出す。並行性(concurrency)の扱いが不明 → EKR「実運用ではCredentialをさらにcookie的な第3層に交換して1万リクエスト程度償却する形になるだろう」。あわせてbot文脈でAnchorを運用するインセンティブが誰にあるのかも疑問視
• DKG (Daniel Kahn Gillmor): MoLEの売りは「1ビットしか渡さない」ことだったが、人間用Anchor集合とbot用Anchor集合を分けると2ビット、クラスを増やせばnビットになる。サイトがAnchor部分集合を反復照会して絞り込むのを防ぐ 防御機構が必要
• Martin Thomson: 単一Anchorしか示していないのはプレゼン上の都合か（→ EKR: その通り、MoLEの複数Anchor証明は利用可能）／MoLEのmoderator delegationを使っていないのも同様／単一エンティティ専用のAnchorを立てればThibault案に縮退するが技術的には防げない／属性を積み上げると結局識別子になる点も指摘
• Rashid Bouzine (Secroots): EndorsementがあるのになぜCredentialが要るのか → EKR「暗号設計上の都合。効率的な挙動を得るには多段が必要」

集中(centralization)と political economy

• EKR自身が「論点の多くは技術ではなく political economy」と総括。自身の懸念は「大手botがすべて識別されると小規模botの匿名認証への需要が消え、自分のbotがOpenAIの影に隠れられなくなる」こと
• Jonathan Hoyland: サイトがGoogle・OpenAIのAnchorだけを信頼すれば、結局小規模botは隠れられないのでは → EKR「そのリスクはある。ただし大手botはIPアドレスがほぼ特定できているので、そもそもこの仕組みの主眼ではない」
• Ted Hardie: Anchorへの権力集中に強い懸念。Anchor hidingは暗号的には可能でも、実際にはAnchorの評判をbot個体の評判の代理として使いたいという動機があるため political economy に合わない。一方で Anchorで「即席に作られた識別子ではない」ことを示せる価値（評判システムのwhitewashing対策、ベースライン評判の底上げ）を評価し、識別方式だけに絞ると「既に評判を持つ者だけが得をする罠」に陥ると警告
• Sam（MoLE共著者）: 集中の懸念はAnchorよりむしろ Moderator に向くべき。レート制限の大半はAnchorではなくModeratorとのやり取りで蓄積される評判から来るべきで、Anchorはエコシステムへの入場券にすぎない。Anchorが有意義な裏書き判断をするには プライバシー保護型の分散フィードバック機構 が必要
• Alyssa Cooper: 1つのAnchorが多様な種類のbotを裏書きする姿が想像しにくい。サイトが歓迎するbotと歓迎しないbotで分断が起き、後者を救う仕組みとして機能しないのではないか。小規模botはGooglebotを裏書きするAnchorに相乗りしようとするのでは
• Marwan: 図書館協会や国連配下のNGO群のようなAnchorを想定すれば、評判構築だけでなく アカウンタビリティと可視性 をもたらしうる
• Eric Carton (Google): 対象はクローラかエージェントか、ローカルかリモートか。誰か分からない状態で適切なレート制限をどう決めるのか、provider単位とclient単位の評判を分けるべきでは（→ Chairs: ローカル/オンデバイスエージェントはWBAのチャーター外、MoLE側の話題になりうる）

より根本的な問い

• Dick Hardt: サイトが欲しいのは「同じbotだと分かる永続識別子」で、それにより自サイト固有の文脈での評判を蓄積したい。第三者Endorsementは全く新しい能力なので、どんなEndorsementならサイトが実際に使うのか を具体化しないと設計しても使われない（例: 識別子の登録からの経過年数）
• Justin Richer: 「我々は本当に気にしていること（認可・評判）の代理として identity / pseudonymity を使っているのではないか」という WGの存在論的問い を提起。グループプライバシーや再識別の問題も指摘
• Alyssa Cooper: 「この仕組みが意図通り機能するために何が真である必要があるのか」（各役割を誰が担うのか、その母数は十分か）を理解しないと、単なる面白い機構で終わる

Chairsのまとめ

アプローチ自体は好意的に受け止められた。ただし ①ユースケースをもっと明確にすること ②権力集中への対処、の2点が課題。加えてMoLEへの依存があるため時期尚早であり、11月のIETFまでにより明確な形にすることを目指す。提案者側も現時点で採択は求めていない。

3. Crawler Best Practices（Gary Illyes / Mirja Kühlewind）

draft-illyes-webbotauth-cbcp-00（アジェンダ上のリンクは aipref 版）

提案内容

• クローラの運用挙動が実装ごとに大きく乖離しており、負荷シグナル無視によるインフラコスト、不十分・誤解を招く識別情報、急激なクロールレート変動によるWAF/IPブロックといった運用上の問題が生じている
• 暗号的な身元証明を扱う他ドラフトとは軸が異なり、運用衛生とクライアント挙動を扱うInformational文書として位置づけ
• 成文化する内容: RFC 9309（robots.txt）遵守と到達不能時のフォールバック、User-Agentへの連絡先URI、429/503とRetry-Afterへの即応、指数バックオフ＋ジッタ、IPレンジの公開（JAFAR: draft-illyes-webbotauth-jafar）
• 「暗号署名はidentityを、行動規範はtrustを確立する」という整理

主な議論

• Justin Richer: 「本日提示された中で最も現実的で即座に有用なドラフト」。既存慣行を記述し落とし穴を示すWIMSEの類似文書を引き合いに、本WGで扱うべきと主張。スコープが狭く発明を伴わないので早く進められる
• EKR: 一部は有用だが、botを叩く棍棒として使われる懸念を表明。自己識別の是非は係争的（ニューヨーク州の関連法案に言及）で、全員が合意できる部分に絞るべき → Gary「新しいbotの挙動が大きく異なるのは悪意ではなく単に作法を知らないから」
• Mark Nottingham: IETFで扱うならここが最も論理的な場。争点のある推奨は無理に書かず合意できる部分に集中すべきで、charter変更の議論をしてはどうか
• Thibault Meunier: 現行慣行の良いまとめであることには同意。ただし「これは best practice なのか」は別問題で、今後の設計に情報を与える意味でこのWGで議論する価値がある
• Mike Bishop (AD): 現行チャーターの成果物「運用上の考慮事項を記述するBCP/Informational文書」に照らせば、議論する程度には十分近い。公開が近づいた段階でcharterを微修正すればよい
• Mirja Kühlewind: 採択するならきちんとrecharterすべき。IETF Last Callでin-charterか否かを争いたくない

全体の結論

Chairsのまとめとしては、スコープの異なる2つの提案がいずれも継続作業となり、本日はどちらも採択コールに至らず。

• 識別ベース: 方向性としては支持を得た（22/6/5）ものの、ドラフトの目的の明確化とRFC 9421利用面の修正が前提。ML上で採択コールを予定
• 匿名ベース: MoLEのcharter化待ち。ユースケースの明確化と集中リスクの整理が宿題
• CBCP: チャーター外ながらML上で議論継続。採択するならrechartering

次回IETF（サンフランシスコ）までにinterimを開催する可能性が示唆された。

注: 録画の文字起こしは自動生成のため人名・用語の綴りが崩れている（Ecker→EKR、TBO/Timo→Thibault、Molly/Moley→MoLE、WebAuthn→WebBotAuth など）。上記では文脈から補正している。