セキュリティ

​

概要

• 金銭取引: 実際の広告費が動く
• 複数主体の信頼: 認証済みエージェント、パブリッシャー、オーケストレーター間の連携が必要
• 機微なデータ: 1P シグナル、未公開クリエイティブ、競合ターゲティング戦略を含む
• 非同期オペレーション: 複数のシステムとプロトコルにまたがる

​

リスク分類

​

高リスクオペレーション（金融）

• 短命な認証情報 — 漏洩したトークンの影響範囲に見合ったサイズにする。支出をコミットできるトークンには 1 時間以内が妥当なデフォルト。相当な閾値を超える支出をコミットできる、または組織境界をまたぐトークンには 15 分以内が適切。最小の数字をデフォルトにするのではなく、選択したウィンドウを文書化して正当化する。
• トランザクション整合性のためのリクエスト署名
• 大規模予算向けの多要素認証または承認ワークフロー
• 改ざん不可能なログによる完全な監査証跡

​

中リスクオペレーション（データアクセス）

​

低リスクオペレーション（ディスカバリー）

​

Webhook セキュリティ

​

レガシー HMAC-SHA256 フォールバック（非推奨、4.0 で削除）

• アルゴリズム: HMAC-SHA256 のみ
• 署名メッセージ: {unix_timestamp}.{raw_http_body_bytes} — JSON を決して再シリアライズしない
• バイト等価性の不変条件: HMAC は、パースされた JSON 値ではなく生のバイト上で計算されます。署名者と検証者はワイヤー上のバイトを直接比較しなければなりません（MUST）。ペイロードを再パース・再シリアライズすると — ライブラリが一致しコンパクトセパレーターを使っていても — 署名されたバイトを再現する保証はありません。キー順序、ユニコードエスケープポリシー、数値表現がシリアライザー間で発散するためです（具体例は下記「正準化されない側面」を参照）。このスキームは正準的な JSON 形式を定義しません。下記の「正準的なワイヤー形式」と「検証者の入力」ルールは、署名者側と検証者側でそれぞれ最も一般的なバイトドリフトの失敗を狭めますが、バイトレベルの発散を排除しません。
• 正準的なワイヤー形式: {raw_http_body_bytes} は、署名者が HTTP ボディとしてワイヤーに載せるバイトとバイト単位で同一でなければなりません（MUST）。署名者が JSON 値をシリアライズしてボディを構築する場合、JSON のコンパクトセパレーター ","（項目セパレーター）と ":"（キーセパレーター）を使わなければなりません（MUST）— トークン間に空白なし。言語レベルのシリアライザー JavaScript JSON.stringify、Go encoding/json json.Marshal、Ruby JSON.generate、Java Jackson writeValueAsString はデフォルトでコンパクト出力を生成します。それらをラップする HTTP クライアント（axios、json.Marshal されたボディを持つ Go net/http、JSON.generate を持つ Ruby Net::HTTP、Jackson を持つ Java OkHttp）はそのデフォルトを継承します。Python では httpx はコンパクトセパレーターでシリアライズしますが、stdlib json.dumps はデフォルトで ", " / ": " になり、separators kwarg なしでペイロードを json.dumps に渡す HTTP クライアント（requests(json=...)、aiohttp）は空白入りのボディを発行します — それらのパスの署名者は separators=(",", ":") を明示的に渡さなければなりません（MUST）。この列挙は網羅的ではありません。署名者はこのリストに頼るのではなく、HTTP クライアントの実際のワイヤー上のシリアライズを検証しなければなりません（MUST、例: プロキシやフックでリクエストボディをキャプチャ）。署名は、署名者がシリアライズしたオブジェクトではなく、レシーバーが見るバイトをカバーします。
• 正準化されない側面: キー順序、ユニコードエスケープポリシー、数値表現はこのスキームで正準化されません。特に数値については言語デフォルトが発散し（JSON.stringify(1.0) → 1、Python json.dumps(1.0) → 1.0、Go json.Marshal(1.0) → 1。0.1 のような浮動小数点や科学記法も同様の崖に当たる）、あるライブラリでシリアライズして送信前に別のライブラリで再パース・再シリアライズする署名者は、コンパクトセパレーターでも署名者-検証者ドリフトを生じさせ得ます — 上記のバイト等価性の不変条件が、このスキームを成立させる唯一のものです。
• 重複オブジェクトキー: 署名者は重複オブジェクトキーを発行してはならず（MUST NOT）、シリアライズ前に上流呼び出し元からの重複キー入力を拒否しなければなりません（MUST）。署名者側の MUST は要となります。この失敗モードを捕捉できる唯一の場所だからです: 重複キーペイロードを黙って畳み込む署名者は、呼び出し元の意図と異なるセマンティクスを持つ暗号学的にクリーンな署名済みフレームを発行し、検証者はワイヤーから上流の発散を検出できません — 署名されたバイトは正常に見えます。署名者側のコンフォーマンスはワイヤー上で検証不能で、ランタイム検出ではなく帯域外の監査 / 相互運用テストで強制されることが期待されます（この形状は署名仕様では日常的で、COSE と JOSE は同じパターンを使います）。検証者は、HMAC 検証が成功した後、重複オブジェクトキーを含むボディを拒否しなければならず（MUST）、構造化された不正ボディエラー（署名不一致エラーとは別 — 署名は有効。ボディが不正）を返します。RFC 8259 §4 に従い、JSON オブジェクト内の名前は「一意であるべき（SHOULD）」であり、非一意の名前を持つオブジェクトを受け取るソフトウェアの動作は予測不能です — したがって同じ HMAC 有効バイトをパースする 2 つの検証者は、パースされた値について一致しないことがあります。これはパーサー差分攻撃クラスです（cf. CVE-2017-12635。ある CouchDB パーサーが同じ署名済みボディから roles=[] を読み、別のパーサーが roles=["_admin"] を読んだ）。レガシー HMAC Webhook スキームで運ばれるすべてのボディは状態変更通知（クリエイティブステータス、メディアバイステータス、ガバナンス遷移）なので、MUST はこのスキームに無条件で適用されます。検出は重複キーを露出するパーサーを使わなければなりません（MUST）— それらを黙って破棄する last-wins/first-wins のデフォルトはこの要件を満たしません。署名者入力検証と検証者ボディチェックの両方についての言語ごとの strict-parse エスケープハッチ: 正準の非網羅的列挙（デフォルトで strict に見えるだけでデータキー重複を黙って畳み込むライブラリを含む）は Webhook 検証者チェックリストのステップ 14を参照してください。検証者側のコンフォーマンスフィクスチャは static/test-vectors/webhook-hmac-sha256.json の duplicate-keys-conflicting-values（expected_verifier_action: "reject-malformed"）です。署名者側のコンフォーマンスフィクスチャは同じファイルの signer_side.rejection_vectors にあります: signer-upstream-duplicate-key-rejection（トップレベル）、signer-upstream-duplicate-key-deep-nested（署名者のチェックがトップレベルキーだけでなくネストされたオブジェクトに再帰することを検証）、signer-upstream-duplicate-key-array-contained（署名者のチェックが配列内のオブジェクトに降りることを検証 — オブジェクトには再帰するが配列メンバーには再帰しない手書きバリデーターの盲点）、signer-upstream-duplicate-key-three-deep（ウォーカーが浅い固定深度で止まらないことを検証）。正例フィクスチャ signer-upstream-clean-input が signer_side.positive_vectors にあり、すべてを拒否する署名者が負例フィクスチャを些細にパスしないようにします — 相互運用ハーネスは、重複キー入力の拒否とクリーン入力の受け入れの両方をアサートしなければなりません（MUST）。上流入力の拒否をログやエラーレスポンスで表面化する署名者は、Webhook 検証者チェックリストのステップ 14bで定義された同じキー名サニタイズルール（最初の非印字文字で <sanitized:N> に切り詰め、32 バイト以下の最後の UTF-8 コードポイントに切り詰め、数を 4 で上限）を適用しなければなりません（MUST）— 署名者側のチャネルは検証者側のチャネルと同じ攻撃者制御バイト形状を持ち、信頼の方向が逆になっているだけです。エラー識別子は規範的、エラーオブジェクトの内部は非規範的。 署名者がエラーで拒否を表面化する場合、エラー識別子（判別ユニオンのエラーコード文字列、型付き throw イディオムの例外クラス名、直和型のタグ）は正確に duplicate_key_input でなければなりません（MUST、大文字小文字を区別、接頭辞・接尾辞なし）— マルチ SDK 統合が if (error.code === 'duplicate_key_input') { ... } を書き、どの SDK がフレームに署名したかに関わらずディスパッチが機能するように。エラーキャリアの内部形状（サニタイズされたキーリストのフィールド名、オーバーフローマーカー文字列、型付き例外コンストラクター引数）は実装依存です。クラッシュ / フェイルクローズする検証者はコンフォーマントだが最適でない（リクエストは黙って受け入れられないが、送信者は actionable なエラーコードを受け取らない）。検証者は代わりに構造化された不正ボディエラーを返すべきです（SHOULD）。非コンフォーマントな失敗モード — 署名検証者のパースがダウンストリームのビジネスロジックのパースと発散する黙った受け入れ — は現在禁止されています。ペイロードをビジネスロジックに渡す前に重複キーを検出しない検証者はこのスキームに準拠しません。
• 検証者の入力: 検証者は、いかなる JSON パースや再シリアライズの前にキャプチャした、ワイヤー上で受信した生の HTTP ボディバイトを使わなければなりません（MUST）。すべての現代的な HTTP フレームワークはパース前の生ボディフックを公開します（Express express.raw()、FastAPI Request.body()、aiohttp Request.read()、json.Unmarshal 前の Go io.ReadAll(r.Body)）。生キャプチャフックは同じルート上のいかなる JSON パースミドルウェアの前に実行しなければなりません（MUST）。検証者が実行される前にリクエストボディを消費するグローバルにマウントされた express.json() または FastAPI BaseModel ボディバインディングは、署名されたバイトではなく再文字列化されたペイロード上で検証者を動作させます — これは一般的なデプロイミスです。検証者はパースされたペイロードを再シリアライズして署名されたバイトを再構築すべきではありません（SHOULD NOT）: 再シリアライズは、キー順序・ユニコードエスケープ・数値フォーマットが異なる署名者に対して黙って失敗し、検証者が表面化すべき署名者のバグを隠します。生バイトを本当にキャプチャできない検証者は、再シリアライズされた近似を受け入れるのではなく、フェイルクローズしてインフラのギャップを表面化しなければなりません（MUST）。
• タイムスタンプソース: 署名メッセージ内の {unix_timestamp} は、X-ADCP-Timestamp ヘッダーで送られた正確な ASCII 整数でなければなりません（MUST）。署名者と検証者はいかなるボディフィールドからもそれを導出してはなりません（MUST NOT）。
• タイミングセーフ比較: 定数時間比較を使わなければなりません（MUST、例: timingSafeEqual）
• リプレイウィンドウ: |current_time - timestamp| > 300 秒のリクエストを拒否
• 最小シークレット長: 32 バイト
• ヘッダー形式: X-ADCP-Signature: sha256=<hex digest> と X-ADCP-Timestamp: <unix seconds>。ボディレベルの signature フィールドは便宜的なコピーであり、ヘッダーより信頼してはなりません（MUST NOT）。

1. X-ADCP-Signature または X-ADCP-Timestamp ヘッダーが欠落していれば拒否
2. タイムスタンプが非数値なら拒否
3. タイムスタンプが 5 分ウィンドウ外なら拒否
4. HMAC を計算して比較

• レシーバーはローテーション中、現在と以前の両方のシークレットからの署名を受け入れなければなりません（MUST）
• ローテーションウィンドウはリプレイウィンドウ（5 分）を超えるべきではありません（SHOULD NOT）
• パブリッシャーはローテーション時に即座に新しいシークレットで署名を開始します

​

Webhook URL 検証（SSRF）

1. 本番で非 HTTPS URL を拒否する。
2. ホスト名を解決し、解決された IP がいずれかの予約範囲に入る場合フェッチを拒否する:
   • IPv4: RFC 1918（10.0.0.0/8、172.16.0.0/12、192.168.0.0/16）、RFC 6598 CGNAT（100.64.0.0/10）、ループバック（127.0.0.0/8）、リンクローカル（169.254.0.0/16 — AWS/GCP/Azure/Alibaba のインスタンスメタデータで使われる 169.254.169.254 を明示的に含む）、ブロードキャスト（255.255.255.255）、0.0.0.0/8、マルチキャスト（224.0.0.0/4）。
   • IPv6: ループバック（::1）、ユニークローカル（fc00::/7）、リンクローカル（fe80::/10）、IPv4 マップ（::ffff:0:0/96 — 予約 IPv4 を IPv6 にマップする最も一般的なバイパス）、マルチキャスト（ff00::/8）、AWS IMDSv2 の fd00:ec2::254 アドレス。
3. 接続を検証済み IP にピン留めする。 DNS ベースのフィルタリングだけでは DNS リバインディングに脆弱です: 攻撃者は検証時にパブリック IP を、接続時にプライベート IP を提供します。フェッチャーは接続をピン留めしなければなりません（MUST）。推奨: (a) 検証済み IP を TCP connect 呼び出しに直接渡し、Host: ヘッダーを URL から設定する。フォールバック（HTTP クライアントが事前解決 IP を受け付けられない場合のみ）: (b) いかなるリクエストボディを送る前に、ソケットのハンドシェイク後ピアアドレスを予約範囲リストに対して検証する。注: (b) は最初のボディバイトが出荷される前に発火するピアアドレスフックをクライアントライブラリが公開することに依存します。多くの一般的なライブラリはそうしないため、(b) を選ぶ実装はテストでフックを検証しなければなりません（MUST）。ピン留めなしの DNS 再解決は不十分です。
4. 相手方制御の URL をフェッチする際、リダイレクトの追従を拒否する（30x レスポンスは、オリジンが最初のチェックをバイパスした予約アドレスにリダイレクトすることを許す）。2 つの制限された例外があり、各ホップでステップ 1-3 を再検証しチェーンに上限を設ける: brand.json 解決（1 リダイレクト、チェーンなし）と、初回の /.well-known/adagents.json フェッチ（標準の apex→www ホスティングが解決するよう、同一登録可能ドメインリダイレクトのみ追従 — apex ↔ www、HTTPS 保持、3 ホップ以下、最初に要求されたドメインに固定 — managed networks を参照）。adagents.json の authoritative_location 参照は例外を取りません: その 2 番目のホップでのリダイレクトは拒否しなければなりません（MUST）。
5. レスポンスサイズとタイムアウトに上限を設ける。 推奨: 5 MB ボディ上限、10 秒接続、10 秒読み取り。唯一の例外は、マネージドネットワーク間接パターンでの参照解決された権威的ファイル — ポインターファイルの authoritative_location がネットワークオリジンにリダイレクトした後の 2 番目のホップのみ — で、パブリッシャーネットワーク横断でファンアウトするため推奨 20 MB 上限を使います。ポインターファイル自体は 5 MB のままです。managed networks security を参照。
6. URL を提供したエージェントにフェッチエラーをエコーしない。 詳細なエラーメッセージ（接続拒否 vs タイムアウト vs TLS 失敗）は、内部ネットワークトポロジーを探るサイドチャネルです。

​

宛先ポート: デフォルトで寛容

• オフラインレポートバケット — IAM 層のプレフィックススコープ、アカウントステータス変更時の認証情報失効。
• コレクションリスト — auth_token スコープと失効、配信 ID 検証、Webhook 署名の規範ルール。
• マネージドネットワークの authoritative_location — バリデーターのフェッチセマンティクス、変更検出、関係終了。
• TMP プロバイダー登録 — 動的登録認証、ルーター-プロバイダー間認証、/health の情報漏洩ルール。

​

認証のベストプラクティス

​

認証情報の保管

// Use secure key management systems
// Never commit credentials to version control
// Use environment variables or secret managers

// Example: Secure credential retrieval
async function getCredentials(agentId) {
  // Retrieve from secure storage (AWS KMS, Vault, etc.)
  const encrypted = await secretManager.get(`agent/${agentId}/apiKey`);
  return decrypt(encrypted);
}

​

トークンの有効期限

const TOKEN_LIFETIMES = {
  discovery: 3600,     // 1 hour for read operations
  financial: 900,      // 15 minutes for financial operations
  refresh: 86400       // 24 hours for refresh tokens
};

function validateToken(token, operationType) {
  const decoded = jwt.verify(token, secret);
  const maxAge = TOKEN_LIFETIMES[operationType] || TOKEN_LIFETIMES.discovery;

  if (Date.now() - decoded.iat > maxAge * 1000) {
    throw new Error('Token expired for this operation type');
  }

  return decoded;
}

​

エージェントとアカウントの分離

1. 作成時にバインド — 各オブジェクト（メディアバイ、クリエイティブ、セッションなど）を、それを作成したリクエストで使われたアカウントに恒久的に関連付ける。
2. アクセス時に検証 — 後続の各読み取りまたは変更で、認証済みエージェントがオブジェクトのバインドされたアカウントへのアクセス権を持つことを検証する。
3. フェイルクローズ — 検証が失敗した場合、汎用エラーを返す（ステータス 403 または 404 が許容されるが、ボディは「未認可」を「not found」と区別したりアカウントを名指ししたりしてはならない）。決してリソースクエリにフォールスルーしない。

​

二段階パターン

1. 認可プリチェック — リクエストの account は認証済みエージェントの認可セット内になければなりません（MUST）。403 または汎用の「not found」でフェイルクローズ（決して「あなたはそのアカウントに認可されていません」ではない — それは存在の漏洩です）。
2. リソースクエリ — リクエストの account_id を主キー制約としてフィルタリング。認可セット全体ではなく、このリクエストが作用している特定のアカウントのみで。

// Two-step: precheck request account is authorized, then scope the query to it.
// authorizedAccountIds is a Set<string> populated once at auth-time, not an Array.
// Set.has() is O(1); Array.includes() is O(n) and scans element-by-element, which
// on large authorized-account sets introduces a timing difference between early
// and late matches that a caller can probe across requests.
async function getMediaBuy(mediaBuyId, requestAccountId, authAgent) {
  // Step 1: auth precheck
  if (!authAgent.authorizedAccountIds.has(requestAccountId)) {
    // Generic error - don't reveal whether the account exists
    throw new NotFoundError("Media buy not found");
  }

  // Step 2: resource query scoped to the specific account
  const mediaBuy = await db.mediaBuys.findOne({
    id: mediaBuyId,
    account_id: requestAccountId  // Primary filter
  });

  if (!mediaBuy) {
    // Generic error - same shape as the precheck failure
    throw new NotFoundError("Media buy not found");
  }

  return mediaBuy;
}

​

行レベルセキュリティ

-- PostgreSQL example
-- app.current_account is set by the auth layer AFTER the precheck above succeeds
CREATE POLICY account_isolation ON media_buys
  USING (account_id = current_setting('app.current_account')::uuid);

ALTER TABLE media_buys ENABLE ROW LEVEL SECURITY;

CREATE POLICY account_isolation_list ON media_buys
  FOR SELECT
  USING (account_id = ANY(current_setting('app.authorized_accounts')::uuid[]));

​

クライアント側の分離: クロスプリンシパルのツールコール混同

1. テキストにその起源プリンシパルをタグ付けする。 LLM コンテキストがネットワークから取り込むすべての文字列（ツール結果、Webhook ボディ、レジストリドキュメント、クリエイティブメタデータ）は、それを生成した {principal_domain, tool_name, response_field} トリプルで内部的に注釈されなければなりません（MUST）。取り込み時に注釈を落とすことが、この防御が死ぬ場所です。
2. ツールコールのターゲットを呼び出しプリンシパルに制限する。 ターゲットプリンシパルが、決定を駆動する文字列を供給したプリンシパルと同じでないツールコールは、(a) 拒否されるか、(b) 人間の承認ステップを通るか、(c) オペレーターが事前に宣言した明示的なプリンシパルごとのポリシーで仲介されなければなりません（MUST）。デフォルトは allow ではなく refuse でなければなりません（MUST）。
3. 認証情報スコープを LLM コンテキストごとに分離する。 単一の LLM プランニングループは、利害が衝突し得るプリンシパル（例: 同じインベントリを競う 2 つのブランド。1 つのコンテキスト内のバイヤー認証情報とガバナンスエージェントの署名鍵）のライブ認証情報を保持してはなりません（MUST NOT）。スコープ分離は、LLM に指示するのではなく、プロセス / ツール登録層で強制されます — LLM は誤用のアフォーダンスを持ってはなりません（MUST NOT）。
4. 成功だけでなく、すべてのクロスプリンシパルの試みをログする。 ルール 2 の下での拒否は、オペレーターが監視しなければならないシグナルです（MUST）— あるプリンシパルからの拒否率の上昇は、あなたのエージェントを標的とする注入キャンペーンの最も早く検出可能な兆候です。

​

時間セマンティクス

​

タイムスタンプ形式

✅ 2026-04-19T10:00:00Z            // UTC, recommended
✅ 2026-04-19T10:00:00-04:00       // explicit offset
❌ 2026-04-19T10:00:00             // no offset — ambiguous
❌ 2026-04-19 10:00:00             // not ISO 8601

​

区間

​

デイパートターゲティング

• バイヤー宣言ゾーン — デイパートと並ぶ IANA ゾーン名（例: timezone: "America/New_York"）。デイパートは、視聴者やパブリッシャーの場所に関わらずそのゾーンに対して評価されます。バイヤーが「ニューヨーク時間の午後 9〜11 時」をグローバルに強制したいときに使います。
• パブリッシャーローカル — デイパートはパブリッシャーが宣言したローカルゾーンで評価されます。バイヤーが「パブリッシャーのスケジュール上のプライムタイム」を望み、それが何を意味するかをパブリッシャーに決めさせてよいときに使います。
• 視聴者ローカル — デイパートは各視聴者のタイムゾーンに対して評価され、配信時に視聴者の場所シグナルから解決されます。バイヤーがグローバルオーディエンス横断で「ローカル午後 8 時に配信」を望むときに使います。

​

Request Safety

​

冪等性

• 3.1.0 — セラーは idempotency_key を運ぶ読み取りを受け入れ、ルール 2-9 に従って処理しなければなりません（MUST、未宣言のエンベロープフィールドで拒否しない）。セラーはそれを省略する読み取りを INVALID_REQUEST で拒否すべきです（SHOULD）。セラーは 3.1.x メンテナンスウィンドウの間は省略を受け入れてもよい（MAY）。
• 3.2.0 — セラーは idempotency_key を省略する読み取りを INVALID_REQUEST で拒否しなければなりません（MUST）。猶予ウィンドウは 3.2 のカットで閉じます。

​

規範的なセラーの動作

1. スキーマ検証が最初に実行される。 セラーは、冪等性キャッシュを参照する前に、リクエストをそのスキーマ（idempotency_key の存在と形式を含む）に対して検証しなければなりません（MUST）。不正なリクエストはキャッシュに一切触れずに INVALID_REQUEST を返します — さもなくばキャッシュミスがタイミングサイドチャネルになり、スキーマ検証がキー形式を受け入れたかを漏らします。検証エラーは決してキャッシュされません（ルール 2）。
2. 最初の呼び出しが正準。 タスク成功時（status: completed、または非同期オペレーションの status: submitted）、セラーは内側のレスポンスペイロード（プロトコルエンベロープではない）を (authenticated_agent, account_id, idempotency_key) でキーし、正準リクエストペイロードのハッシュと共に保存します。キャッシュエントリは不変です — TTL 内のリプレイは元々キャッシュされたペイロードを（replayed: true 付きで）返さなければならず（MUST）、そのペイロード内の状態追跡フィールドはリソースの現在の状態を反映するようリフレッシュされてはなりません（MUST NOT）。このルールは両方の成功ブランチにわたって適用されます:
   • 非同期タスク — キャッシュされたレスポンスは task_id を含む submitted 結果です。非同期タスクがその後完了・失敗・キャンセルされても、リプレイは現在の終端状態ではなく元々キャッシュされた submitted レスポンスを返さなければなりません（MUST）。バイヤーは返された task_id を使い、最初の呼び出しと全く同じように tasks/get または Webhook で現在の状態を観測します。
   • 同期成功タスク — 初回レスポンスが状態追跡フィールド（例: create_media_buy の status, packages, affected_packages。sync_creatives / sync_accounts のレコードごとの status 配列。acquire_rights / activate_signal のリソーススナップショット）を運ぶ場合、リプレイはリソースへの介在する変更に関わらず元々キャッシュされたペイロードを返さなければなりません（MUST）。status: pending_creatives で作成され、その後 update_media_buy で canceled に変更されたメディアバイは、status: pending_creatives としてリプレイされます — キャッシュされたバイトは作成時レスポンスの履歴スナップショットであり、現在状態の読み取りではありません。バイヤーは現在の状態についてリソースの読み取りエンドポイント（get_media_buys, list_accounts, list_creatives など）を参照しなければなりません（MUST）。下記「バイヤーの義務」を参照。
   これはバイト安定なキャッシュ特性を一律に保ち、冪等性層をリソースライフサイクルから分離します — セラーはタスクやリソース状態が変わってもキャッシュエントリを更新する必要がありません。代替案（「リプレイ時に状態フィールドをリフレッシュ」）は、すべてのセラーにリソース状態機械を冪等性キャッシュに通させ、あるキーの有効なキャッシュ内容の数を増やし（単一キーのリプレイが呼び出し間で決定論的でなくなる）、残りのルールが依拠する正準リプレイの不変条件を壊します。セラーは、一部の状態追跡フィールドがリプレイ時にリフレッシュされ、他がされないハイブリッドを実装してはなりません（MUST NOT）— 部分リフレッシュは両方の選択肢の最悪で、非コンフォーマントです。
3. 成功レスポンスのみがキャッシュされる。 いかなるエラー — 検証、ガバナンス拒否、トランスポート失敗、内部エラー — でもキーは保存されません。リトライは再実行します。これはバイヤーの意図に一致します: 5xx 後のリトライは失敗をリプレイするのではなく再試行すべきです。また、バイヤーの不正リクエストがキーに TTL 全体ロックされるのを防ぎます。
4. リプレイはキャッシュされたレスポンスを返す。 同じ idempotency_key かつ等価な正準形ペイロード（下記「ペイロード等価性」を参照）を持つ後続リクエストは、副作用を再実行せずに保存された内側レスポンスを返さなければなりません（MUST）。セラーはレスポンス時に送信プロトコルエンベロープに replayed: true を注入します — replayed は冪等性層が生成するエンベロープレベルのフィールドであり、キャッシュされた内側レスポンスの一部ではありません。リプレイ時の注入により、エンベロープ変更（新しい timestamp、ローテーションされた governance_context など）に関わらずキャッシュされたペイロードがリプレイ間でバイト安定に保たれます。MCP のトランスポート固有の注記: MCP ツールレスポンスは別個のエンベロープスロットを持ちません。サーバーは replayed をツール結果オブジェクト自体の中（例: 構造化リターンの先頭）またはレスポンスメタデータフィールドで公開してもよい（MAY）。REST と A2A レスポンスはエンベロープフィールドを直接使います。
5. 異なる正準ペイロードでのキー再利用は競合。 同じキー、リプレイウィンドウ内で異なる正準ハッシュは IDEMPOTENCY_CONFLICT で拒否しなければなりません（MUST）。セラーは 2 番目のリクエストを黙って適用してはなりません（MUST NOT）。
6. 期限切れキーは明示的に拒否される。 replay_ttl_seconds が経過した後、セラーはキャッシュエントリを退避してもよい（MAY）。セラーが見たことのあるキーで退避後に到着するリクエストは、黙って新規として扱うのではなく IDEMPOTENCY_EXPIRED で拒否すべきです（SHOULD）— 黙った再実行は、まさにキーが防ぐはずのダブルブッキングのフットガンです。セラーは TTL 境界で ±60 秒のクロックスキューウィンドウ（本書の他所で JWS exp に適用される許容範囲と同じ）を許可すべきです（SHOULD）。名目上の期限切れの数秒後に到着するリトライが、新規として扱われるのではなく依然キャッシュからリプレイされるように。 耐久性は規範的。 宣言された replay_ttl_seconds はベストエフォートのキャッシュヒントではなく耐久性契約です。セラーは、宣言された TTL の間、プロセス再起動、ポッド置換、リージョンフェイルオーバー、オペレーター起因のキャッシュフラッシュを生き延びるストレージで冪等性キャッシュをバックアップしなければなりません（MUST）。インメモリのみのストア（プレーンな Map、バッキング層なしの単一プロセス LRU）は、replay_ttl_seconds がプロセス寿命を超えるときは常に非コンフォーマントです — 3600 秒の下限では常に真です。宣言された TTL 未満での黙った退避の帰結は変位リプレイウィンドウです: 送信者は新しい署名ノンスの下で同じ idempotency_key で正当にリトライし（署名済みリトライが機能すべき方法 — ノンスは送信ごとであってイベントごとではない）、署名リプレイチェックを通過し、レシーバーのインメモリ状態が落とされたためアプリ層キャッシュが空であることを見つけます。副作用が 2 回実行されます。セラーは、キャッシュ層が耐久的に守れる以上の replay_ttl_seconds を宣言してはならず（MUST NOT）、「見たことがない」を「宣言 TTL 下で退避された」と区別できないとき、フェイルオープン（黙った再実行）ではなくフェイルクローズ（IDEMPOTENCY_EXPIRED）しなければなりません（MUST）。運用上の現実が「メモリのみ、ポッド再起動で消失」のセラーは、replay_ttl_seconds を保証される最短ポッド寿命以下に宣言することが求められます — 実際上、これは耐久層を強制します。
7. リプレイウィンドウは推論ではなく宣言される。 セラーは get_adcp_capabilities で capabilities.idempotency.replay_ttl_seconds を宣言しなければなりません（MUST、最小 3600 秒 / 1 時間、推奨 86400 秒 / 24 時間、最大 604800 秒 / 7 日）。クライアントは想定デフォルトにフォールバックしてはなりません（MUST NOT）— 宣言のないセラーは非準拠で、リトライ機微なオペレーションには安全でないものとして扱わなければなりません（MUST）。
8. キャッシュ増大防御。 セラーは、リクエストレート制限とは別に、(authenticated_agent, account) ごとの冪等性キャッシュ挿入レート制限を適用しなければならず（MUST）、エージェントごとの挿入レートが設定上限を超えたときはキャッシュを無制限に増大させるのではなく RATE_LIMITED（error taxonomy を参照）を返さなければなりません（MUST）。安価な成功パスオペレーション（例: log_event）で毎秒 N 個の新しいキーを送るバイヤーは、さもなくば無制限のストレージを強制し、3600 秒の下限で replay_ttl_seconds に比例した増幅を伴います。自然な境界は inserts_per_hour × replay_ttl_hours ≤ max_cache_rows_per_agent です。 推奨上限（3.1+）: 元の 60/秒持続 / 300/秒バーストの単一予算上限は、書き込み重視のローンチパターン（10 メディアバイ/分以下 × 10 パッケージ × 10 クリエイティブ、3-5 倍の余裕）に対してサイズされました。ユニバーサル冪等性の下では、読み取りトラフィックも挿入レートに寄与します — 5 アカウント横断で get_products(brief) + list_creatives + list_accounts を 1Hz でポーリングする単一のエージェンティックダッシュボードは、いかなる書き込み活動の前に読み取りだけで約 15 挿入/秒です。オペレーターは (authenticated_agent, account) ごとの分割予算を採用すべきです（SHOULD）:
   • 読み取り: 300 挿入/秒持続、ローリング 10 秒ウィンドウで 1,500/秒バースト。 Polling / state re-read ルール下でのダッシュボードポーリングとエージェンティック状態再読み取りが支配的。読み取りトラフィックは通常、ユーザー駆動の UI 操作中はバースト的、エージェント実行中は低レートで安定。
   • 書き込み: 60 挿入/秒持続、300/秒バースト。 元の書き込み重視サイジングから変更なし — バイヤーのダッシュボードポーリングが、create_media_buy / sync_creatives / activate_signal をダブル実行レースから守る書き込み容量を枯渇させられないよう、別個の予算として保持。
   • 合算上限（多層防御）: 総挿入はエージェントごとに 350/秒持続 / 1,700/秒バーストを超えるべきではありません（SHOULD NOT）— 小さなクッション付きの 2 予算の合計。読み取り予算を飽和させる攻撃者が書き込み容量を飢えさせられないように。
   安定した低ボリュームトラフィックのオペレーターはこれらの開始値未満に締めてもよい（MAY）。この上限より大きいバーストオンボーディングやトラフィッキングパターンのオペレーターは、正当なトラフィックの黙った拒否を受け入れるのではなく引き上げなければなりません（MUST）。分割予算の形状（別個の読み取りと書き込みカウンター）は、オペレーターが大きさを締めても 3.1 以降実装しなければなりません（MUST）— 共有単一予算上限がこのルールが防ぐ失敗モードです。持続境界はローリング 60 秒ウィンドウです — 10 秒ウィンドウを空にするバーストは 60 秒ローリング境界の次の 50 秒にカウントされます。異なるウィンドウ形状（固定分バケット、EWMA）を採用するセラーは、リトライロジックを持つバイヤーが RATE_LIMITED がいつ発火するか予測できるよう文書化しなければなりません（MUST）。セラー間のウィンドウ形状の黙った発散は、同一のバイヤートラフィックがあるセラーを通過し、コンフォーマントな実装で別のセラーに拒否されることを意味します。3600 秒 TTL 下限で合算上限レートはエージェントごとの常駐を約 126 万エントリに制限します — 書き込みのみサイジングの元の 21.6 万から一桁上で、読み取りトラフィックの追加を反映します。エージェントごとのストレージ予算はこれを考慮すべきです。数値推奨は SHOULD レベルです。レート制限して RATE_LIMITED で拒否する動作自体は MUST です。セラーは上限を調整可能な設定パラメーターとして公開しなければなりません（MUST）— 300/60 の読み取り/書き込み分割数はエージェンティックバイヤーダッシュボードパターンの初回デプロイ開始点であり、凍結されたデフォルトではありません。セラーは正確な設定上限数値をケイパビリティレスポンスで公開すべきではありません（SHOULD NOT）— そうすると上限がエコシステム全体の攻撃ターゲットになります。バイヤーは、ケイパビリティイントロスペクションではなく RATE_LIMITED + retry_after レスポンスを通じて実効上限を発見します。 上限は (authenticated_agent, account) ごとです — 冪等性キー自体（項目 1）と同じスコープ — なので、マルチアカウントエージェンシーはアカウントごとの予算が単一の共有クォータに畳み込まれません。RATE_LIMITED 拒否は error handling taxonomy に従い retry_after（秒）を設定しなければならず（MUST）、冪等性レスポンスとしてキャッシュされてはなりません（MUST NOT、ルール 3: 成功レスポンスのみキャッシュ）。セラーは retry_after を安価な拒否フロアとして強制すべきです（SHOULD）— retry_after 経過前にリトライするバイヤーは、リトライごとにフルのスキーマ検証・キャッシュチェックパイプラインに再入するのではなく、事前認証トークンバケット（例: リバースプロキシ層）にヒットすべきです（SHOULD）。この規律なしでは、誤動作するバイヤーがレートリミッター自体の負荷を増幅できます。
9. 並行リトライ — 最初の挿入が勝つ。 同じ (authenticated_agent, account_id, idempotency_key) を運ぶ 2 番目のリクエストが、最初のリクエストがまだ実行中に到着してもよい（MAY）— 最も一般的には、セラーのダウンストリーム呼び出しが返る前にバイヤーのトランスポートタイムアウトが発火し、バイヤーがリトライするとき。セラーはレースを決定論的に解決しなければならず（MUST）、副作用を 2 回実行してはならず（MUST NOT）、2 番目のリクエストを黙って落としてはなりません（MUST NOT）。解決はスコープタプル上の (unique constraint, INSERT … ON CONFLICT DO NOTHING) パターンです: 最初に着地する行が実行を所有し、正準ペイロードハッシュを実行中の行に保存する（センチネルではない）。後続リクエストは、レスポンススロットがまだ設定されていないがペイロードハッシュは設定されている既存行を観測します。 セラーは 2 番目のリクエストを 2 つのポリシーの 1 つで処理しなければならず（MUST）、呼び出し間で一貫して動作しなければなりません（MUST）— クライアントはセッション内の最初のレスポンスからポリシーを推論し、後続のリトライに適用します:
   • Wait-and-replay（高速オペレーション向け推奨、通常 5 秒未満）: セラーは最初が完了するまで 2 番目のリクエストをブロックし、その後 replayed: true 付きでキャッシュされたレスポンスを返します。2 番目の呼び出しの総壁時間はセラーのリクエストタイムアウト予算で制限されます。
   • Reject-and-redirect（長時間実行のダウンストリーム呼び出しを伴う低速オペレーション向け推奨）: セラーは即座に IDEMPOTENCY_IN_FLIGHT を返し、最初のリクエストの経過時間と予想完了に基づいて error.details.retry_after（秒、整数）を設定します。バイヤーはヒント経過後、同じ idempotency_key でリトライしなければなりません（MUST）— IDEMPOTENCY_IN_FLIGHT で新しいキーを生成するバイヤーは、安全なリトライを、まさにこのルールが防ぐダブル実行レースに変えます。
   同じキーかつ異なる正準ペイロードを持つ 2 番目のリクエストが実行中ウィンドウ中に来た場合、IDEMPOTENCY_IN_FLIGHT ではなく IDEMPOTENCY_CONFLICT（ルール 5）を返さなければなりません（MUST）— 正準形の不一致は行の保存済みハッシュに対して INSERT 時に計算可能なので、最初のリクエストのレスポンスを待たずに競合を検出できます。バッキングストアがハンドラー完了まで実際の正準ハッシュを永続化できないセラー（例: プレースホルダーセンチネルパターン）は、ルール 9 のコンフォーマンスを宣言する前に INSERT 時にハッシュを永続化するようストアをアップグレードしなければなりません（MUST）— 代替案（同一キー・異ペイロードレースで IDEMPOTENCY_IN_FLIGHT を返し、最初のリクエスト完了後にのみ競合を表面化）は、実際のクライアントバグの検出を黙って遅らせます。 ルール 3 に従い、最初のリクエストが最終的に失敗する（検証エラー、ダウンストリームタイムアウト、内部エラー）場合、(in_flight) 行は解放されます — キーは「見たことがない」状態に戻り、後続のリトライは最初から再実行します。セラーは実行中の行の寿命を宣言されたタスクごとハンドラータイムアウトに制限しなければならず（MUST）、そのタイムアウトが発火したとき — ダウンストリームがまだ応答していなくても — 行を解放しなければなりません（MUST、ルール 3 に従い失敗として扱う）。この境界なしでは、ハングしたハンドラーが同じキーに対して無期限に IDEMPOTENCY_IN_FLIGHT を返し、バイヤーをいかなる安全なリトライパスからもロックアウトします。 reject-and-redirect を使うセラーは、error.details.retry_after を replay_ttl_seconds（capabilities.idempotency で宣言）以下の値に設定しなければなりません（MUST）。セラー自身のリプレイウィンドウを過ぎて待つよう指示されたバイヤーは、レスポンスがもはやリプレイできなくなるまで待つよう言われています — 待機は無意味で、バイヤーは新しいキーを生成する（このルールが防ぐ失敗モード）か、リトライで IDEMPOTENCY_EXPIRED にヒットします。セラーは capabilities.idempotency.in_flight_max_seconds — 実行中の行の最大寿命、セラーのタスクごとハンドラータイムアウトにスコープ — も宣言すべきです（SHOULD）。バイヤーは存在する場合その宣言値を主要なリトライ予算境界として使うべきです（SHOULD）。不在の場合、桁数ヒューリスティクス（セラーの典型的なハンドラーレイテンシーから導出され、リプレイ TTL の一桁下、決して TTL 上限自体ではない値）にフォールバックします。 セラーはスコープ境界をまたいで実行中の状態を漏らしてはなりません（MUST NOT）: 候補キーを探る攻撃者は、行が存在するか、実行中か、一度も存在しなかったかに関わらず、同じレスポンス形状とタイミングを受け取らなければなりません（MUST）。
10. サービス境界をまたぐ — ダウンストリームリコンシリエーション。 セラーはリクエスト処理中にダウンストリームシステムを呼び出すのが一般的です — create_media_buy での SSP/アドサーバー呼び出し、請求オペレーションでの決済プロバイダー呼び出し、check_governance でのガバナンスエージェント呼び出し。これらの呼び出しは、セラーを「ダウンストリーム不明」状態に残し得る独自の失敗モードを持ちます: ダウンストリームがリクエストを受け入れた後、そのレスポンス到着前にネットワーク接続が切れた。セラープロセスが呼び出し中にクラッシュした。リージョンフェイルオーバーがレスポンス永続化前にワーカーをスワップした。ルール 3（成功レスポンスのみキャッシュ）は必要だが不十分です: 単にキャッシュせずリトライで再実行するセラーは、ダウンストリームを二重呼び出しし、そこで重複した副作用を作ります。 コンフォーマンスの採点。 このルールはコンプライアンスストーリーボードスイートによるプログラム的採点ではなく、レビュアー採点です。ブラックボックス観察は「セラーがクレーム行を持つ」を「セラーがテスト実行で運が良かった」と区別できません。parallel_dispatch_runner テストキットはルール 10 のコンフォーマンスを reviewer_checks の下にリストします — ルール 10 のコンフォーマンスを表明するセラーは、どのパターンがどのダウンストリームに適用されるかを記述する運用ランブックを表面化しなければならず（MUST）、レビュアーはそのランブックに対して実装を検証します。他の規範ルール（1-9）はプログラム的に採点されます。 セラーは、二重呼び出しがビジネス上の帰結（リソース作成、決済移動、不可逆な状態変更）を持つすべてのダウンストリーム呼び出しについて、2 つのリコンシリエーションパターンの 1 つを採用しなければなりません（MUST）。読み取り専用のダウンストリーム呼び出し（キャッシュルックアップ、書き込まない適格性チェック）は免除されます — が、ダウンストリーム監査ログにも書く不正スコアリングルックアップのような境界ケースはこのルールでは書き込みとしてカウントされます（監査ログエントリが副作用）。
    • Write-claim-before-invoke（推奨デフォルト）。 ダウンストリームを呼び出す前に、セラーは冪等性キャッシュ行と同じトランザクションで「クレーム」行を永続化します — 通常 {idempotency_key, downstream_provider, downstream_request_id, status: 'invoked', invoked_at} — セラー生成の downstream_request_id（ダウンストリーム自身の相関/冪等性識別子としてダウンストリームに渡す）を使って。リトライ時、ダウンストリームを再度呼び出す前に、セラーは (idempotency_key, downstream_provider) でクレーム行をルックアップしてリコンサイルしなければなりません（MUST）: downstream_request_id でダウンストリームをクエリして真の結果を判定し、そこからキャッシュ投入を再開します。セラーは、ローカルレコードの欠落を「ダウンストリーム呼び出しは起きなかった」と扱ってはなりません（MUST NOT）— ダウンストリーム受け入れとローカル永続化の間のクラッシュは、まさに起きてローカルレコードが欠落しているケースです。ダウンストリームが downstream_request_id のレコードなしを報告する場合（クレーム行は永続化されたが、セラーが呼び出し前にクラッシュ）、セラーは呼び出しを未実行として扱い、呼び出しを進めなければなりません（MUST）。クレーム行はすでに downstream_request_id を予約しているので、ダウンストリーム自身の冪等性が後続のリトライを重複排除します。ダウンストリームルックアップからの曖昧なレスポンス（一時的 5xx、ネットワークエラー、不正レスポンス）では、セラーはフェイルクローズしなければなりません（MUST）— 未認証の「レコードなし」シグナルで呼び出しを進めるのではなく、バイヤーに一時的エラーを返します（バイヤーがルール 9 に従い同じ idempotency_key でリトライするように）。
    • Thread-buyer-key（ダウンストリームプロトコルがサポートする場合に許容）。 セラーはバイヤーの idempotency_key のダウンストリームプロバイダーごとの派生をダウンストリーム自身の冪等性キーとして渡します — 通常 HMAC(K_provider, idempotency_key)。ここで K_provider はプロバイダーアイデンティティでキーされたセラーの KMS 管理ルートから導出されます（ダウンストリームごとに 1 鍵、すべてのダウンストリームで共有する 1 つのセラーシークレットではない）。プロバイダーごとの導出は、単一のダウンストリームが侵害された場合のクロスプロバイダーリプレイを防ぎます。すべてのダウンストリームで共有するセラーシークレットは、すべてのプロバイダーを単一の鍵露出影響範囲に畳み込みます。ダウンストリームの at-most-once 保証が、セラーのローカル永続化が見逃したケースをカバーします。セラーは、キャッシュされたレスポンスが正しく投入されるよう成功パスで依然クレーム行を書かなければなりません（MUST）が、ダウンストリーム自体がリトライ時の真実の源になります。セラーは、異なる信頼プリンシパルが運用する任意のダウンストリームにバイヤーの生の idempotency_key を渡してはなりません（MUST NOT）— バイヤーのキーは TTL 内のケイパビリティトークン（下記「キーはセキュリティ機微」を参照）であり、信頼境界をまたいで転送するとケイパビリティ面が広がります。「異なる信頼プリンシパル」とは、セラーが同じセキュリティ境界の下で運用しない任意のシステムを意味します。セラーがエンドツーエンドで所有する純粋にテナント内のマイクロサービス（同じ KMS、同じ監査ログ、同じオペレーター）に生のキーを渡すことは信頼境界をまたがず、許可されます（ただしプロバイダーごとの導出が依然としてより良いデフォルト）。
    セラーは、どのパターンがどのダウンストリームに適用されるかを運用ランブックに文書化しなければなりません（MUST）。セラーは「ダウンストリームレスポンス検査でのベストエフォート重複排除」という 3 番目のパターン — ダウンストリームのレスポンスペイロードをキャッシュされた指紋と比較して呼び出しがすでに起きたか判定 — を使ってはなりません（MUST NOT）。ダウンストリームのレスポンス形状はバージョン間で変わり、指紋は同期バグの温床だからです。クレーム行 OR スレッド化されたキー。レスポンスへのパターンマッチではありません。 セラーは、ダウンストリーム起因のエラーをバイヤーに返す際、バイヤーの idempotency_key（またはその可逆な派生）をエラーエンベロープに含めてはなりません（MUST NOT）。セラーのダウンストリームプロバイダーごとのキー（またはセラーが誤って生でスレッド化した場合はバイヤーのキー）に言及するダウンストリームエラーは、バイヤーに伝播する前に再キーまたは除去されなければなりません（MUST）— さもなくばダウンストリームエラーメッセージが信頼境界をまたぐキー開示面になります。 このルールのバイヤー可視の帰結: セラーが低速ダウンストリームを呼び出し、バイヤーがウィンドウ中にリトライするとき、2 番目のリクエストでのセラーのレスポンスは、ダウンストリームの動作ではなく、ルール 9 の下でのセラーのポリシー（IDEMPOTENCY_IN_FLIGHT または wait-and-replay）で決まります。バイヤーはどのダウンストリームがパスにあるか知る必要はありません — セラーは関わらず一律のリトライ面を提示しなければなりません（MUST）。

​

ペイロード等価性

• idempotency_key — キー自体
• context — バイヤー不透明なエコーデータ（トレース ID、相関 ID）は設計上リトライで変わる
• governance_context — エンベロープ上。リトライでリフレッシュされた署名トークンかもしれない
• push_notification_config.authentication.credentials — ローテーションされた bearer トークンかもしれない。URL とスキームはハッシュに残る。クレデンシャル値のみ除外。

• TypeScript / JavaScript: @truestamp/canonify または canonicalize
• Python: pyjcs または RFC 8785 appendix のリファレンス実装
• Go: gowebpki/jcs
• Rust: serde_jcs

​

サーバー側ツールラッパーのコンフォーマンス

• idempotency_key はすべての AdCP タスクリクエストで必須です（上記ルール 1 を参照 — 読み取りも変更系も）。ツールラッパーはそれを受け入れなければなりません（MUST）。冪等性層がルール 2-9 に従ってルーティングします。フィールドを unexpected_keyword_argument（FastMCP/Pydantic の厳格なシグネチャ）で拒否するラッパーは非コンフォーマントです。
• context_id, context, push_notification_config, governance_context は読み取りを含むすべてのツールで受け入れられなければなりません（MUST）。あるフィールドを消費しないツールはそれを無視しなければならず（MUST）、エンベロープフィールドが存在するという理由で呼び出しを拒否してはなりません（MUST NOT）。

• 厳格なシグネチャの FastMCP / Pydantic — def get_products(brief: str) と宣言されたツールラッパーは、バイヤーが同じ params オブジェクト内に idempotency_key を送ると unexpected_keyword_argument を送出します。修正: idempotency_key: str | None = None（および他のエンベロープフィールド）を受け入れて無視する任意パラメーターとして宣言するか、**kwargs catch-all を使って未知のキーを破棄します。Pydantic-on-input は Extra.allow または model_config = ConfigDict(extra='allow') を使います。
• .strict() 付きの Zod / valibot はインバウンドリクエストスキーマで同じ理由で未知のキーを拒否します。入力スキーマで .strict() を外すか、passthrough バリアントで合成します。
• codegen ツールが additionalProperties: false を注入した OpenAPI 生成サーバースタブ — 生成された入力スキーマがスペックの additionalProperties: true デフォルトをミラーすることを検証します。一部のジェネレーターはモデル発行時にデフォルトを反転させます。

​

レスポンスレベルのリプレイインジケーター

{
  "status": "completed",
  "replayed": true,
  "timestamp": "2026-04-18T14:35:00Z",
  "payload": {
    "media_buy_id": "mb_01HW7J8K9P0Q1R2S3T4U5V6W7X"
  }
}

• エージェントの副作用抑制 — 人間が見る前にレスポンスデータに作用するエージェント（通知、ダウンストリームツール呼び出し、メモリ書き込み）は、リトライで再発行しないよう replayed を確認しなければなりません（MUST）。「キャンペーン作成！」通知、LLM メモリ挿入、ダウンストリームエージェント呼び出しは、まさに黙ったリプレイが壊すものです。
• 副作用の不変条件 — exactly-once イベントセマンティクスを期待するダウンストリームシステムは、レスポンスを新しいイベントとして扱う前に replayed を読みます。
• 請求リコンシリエーション — 「今月 N 個のバイを処理」は replayed: false のみをカウントします。
• ロギング — 「キャッシュを返してリトライが成功」を「リトライが新しい実行をトリガー」から区別（後者は通常リプレイウィンドウやキー管理のバグを示します）。
• 状態機械ルーティング — キャッシュされた payload の状態追跡フィールド（例: リプレイされた create_media_buy の status: pending_creatives）は、現在状態の読み取りではなく履歴スナップショットです（セラールール 2 とバイヤーの義務下の「リプレイレスポンスは履歴スナップショット」を参照）。バイヤーはいかなる状態依存アクションの前にリソースの読み取りエンドポイントを介して再読み取りしなければなりません（MUST）。

​

IDEMPOTENCY_CONFLICT レスポンス形状

• code: "IDEMPOTENCY_CONFLICT" と人間可読な message を含めなければなりません（MUST）
• キャッシュされたレスポンス、元のペイロード、正準形の diff、それらから導出された指紋を含めてはなりません（MUST NOT）。field json-pointer ヒントは無害に見えますがスキーマ形状を明かします（例: /packages/0/budget は攻撃者に、被害者のペイロードが最初のパッケージに予算を持っていたと伝えます）。セラーは発行してはなりません（MUST NOT）。リトライをデバッグする正当なバイヤーは自身の 2 つのペイロードを diff できます — 両方を持っています。

{
  "errors": [
    {
      "code": "IDEMPOTENCY_CONFLICT",
      "message": "idempotency_key was used with a different payload within the replay window. Either resend the exact original payload (to return the cached response) or generate a fresh UUID v4 to submit this new payload.",
      "recovery": "correctable"
    }
  ],
  "context": { "correlation_id": "..." }
}

​

SI send_message の冪等性モデル

• TTL 内のターン N のリトライはターン N のキャッシュされたレスポンスを返します。ターン N+1 がその後受け入れられていても。冪等性はあなたがしたことを返し、セッションが何であるかを巻き戻しません。バイヤーのリトライは「私のメッセージは通ったか」を尋ねています — 答えは依然「はい、これが返ってきたものです」です。
• 新しい idempotency_key を持つ新しい si_send_message は新しいターンで、現在のセッション状態に対して処理されます。バイヤーは HTTP 試行ごとではなく論理ターンごとに新しいキーを生成しなければなりません（MUST）。
• セラーがセッション状態をターン N を超えて進め、キャッシュされたレスポンスをバイト単位で再現できない場合（例: セッションがストレージのためにプルーニングされた）、セラーは再構築するのではなく SESSION_NOT_FOUND または IDEMPOTENCY_EXPIRED を返してもよい（MAY）。セッションタイムアウトをはるかに過ぎてリトライするバイヤーはこれを予期すべきです。

​

バイヤーの義務

• ネットワークリトライ — ソケットタイムアウト、5xx、一時的失敗。バイヤーは同じ意図を持ち同じバイトを送った — そしてそれらを同じキーで再送しなければなりません（MUST）。これが idempotency_key の存在理由です。
• エージェント再計画 — バイヤーは、プランナーが再実行され（プロンプト再実行、ツール出力変化、ポリシー再評価）異なるペイロードを生成したエージェントです。意図が変わりました。エージェントは新しいキーを生成し、以前のリクエストを放棄されたものとして扱わなければなりません（MUST）。以前のキーを異なる正準ペイロードで再利用すると IDEMPOTENCY_CONFLICT を返し、これはセラーが正しくエージェントに「あなたはリトライしていない、新しいことをしている」と伝えるものです。
• ポーリング / 状態再読み取り — get_products(brief), list_creatives, list_accounts を間隔でポーリングするダッシュボード。変更後に新しい状態をフェッチするため get_media_buys を読むバイヤーエージェント。任意の「時刻 T の現在状態をください」呼び出し。バイヤーは呼び出しごとに新しい idempotency_key を生成しなければなりません（MUST）。以前のポーリングのキーを再利用すると、キャッシュされたスナップショットを（replay_ttl_seconds まで）リプレイし、黙って古いデータを返します — まさにキャッシュが変更系で防ぐ失敗モードです。このルールは下記の リプレイレスポンスは履歴スナップショット パターンの再読み取りステップも規定します: 「現在状態の再読み取り」呼び出しは新しいキーを運ばなければならず（MUST）、決して状態を読んでいる変更のキーを使いません。

import { canonicalize } from "@truestamp/canonify"; // RFC 8785 JCS
import { createHash } from "node:crypto";

const EXCLUDED_FROM_HASH = new Set([
  "idempotency_key",
  "context",
  "governance_context",
]);

function payloadHash(request) {
  const filtered = Object.fromEntries(
    Object.entries(request).filter(([k]) => !EXCLUDED_FROM_HASH.has(k)),
  );
  // If push_notification_config.authentication.credentials rotates, exclude it too
  if (filtered.push_notification_config?.authentication) {
    const { credentials, ...auth } = filtered.push_notification_config.authentication;
    filtered.push_notification_config = {
      ...filtered.push_notification_config,
      authentication: auth,
    };
  }
  return createHash("sha256").update(canonicalize(filtered)).digest("hex");
}

async function createMediaBuy(request, envelope) {
  if (!request.idempotency_key) {
    throw new InvalidRequestError("idempotency_key is required");
  }

  const requestHash = payloadHash(request);

  const existing = await db.findByIdempotencyKey({
    agent_id: currentAgent.id,
    account_id: request.account.account_id,
    idempotency_key: request.idempotency_key,
  });

  if (existing) {
    if (existing.expires_at < new Date()) {
      throw new IdempotencyExpiredError("idempotency_key is past replay window");
    }
    if (existing.request_hash !== requestHash) {
      throw new IdempotencyConflictError("idempotency_key reused with a different payload");
    }
    // Return the stored INNER payload; replayed: true is injected by the envelope layer
    envelope.replayed = true;
    return existing.response;
  }

  return db.transaction(async (tx) => {
    const response = await processMediaBuy(tx, request);
    // Cache ONLY on success, and cache only the inner response payload
    await tx.idempotencyKeys.insert({
      agent_id: currentAgent.id,
      account_id: request.account.account_id,
      key: request.idempotency_key,
      request_hash: requestHash,
      response,
      expires_at: new Date(Date.now() + TTL_SECONDS * 1000),
    });
    envelope.replayed = false;
    return response;
  });
}

​

自然キー冪等性は代替にならない

​

署名付きガバナンスコンテキスト

• ガバナンスエージェントがトークンに署名します。署名する唯一の当事者です。
• バイヤーはガバナンスエージェントから受け取ったトークンをプロトコルエンベロープに添付し、セラーに転送します。バイヤーはトークンを構築・変更・再署名してはなりません（MUST NOT）。バイヤーは自身の監査記録のため jti と check_id を保持すべきです（SHOULD）。
• セラーはトークンを受け取ったまま永続化し、後続のすべてのガバナンス呼び出しにそのまま含めます。検証を実装するセラーは、トークンに基づいて行動する前に下記のチェックリストに従って検証しなければなりません（MUST）。検証をまだ実装していないセラーも、ダウンストリームの検証可能な当事者（監査人、規制当局）が後でそれに基づいて行動できるよう、トークンを変更せずに永続化・転送しなければなりません（MUST）。
• 監査人と規制当局はガバナンスエージェントの公開鍵を使って独立に検証します — これが署名形式が提供するために存在するアカウンタビリティ特性です。

​

スコープと依存関係

• スコープ内（3.0）: バイサイドガバナンス。governance_context トークンは、AdCP タスク（create_media_buy, acquire_rights, activate_signal, creative_services）を介してなされる支出コミットメントを認可します。独自のコンプライアンスポリシーを実行するセラー（例: CTV 政治広告ルール、パブリッシャーブランドセーフティゲート）は、それらを独自のガバナンスワークフロー上の conditions レスポンスで表現します。このプロファイルの下では署名付きトークンを発行しません。
• スコープ外（3.0）: セラーサイドのガバナンス当局。将来の RFC が adagents.json を介して宣言されるセラーサイドの署名付き決定をカバーするようこのプロファイルを拡張するかもしれません。
• スコープ外（永久）: OpenRTB 入札ストリーム。ガバナンスの証明は AdCP メディアバイ境界で終わります。署名付き証明をインプレッションごとの入札リクエストに通すことは運用上実現不可能（1 トークン、多数の受信者、ブロードキャストファンアウト）で不要（支出認可はインプレッションごとではなくメディアバイ時に発生）です。

​

AdCP JWS プロファイル

• alg: サーバー側ランタイムでは EdDSA（Ed25519）を RECOMMENDED。Ed25519 が明示的なランタイム設定を要するエッジランタイム（Cloudflare Workers、Vercel Edge、Deno Deploy）では ES256（ECDSA P-256）を RECOMMENDED。検証者は none、HS*、2048 ビット未満の任意の RS* バリアントを拒否しなければなりません（MUST）。検証者はトークンヘッダー上で許可リストを強制しなければならず（MUST）、ライブラリのデフォルトのみに頼ってはなりません（MUST NOT）。
• kid: REQUIRED。発行者の JWKS 内の署名鍵を識別します。
• typ: REQUIRED。正確に adcp-gov+jws でなければなりません（MUST、バイト単位一致。検証者は RFC 6838 §4.2.8 に従い +jws 構造化サフィックスを正規化・除去してはならない、MUST NOT）。型付きヘッダーは、ガバナンス署名鍵が別目的の汎用 JWT を検証するよう騙されるのを防ぎます。
• crit: crit リストのクレームが存在する場合 REQUIRED。RFC 7515 §4.1.11 に従い、crit は検証者が理解しなければならないヘッダー/クレーム名の配列です。検証者は crit の名前が認識されない場合トークンを拒否しなければなりません（MUST）。ガバナンスエージェントは、省略または誤解釈が認可セマンティクスを変える任意のクレーム（例: 将来の budget_cap クレーム）を crit にリストしなければなりません（MUST）。これはプロファイルが後のバージョンでクレームを追加するときの黙ったダウングレード攻撃を防ぎます。

​

バイヤーアイデンティティ解決

1. mTLS: バイヤーがクライアント証明書を提示。証明書の Subject/SAN がバイヤーの登録済みドメインに解決。セラーが https://{domain}/.well-known/brand.json をフェッチ。
2. 事前プロビジョニングされたバイヤーアイデンティティ: オンボーディング時にセラーが発行し、セラーの記録でバイヤーのドメインにマップされた API キーまたは OAuth クライアント識別子。
3. #2307 に従う署名付きリクエスト（3.1 規範）: keyid がバイヤーの adagents スタイルエージェントレジストリのバイヤー宣言公開鍵に解決する RFC 9421 HTTP Signatures。

​

鍵ディスカバリー（JWKS）

1. Buyer identity resolution のルールを介してバイヤードメインを確立する。
2. バイヤーの brand.json をフェッチする。type が governance で url がトークンの iss とバイト単位で等しい agents[] エントリを見つける。一致するエントリがなければ拒否する。
3. 宣言されていればエントリの jwks_uri を使う。不在の場合、{origin of iss}/.well-known/jwks.json（origin = RFC 6454 に従う scheme+host+port）をデフォルトとする。共有オリジンから複数バイヤーを提供するマルチテナントガバナンスエージェントは、テナント鍵素材がオリジン横断でプールされないよう、明示的なテナントごとの jwks_uri を宣言しなければならない（MUST）。シャーディングは分離要件だけでなくサイズ要件でもある: 各 jwks_uri は MAX_JWKS_BYTES 予算（64 KiB — 下記の検証者疑似コードを参照）の下でフェッチされ、これは JWKS 固有の上限で、汎用の 5 MB SSRF ボディ上限より意図的に厳しい。数百のテナントごとの鍵をプールする単一の JWKS は 64 KiB を超えて拒否されるので、テナントごとの jwks_uri（それぞれ小さな鍵セットを提供）— 1 つの集約ドキュメントではない — がスケール時のコンフォーマントなパス。
4. JWKS を HTTPS でフェッチする。
5. JWKS 内で kid がトークンヘッダーに一致する鍵を見つける。kid のキャッシュミスでは、拒否する前に JWKS を 1 回再フェッチする（無制限の再フェッチを防ぐため最小 30 秒のクールダウンを尊重）。

​

セラー検証チェックリスト

1. コンパクト JWS をパースする。不正なら拒否。
2. ヘッダー alg が none または許可リスト（EdDSA、ES256）にない場合拒否。ライブラリのデフォルトに頼ってはならない（MUST NOT）。
3. ヘッダー typ が正確に adcp-gov+jws でない場合拒否（正規化なし）。
4. ヘッダーが crit 配列を含み、リストされた名前が検証者に認識されない場合拒否。
5. 上記のディスカバリールールで iss を JWKS に解決する。JWKS がフェッチできない（SSRF 検証後）か 1 回の再フェッチ後に kid が存在しない場合拒否。
6. JWKS エントリの use が "sig" で key_ops が "verify" を含むことを検証。他の用途にマークされた鍵は拒否。
7. 署名を暗号学的に検証する。
8. aud が関連する adagents.json エントリで宣言されたセラー自身の正準 URL とバイト単位で等しくない場合拒否。
9. exp が過去、または iat が 60 秒より先の未来の場合拒否（±60 秒クロックスキュー許容、両境界で対称）。nbf が存在する場合、now < nbf − 60 s なら拒否。
10. sub がこのトークンが添付されているガバナンス呼び出しの plan_id と等しくない場合拒否（プランスワップを防ぐ）。
11. phase がオペレーションに一致しない場合拒否: create_media_buy には purchase、update_media_buy には modification、デリバリーレポートコールバックには delivery、intent はセラー前のバイヤー側評価のみ。
12. 非インテントトークンでは、media_buy_id がリクエストのメディアバイ ID と等しくない場合拒否。
13. クロスチェック: トークンの iss はバイヤーの現在の brand.json（Buyer identity resolution を介して確立）にガバナンス型エージェントとして現れなければならない（MUST）。セラーは妥当な TTL（1 時間推奨）で brand.json をキャッシュし、検証失敗時にリフレッシュすべき（SHOULD）。
14. 失効リスト（Revocation を参照）を確認する。jti ∈ revoked_jtis またはトークンヘッダーの kid ∈ revoked_kids なら拒否。このチェックはキャッシュミス時だけでなくすべての検証で実行される。
15. jti がこの (iss, aud) タプルで以前に見られている場合拒否。ストレージガイダンスは Replay dedup を参照。

​

リプレイ重複排除

• 実行トークンの exp を 30 日で上限（ガバナンスエージェントが強制。セラーはそれより長いものを拒否）。これは重複排除ウィンドウを制限します。
• 高速パスチェックとして小さな偽陽性率（約 100 万分の 1）の (iss, aud, jti) でキーされたブルームフィルターを使い、ブルームフィルターヒット時のみ制限されたストア（Redis SET jti NX EX <remaining_ttl>、TTL クリーンアップ付き Postgres 一意インデックス）で権威的ルックアップ。
• ガバナンスエージェントは、セラーが重複排除ストアを時間ウィンドウでパーティション化して期限切れパーティションを安価にドロップできるよう、jti 値を時間順序付け可能な形式（UUID v7 または ULID）で発行すべき（SHOULD）。

​

失効

{
  "payload": "<base64url of the JSON below>",
  "signatures": [
    { "protected": "<b64url header with kid, alg, typ=adcp-gov-revocation+jws>",
      "signature": "<b64url signature>" }
  ]
}

{
  "version": 1,
  "issuer": "https://gov.example.com",
  "updated": "2026-04-18T14:00:00Z",
  "next_update": "2026-04-18T14:15:00Z",
  "revoked_jtis": ["01HWZX..."],
  "revoked_kids": ["gov-2026-03"]
}

• revoked_jtis は個別の決定を無効にします（例: プランが撤回された）。失効は署名鍵に関わらずその jti を持つ任意のトークンに適用されます。
• revoked_kids はその kid の下で署名されたすべてのトークン（失効タイムスタンプの前後）を無効にします。発行後のトークンだけではありません。
• issuer はこのリストが規定するトークンの iss オリジンと一致しなければなりません（MUST）。共有 CDN による発行者をまたぐキャッシュ置換を防ぎます。
• リストは署名されているので、侵害された CDN や DNS オリジンが、侵害された鍵の失効を解除するために古いまたは改ざんされたリストを提供できません。

• セラーは next_update で宣言されたケイデンスでリストをポーリングしなければなりません（MUST）。
• フロア: 1 分。上限: 実行フェーズトークンを受け入れる任意のセラーで 30 分。ガバナンスエージェントは、実行フェーズトラフィックがカバーする発行者について next_update を 30 分より先の未来に宣言してはなりません（MUST NOT）。next_update 値は HTTP キャッシュヘッダーではなく JSON タイムスタンプです — 標準の HTTP キャッシュはそれを尊重しません。セラーは自分でそれをパースして守らなければなりません（MUST）。DoS 耐性より高速な鍵侵害伝播を優先するセラーはフロア付近でポーリングすべき（SHOULD）。上限は、より長い失効エンドポイント停止に耐えることと引き換えに遅い revoked_kids 伝播を受け入れるセラーのために存在します。
• ポーリングは、15 分以下の exp を持つインテントフェーズトークン（上記 JWT クレーム表からのインテントトークン exp 上限 — ポーリング上限とは別、数値が以前は一致していたが）では任意です。
• 不要なボディ転送を避けるため HTTP 条件付きリクエスト（If-Modified-Since / ETag）を使います。

• ガバナンスエージェントは、現在のローテーション後に監査人が履歴トークンを検証できるよう、失効した公開鍵を監査保持期間（7 年推奨）の間発見可能に保持しなければなりません（MUST）。失効した鍵は {origin}/.well-known/jwks-archive.json（アクティブ JWKS とは別）で提供すべきです（SHOULD）。

​

鍵ローテーション

• ガバナンスエージェントは、新しい kid を持つ新しい鍵を JWKS に追加し、新しい kid で新しいトークンに署名し、最も長命な未処理トークンが期限切れになるまで古い鍵を公開したままにしてローテーションします。
• セラー JWKS キャッシュは、拒否する前に missing-kid 失敗で無効化・再フェッチしなければなりません（MUST、無制限の再フェッチを防ぐため 30 秒クールダウン付き）。
• 緊急ローテーション（鍵侵害）は、古い kid を署名付き revoked_kids リストに追加し、即座に新しい鍵にローテーションして進みます。インテントトークンの短い exp、実行トークンの上限付き exp、失効リストポーリングが共に不正ウィンドウを制限します。

​

検証エラータクソノミー

​

プライバシー考慮事項

​

リファレンス実装

{
  "alg": "EdDSA",
  "kid": "gov-2026-04",
  "typ": "adcp-gov+jws"
}

{
  "iss": "https://gov.scope3.com",
  "sub": "plan_q1_2026_launch",
  "plan_hash": "EiCW8FkxgZ2wKqGv3Z9XuT4n2LwcJm1fK7vRaTpQ0sU",
  "aud": "https://seller.example.com/adcp",
  "iat": 1744934400,
  "exp": 1744935300,
  "jti": "01HWZXABCDEFG1234567890",
  "phase": "intent",
  "caller": "https://orchestrator.example.com",
  "check_id": "chk_001",
  "policy_decision_hash": "9b2a...f41c",
  "audit_log_pointer": "https://gov.scope3.com/plans/plan_q1_2026_launch/logs/01HWZXABCDEFG1234567890"
}

import { createRemoteJWKSet, decodeProtectedHeader, decodeJwt, jwtVerify } from "jose";

class GovTokenError extends Error {
  constructor(public code: string) { super(code); }
}

const jwksCache = new Map<string, ReturnType<typeof createRemoteJWKSet>>();
function jwksFor(jwksUri: string) {
  let jwks = jwksCache.get(jwksUri);
  if (!jwks) {
    // ssrfValidatedFetch enforces the Webhook URL validation rules on the JWKS URL
    jwks = createRemoteJWKSet(new URL(jwksUri), { cacheMaxAge: 15 * 60 * 1000, cooldownDuration: 30 * 1000, [Symbol.for("fetch")]: ssrfValidatedFetch });
    jwksCache.set(jwksUri, jwks);
  }
  return jwks;
}

export async function verifyGovernanceContext(token: string, ctx: {
  sellerId: string; planId: string; mediaBuyId?: string; phase: "intent" | "purchase" | "modification" | "delivery";
  resolveBrandJsonGovernanceAgent: (iss: string) => Promise<{ jwks_uri: string } | null>;
  seenJti: (iss: string, aud: string, jti: string) => Promise<boolean>;
  isRevoked: (iss: string, jti: string, kid: string) => Promise<boolean>;
  revocationFresh: (iss: string) => Promise<boolean>;
}) {
  const header = decodeProtectedHeader(token);
  if (header.typ !== "adcp-gov+jws") throw new GovTokenError("governance_token_invalid");
  if (!["EdDSA", "ES256"].includes(header.alg ?? "")) throw new GovTokenError("governance_token_invalid");
  const { iss } = decodeJwt(token);
  const agent = await ctx.resolveBrandJsonGovernanceAgent(iss as string);
  if (!agent) throw new GovTokenError("governance_issuer_not_authorized");

  const { payload } = await jwtVerify(token, jwksFor(agent.jwks_uri), {
    issuer: iss as string, audience: ctx.sellerId, typ: "adcp-gov+jws",
    algorithms: ["EdDSA", "ES256"], clockTolerance: 60,
  }).catch(() => { throw new GovTokenError("governance_token_invalid"); });

  if (payload.sub !== ctx.planId) throw new GovTokenError("governance_token_not_applicable");
  if (payload.phase !== ctx.phase) throw new GovTokenError("governance_token_not_applicable");
  if (ctx.phase !== "intent" && payload.media_buy_id !== ctx.mediaBuyId)
    throw new GovTokenError("governance_token_not_applicable");
  if (!(await ctx.revocationFresh(iss as string))) throw new GovTokenError("governance_revocation_stale");
  if (await ctx.isRevoked(iss as string, payload.jti as string, header.kid as string))
    throw new GovTokenError("governance_token_revoked");
  if (await ctx.seenJti(iss as string, ctx.sellerId, payload.jti as string))
    throw new GovTokenError("governance_token_replayed");
  return payload;
}

const JWS_COMPACT = /^[A-Za-z0-9_-]+\.[A-Za-z0-9_-]+\.[A-Za-z0-9_-]+$/;

function handleGovernanceContext(value: string, ctx) {
  persistOpaque(value); // always persist and forward for auditor use
  if (!JWS_COMPACT.test(value)) return; // pre-3.0 opaque value, nothing to verify
  return verifyGovernanceContext(value, ctx); // throws on any failure
}

​

移行（3.0 → 3.1）

• 3.0: ガバナンスエージェントは、必須の plan_hash 監査層クレーム（セマンティクスは Plan binding and audit を参照）を含め、このプロファイルに従ってコンパクト JWS を発行しなければなりません（MUST）。セラーは 15 ステップチェックリストを検証してもよい（MAY）。検証しないセラーはトークンを変更せずに永続化・転送しなければなりません（MUST）。JWS でない値は非推奨で、遷移中の pre-3.0 ガバナンスエージェントからのみ現れるべきです（SHOULD）。3.0 で非 JWS 値を発行するガバナンスエージェントは、セラーが検証不能なデプロイを検出できるよう、それをケイパビリティで宣言しなければなりません（MUST）。
• 3.1: すべてのセラーは 15 ステップチェックリストに従って検証しなければなりません（MUST）。ガバナンスエージェントは JWS を発行しなければなりません（MUST）。非 JWS 値はエンドツーエンドで拒否されます。plan_hash は監査層のまま（ガバナンスエージェント / 監査人 / バイヤーコンプライアンス検証のみ — セラー検証ではない）。

​

署名付きリクエスト（トランスポート層）

• エージェントは、オペレーターの brand.json の agents[] エントリの自身の jwks_uri で公開した鍵でリクエストに署名します。オペレーター（brand.json をホストするドメイン）は直接購入するハウスでも認可されたサードパーティでもよい — このプロファイルは区別しません。署名者は常にエージェントです。
• セラーは署名を署名エージェントの公開鍵に対して検証し、エージェントアイデンティティを確立します。次にセラーは別個のブランド-オペレーター認可チェック（このプロファイルのスコープ外）を実行します。
• エージェント側 AdCP エンドポイントを呼ぶセラー（例: それ自体が AdCP プロトコル呼び出しであるバイヤーホストの変更コールバック）は、アウトゴーイングリクエストに対称的に署名します。受信エージェントはセラーオペレーターの brand.json の agents[] エントリで公開されたセラーの鍵に対して検証します。プッシュ通知 Webhook コールバック（push_notification_config.url や類似の非同期一方向通知）は、このプロファイルの対称 Webhook callbacks バリアントでカバーされます — セラーは adcp_use: "request-signing" 鍵でアウトバウンド署名し（非推奨の "webhook-signing" 値も受け入れられる）、バイヤーが検証します。

• JWKS ディスカバリー、SSRF ルール、alg 許可リスト、失効セマンティクス、鍵ローテーションを上記の AdCP JWS profile と共有します。リクエスト検証は決して別の鍵目的を受け入れません: リクエスト署名 JWK は "adcp_use": "request-signing"、"use": "sig"、"key_ops": ["verify"]、および異なる adcp_use を持つ他の JWKS エントリに現れない kid を宣言しなければなりません（MUST）。検証者は 4 つすべてを強制します。Agent key publication を参照。Webhook パスは、Webhook tag がドメイン分離を提供するため独自の明示的な緩和を持ちます。
• ガバナンスの Buyer identity resolution のアイデンティティブートストラップ依存を解決します: リクエスト署名を検証するセラーは暗号学的に確立された署名エージェントアイデンティティを持ち、署名エージェントのオペレータードメインをガバナンス検証ステップの brand.json 解決入力として使ってもよい（MAY）。

• 署名の場所: HTTP レスポンスヘッダーではなく、レスポンスボディの中。
• 検証パス: レスポンスボディをパースし、次に JWS をエージェントの jwks_uri で公開された応答エージェントの response-signing JWK に対して検証 — トランスポートヘッダー上の RFC 9421 ベース再構築ではない。

• verify_brand_claim とそのバルクバリアント verify_brand_claims（Brand Protocol）。応答するブランドエージェントは、ブランドの adcp_use: "response-signing" 鍵の下で JWS エンベロープとしてレスポンスペイロードに署名します。署名は方向非対称の信頼モデルの要です — verify_brand_claim trust model と Building a brand agent — Signing setup を参照。

​

トランスポートスコープ

​

クイックスタート: 3.0 でリクエスト署名にオプトイン

0. ターゲットセラーで get_adcp_capabilities を呼び出す。request_signing.supported_for と required_for を読んで、セラーがあなたに署名を期待する AdCP オペレーションを確認し、request_signing.protocol_methods_supported_for / protocol_methods_required_for を読んで、セラーの検証者がカバーする JSON-RPC プロトコルメソッド（例: tasks/cancel）を確認する。covers_content_digest（"required" / "forbidden" / "either"）を読んで、content-digest をカバーしなければならない、してはならない、してもよいかを確認する。
1. Ed25519 鍵ペアを生成: openssl genpkey -algorithm ed25519 -out signing-key.pem。
2. 公開鍵を JWK としてエクスポート。"kid"、"use": "sig"、"key_ops": ["verify"]、"adcp_use": "request-signing"、"alg": "EdDSA" を追加。
3. JWK をエージェントの jwks_uri（brand.json の agents[] エントリで宣言された URL。エージェント URL のオリジンの /.well-known/jwks.json にデフォルト）で公開。
4. AdCP クライアントを秘密鍵とエージェント URL で設定。SDK は、セラーの supported_for または required_for ケイパビリティにリストされた任意のオペレーションと、protocol_methods_supported_for または protocol_methods_required_for にリストされた任意の JSON-RPC メソッドについて、セラーの covers_content_digest ポリシーを守って自動的にリクエストに署名する。SDK は、秘密鍵がプロセスメモリではなくマネージド鍵ストア（KMS / HSM / Vault）に存在できるよう、プラガブルな署名者をサポートすべき（SHOULD）— 下記の Production key storage を参照。
5. /compliance/latest/test-vectors/request-signing/ のコンフォーマンスベクター（AdCP バージョンごとに公開。ソースは static/compliance/source/test-vectors/request-signing/）でエンドツーエンド検証 — クライアントが正例ベクターの expected_signature_base に一致する署名を生成すれば完了。

1. get_adcp_capabilities で request_signing.supported: true を宣伝。パイロット中は required_for: [] のまま。相手方ごとに段階的にオペレーションを追加。
2. 変更系ルートで署名検証ミドルウェアを有効化。verifier checklist を実装 — 14 のチェックすべて（13 の番号付きステップとサブステップ 9a）、最初の失敗でショートサーキット。
3. required_for を設定する前に、パイロット相手方についてシャドウモード（検証してログ。失敗で拒否しない）で開始。最初の数週間は検証失敗をオペレーションではなくモニタリングで表面化。
4. 検証者に対してコンフォーマンス負例ベクターを実行 — 各拒否はベクターの記載された error_code を生成しなければならない（MUST）。ベクターの failed_step は情報的です。正しいエラーコードで拒否する実装は、内部ステップ番号が異なってもコンフォーマントです。

​

本番の鍵保管

• ほとんどの KMS API が返す ECDSA-P256 署名は DER エンコードです。このプロファイルと RFC 9421 §3.3.1 は IEEE P1363（r‖s、P-256 では 64 バイト）を要求します。アダプター境界で変換します。
• KMS 鍵を単一目的として扱います。このプロファイルの tag パラメーターは署名者ではなく検証者を保護します — 同じ KMS 鍵を AdCP リクエスト署名と他の任意の署名プロトコルに再利用するオペレーターは、クロスプロトコルオラクルを作ります。AdCP 署名パスのみが鍵を呼び出せるよう KMS アクセスポリシーをバインドします（GCP roles/cloudkms.signer を特定の cryptoKey にスコープ、AWS kms:Sign を鍵 ARN で条件付け）。

{
  "keys": [
    {
      "kty": "OKP", "crv": "Ed25519",
      "x": "SRYr8eSvjkZF6dAUquI1sKuU4YGZkoGH-2jwkz4dRJg",
      "kid": "acme-signing-2026-04",
      "alg": "EdDSA", "use": "sig",
      "adcp_use": "request-signing",
      "key_ops": ["verify"]
    },
    {
      "kty": "OKP", "crv": "Ed25519",
      "x": "lHJI-IvBwCE36heDNOyBmCk5UMKRIs4b4BAWJRgao-M",
      "kid": "acme-webhook-2026-04",
      "alg": "EdDSA", "use": "sig",
      "adcp_use": "request-signing",
      "key_ops": ["verify"]
    }
  ]
}

​

AdCP RFC 9421 プロファイル

1. 署名者はパディングなし base64url のみを発行しなければなりません（MUST）。+、/、= を含む Signature または Content-Digest 値を発行する署名者は非コンフォーマントです。
2. 検証者はパディングなし base64url を受け入れなければなりません（MUST）。検証者はこの明確化より前の相手方との相互運用のため、純粋な標準 base64 トークンも寛容にデコードすべきです（SHOULD、+→- 次に /→_ に変換、次に末尾 = を除去、次に base64url デコード）。この寛容は AdCP 3.2 で削除予定の互換性の便宜です — それに依拠する署名者はそれまでにパディングなし base64url に移行しなければなりません（MUST）。
3. 検証者は、アルファベットを混在させる任意のトークン（同じトークン値内の [+/=] 内の任意の文字 AND [-_] 内の任意の文字）を request_signature_header_malformed で拒否しなければなりません（MUST）。混在アルファベットトークンは曖昧です: A+B- は「標準 base64 文字を変換」と「base64url デコード」ステップの順序によって異なるバイトにデコードされ得、検証者間で異なる Content-Digest バイトは、攻撃者があるバリデーターが受け入れ別のが拒否するダイジェストミスマッチを仕込むことを許します。
4. コンフォーマンスベクターの expected_signature_base フィールドはバイナリ値エンコードから独立です — 正準署名ベースバイトを含み、ヘッダーフィールドエンコードではありません。発行される Signature トークン自体のみがエンコードされます。

​

エージェント鍵の公開

• governance-keys.{org}.example/.well-known/jwks.json — ガバナンス署名 JWK のみ
• keys.{org}.example/.well-known/jwks.json — リクエスト署名鍵（Webhook 専用 kid を含む）、後方互換性ウィンドウ中の非推奨 Webhook 署名鍵、TMP 鍵

1. 検証者は署名エージェントの URL をその brand.json の agents[] エントリに解決します。ディスカバリーは以前のオンボーディングから来てもよく（MAY）、レジストリキャッシュから来てもよい（MAY）が、正準のワイヤー上ブートストラップはエージェントの get_adcp_capabilities レスポンスの identity.brand_json_url フィールドです — Discovering an agent’s signing keys via brand_json_url を参照。
2. エージェントの jwks_uri（またはエージェントの url のオリジンの /.well-known/jwks.json にデフォルト）を Webhook URL validation に従う SSRF 検証付きでフェッチ。JWKS キャッシュ TTL は失効リストポーリング間隔で上限が制限される。
3. kid がキャッシュされた JWKS に不在の場合、JWKS を即座に再フェッチ（ステップ 2 の最初のフェッチはキャッシュされていたかもしれない）。同じ jwks_uri について過去 30 秒に再フェッチがすでに実行された場合、クールダウンが適用される: 検証者は再度再フェッチしてはならず（MUST NOT）、request_signature_key_unknown で拒否しなければならない（MUST）。クールダウンは再フェッチ間であり、最初のフェッチ前ではない。

​

brand_json_url を介したエージェントの署名鍵の発見

1. A の get_adcp_capabilities レスポンスを Webhook URL validation に従う SSRF 検証付きでフェッチ（HTTPS のみ — URL A は呼び出し元が供給し、Webhook コールバックに使う同じアドレスファミリー + プライベート IP フィルタリングを通らなければならない）。到達不能/タイムアウトでは request_signature_capabilities_unreachable で拒否。
2. identity.brand_json_url を読む。不在でリクエストが署名されている場合、request_signature_brand_json_url_missing で拒否。値が非 HTTPS の場合も同じコードで拒否（スキーマは ^https:// を強制するが、検証者はチェックを再表明しなければならない。不正な値を許容する 3.x パーサーは続行してはならない、MUST NOT）。required-when ルール: identity.brand_json_url は、エージェントが request_signing.supported_for/required_for を非空、webhook_signing.supported === true、または identity.key_origins の下の任意のフィールドを宣言するとき存在しなければならない（MUST）。これは 3.x でストーリーボード強制。4.0 ではレスポンスが 4.x リリースを含む supported_versions を宣言するときスキーマ必須になる。クロスバージョン検証者（4.x サポートを宣伝しない 3.x エージェントと通信する 4.0）は不在の identity.brand_json_url を受け入れ続けなければならない（MUST）。
3. オリジンバインディング。 エージェント URL A のホスト eTLD+1 は brand_json_url のホスト eTLD+1 と等しくなければならない（MUST）。eTLD+1 計算はピン留めされた日付付き Public Suffix List スナップショットを使わなければならない（MUST、vercel.app, pages.dev, github.io のようなプラットフォームがサフィックスとして扱われるよう ICANN+PRIVATE セクション両方をスコープ）。異なる PSL バージョンを実行する 2 つの検証者は互いに非コンフォーマント。eTLD+1 が不一致の場合、brand.json をフェッチして authorized_operators[] が A の eTLD+1 をリストすることを確認。どちらも成立しなければ request_signature_brand_origin_mismatch で拒否。これは、攻撃者が attacker.example/mcp にエージェントを立て、その brand_json_url を、たまたま正当に attacker.example/mcp をリストする無関係なオペレーターの brand.json（例: SaaS マルチテナントデプロイ）に向ける共有テナントスプーフィングベクトルを閉じる。
4. brand_json_url の brand.json を Webhook URL validation に従う SSRF 検証付きでフェッチ。検証者はこのフェッチでリダイレクトに従ってはならない（MUST NOT、このプロファイルの他所で文書化された authoritative_location の単一リダイレクト切り出しはそのフィールドにスコープされ、brand.json ブートストラップに継承されてはならない）。推奨予算: 接続 5 秒、総デッドライン 10 秒、ボディ上限 256 KiB。成功フェッチのキャッシュ TTL は JWKS 失効ポーリング間隔で上限が制限されなければならない（MUST、鍵ローテーションが古い brand.json でマスクされないように）。負のレスポンス（404、ネットワーク失敗）は 60 秒以上キャッシュされてはならない（MUST NOT）— 誤設定を修正するオペレーターが完全な失効サイクルの間ロックアウトされてはならない。
5. url が A とバイト等価な agents[] エントリを見つける（このステップで正準化なし — ガバナンス JWS の iss-to-brand.json 一致と同じルール、Buyer identity resolution を参照。最も一般的な失敗モードは末尾スラッシュまたはスキーム不一致、例: https://x.com/mcp ≠ https://x.com/mcp/）。一致しなければ request_signature_agent_not_in_brand_json で拒否。複数一致する場合（オペレーター誤設定 — brand.json スキーマは現在 agents[] を URL 一意に制約しない）、request_signature_brand_json_ambiguous で拒否。
6. JWKS ソースを署名面 AND 役割（adcp_use だけでなく送信者 vs 受信者の位置）で解決:
   • セルサイド Webhook 配信のみ — すなわち、セラーがメディアバイ配信についてバイヤーへのアウトバウンド Webhook に署名: パブリッシャーの adagents.json signing_keys ピン（存在する場合）は上記のパブリッシャーピン優先順位ルールに従って権威的で、下記のすべてを上書きする。ピンは（エージェント、Webhook 配信面、セルサイド役割）にスコープされる — オペレーター側 Webhook 配信（例: オペレーターステータスコールバックを受け取るバイヤーホストの Webhook）を上書きせず、別個の adcp_use: "webhook-signing" 鍵目的を示唆しない。
   • 他のすべての（面、役割）タプル — リクエスト署名（任意の方向）、オペレーター側 Webhook 配信、ガバナンス署名、TMP 署名: 一致した agents[] エントリの jwks_uri を使い、不在時は A のオリジンの /.well-known/jwks.json にデフォルト。
7. identity.key_origins 一貫性チェック（署名時は必須）。 ケイパビリティレスポンスの identity.key_origins の下で宣言され、ステップ 6 での JWKS ソースがオペレーター brand.json だった（すなわち、パブリッシャー adagents.json signing_keys ピンでない）すべての面/目的について、解決された jwks_uri のホストはその面/目的について宣言されたオリジンと等しくなければならない（MUST）。任意の面/目的での不一致 → { purpose, expected_origin, actual_origin } を運ぶ request_signature_key_origin_mismatch で拒否。ソースがパブリッシャーピンだった特定の（エージェント、面/役割）タプルについてのみチェックをスキップ — 同じ面のオペレーター側使用は依然チェック。エージェントが対応する identity.key_origins.{purpose} エントリなしに署名を宣言する場合、{ purpose, posture } を運ぶ request_signature_key_origin_missing で拒否。
8. JWKS をフェッチ、kid を見つけ、既存の RFC 9421 プロファイル（verifier checklist のステップ 7 以降）に従って検証。

クイックスタート: brand_json_url ベースの検証者を実装

1. 署名エージェントの URL A のケイパビリティをフェッチ。これはプロトコルレベル呼び出し — A に対する生の HTTP GET ではなく、エージェントの宣言されたトランスポート（MCP tools/call または A2A スキル呼び出し）を介して get_adcp_capabilities を呼び出す。エージェント URL は JSON ケイパビリティドキュメントではなくプロトコルエンドポイント。Webhook URL validation に従う SSRF セーフトランスポートを使う: HTTPS のみ、アドレスファミリー + プライベート IP フィルタリング、リダイレクトなし、予算 { connect: 5000, total: 10000, body: MAX_CAPABILITIES_BYTES, maxRedirects: 0 }。
2. identity.brand_json_url を読む。 不在（かつリクエストが署名済み）または非 HTTPS なら request_signature_brand_json_url_missing で拒否。
3. eTLD+1 オリジンバインディング。 ピン留め PSL スナップショットを使って eTLD+1(A) と eTLD+1(brand_json_url) を計算。ベンダー済みの日付付きスナップショットで tldts（TS）、publicsuffixlist（Python）、または golang.org/x/net/publicsuffix（Go）を使う。ランタイムで PSL をフェッチしない — ランタイムフェッチは DoS オラクルとデプロイ間で非決定論的な eTLD+1 を作る。一致すれば続行。そうでなければ brand.json をフェッチして authorized_operators[] を確認 — eTLD+1(A) が委任されていれば続行。そうでなければ request_signature_brand_origin_mismatch で拒否。このアルゴリズム全体のオリジン比較は両側を正準化しなければならない（MUST）: ホストを ASCII 小文字化し、バイト等価前に IDNA-2008 A-label 形式（Punycode）に変換。非正準比較（例: 生の Example.COM vs example.com、または U-label vs A-label）は正当なトラフィックを黙って拒否する。
4. 同じ SSRF ルール + リダイレクトなし、ボディ上限 MAX_BRAND_JSON_BYTES、接続 5 秒、総 10 秒で brand.json をフェッチ。重複キーを拒否する strict JSON パーサー（例: TS の secure-json-parse、重複で raise する object_pairs_hook 付きの Python stdlib json.JSONDecoder、Go の重複キーチェックと組み合わせた encoding/json Decoder.DisallowUnknownFields）でパース — 重複キーはステップ 14 がリクエスト面で閉じるパーサー差分ベクトルで、同じトラストルートドキュメントが検証者間で 2 つの異なる形状にパースされてはならない（MUST NOT）。重複キー検出で request_signature_brand_json_malformed で拒否。成功レスポンスを JWKS 失効ポーリング間隔まで（それより長くない）キャッシュ。失敗は最大 60 秒キャッシュ。
5. url が A とバイト等価な agents[] エントリを見つける（正準化なし）。ミスで request_signature_agent_not_in_brand_json、複数一致で request_signature_brand_json_ambiguous を拒否。
6. 一致したエントリから jwks_uri を解決 — セルサイド Webhook 配信のみ、オペレーターの jwks_uri よりパブリッシャーの adagents.json signing_keys ピン（存在する場合）を優先。他のすべての（面、役割）タプルは、一致したエントリの jwks_uri（デフォルト: A のオリジンの /.well-known/jwks.json）を使う。
7. 一貫性チェック。 ケイパビリティ identity.key_origins の下で宣言されたすべての面/目的について、解決された jwks_uri ホストと宣言オリジンの両方に canonicalizeOrigin()（ASCII 小文字 + IDNA-2008 A-label）を適用し、バイト比較（パブリッシャーピン由来の特定の（エージェント、面/役割）タプルのみスキップ）。適宜 request_signature_key_origin_mismatch / _missing を拒否。
8. verifier checklist のステップ 8 以降にハンドオフ — JWKS をフェッチ（同じバイト予算 MAX_JWKS_BYTES と 5/10 秒の接続/総デッドライン）、kid を見つけ（ここでステップ 7 のプリアンブルですでに解決済み — 検証者チェックリストのステップ 7 はディスカバリープリアンブル自体）、RFC 9421 に従って検証。

const MAX_CAPABILITIES_BYTES = 65_536;
const MAX_BRAND_JSON_BYTES   = 262_144;
const MAX_JWKS_BYTES         = 65_536;
const FETCH_BUDGETS          = { connect: 5_000, total: 10_000, maxRedirects: 0 };

function canonicalizeOrigin(hostOrUrl: string): string {
  const host = hostOrUrl.includes('://') ? new URL(hostOrUrl).hostname : hostOrUrl;
  return toAsciiIdna2008(host.toLowerCase());                                 // A-label form
}

async function resolveAgent(agentUrl: string): Promise<AgentResolution> {
  const caps = await getAdcpCapabilities(agentUrl, {                          // step 1: protocol-level call
    ...FETCH_BUDGETS, body: MAX_CAPABILITIES_BYTES, ssrf: true,
  });
  const brandJsonUrl = caps.identity?.brand_json_url;
  if (!brandJsonUrl?.startsWith('https://')) throw new Err('brand_json_url_missing');  // step 2
  const agentEtld1 = etldPlusOne(new URL(agentUrl).hostname, PINNED_PSL_SNAPSHOT);     // step 3
  const brandEtld1 = etldPlusOne(new URL(brandJsonUrl).hostname, PINNED_PSL_SNAPSHOT);
  const brandJson = await safeFetch(brandJsonUrl, {                            // step 4
    ...FETCH_BUDGETS, body: MAX_BRAND_JSON_BYTES, ssrf: true, parse: 'strict-json',
  });
  if (agentEtld1 !== brandEtld1
      && !brandJson.authorized_operators?.some(o => o.domain === agentEtld1)) {
    throw new Err('brand_origin_mismatch');
  }
  const entries = brandJson.agents.filter(e => e.url === agentUrl);            // step 5 (byte-equal)
  if (entries.length === 0) throw new Err('agent_not_in_brand_json');
  if (entries.length > 1) throw new Err('brand_json_ambiguous');
  const entry = entries[0];
  const jwksUri = entry.jwks_uri ?? `${origin(agentUrl)}/.well-known/jwks.json`;  // step 6
  for (const [purpose, declared] of Object.entries(caps.identity?.key_origins ?? {})) { // step 7
    if (canonicalizeOrigin(jwksUri) !== canonicalizeOrigin(declared)) {
      throw new Err('key_origin_mismatch', { purpose });
    }
  }
  const jwks = await safeFetch(jwksUri, {                                      // step 8 setup
    ...FETCH_BUDGETS, body: MAX_JWKS_BYTES, ssrf: true, parse: 'strict-json',
  });
  return { agentUrl, brandJsonUrl, agentEntry: entry, jwksUri, jwks, /* trace, freshness */ };
}

リファレンス実装

• TypeScript（@adcp/sdk）: resolveAgent(url) は { agentUrl, brandJsonUrl, agentEntry, jwksUri, jwks, identityPosture, consistency, freshness, trace } を返す。getAgentJwks(url) は JWKS のみの高速パス。createAgentJwksSet(url, opts) は jose の jwtVerify に渡す JWTVerifyGetKey を返す。
• Python（adcp）: resolve_agent(url) は agent_url, brand_json_url, agent_entry, jwks_uri, jwks, identity_posture, consistency, freshness, trace フィールドを持つ AgentResolution データクラスを返す。verify_request_signature(request, *, agent_url, allowed_algs) はディスカバリーチェーンと verifier checklist を 1 呼び出しで実行するワンショットヘルパー。
• Go（adcp-go）: ResolveAgent(ctx, agentURL) (*AgentResolution, error) は AgentURL, BrandJSONURL, AgentEntry, JWKSUri, JWKS, IdentityPosture, Consistency, Freshness, Trace フィールドを持つ構造体を返す。VerifyRequestSignature(ctx, req, opts) (*VerifiedIdentity, error) は TS/Python のワンショットをミラー。

​

エージェントアイデンティティ

​

検証者チェックリスト（リクエスト）

• オペレーションが検証者の required_for ケイパビリティにあり、AND Signature-Input ヘッダーが存在せず、AND 呼び出し元がこのオペレーションについて検証者が受け入れる他のクレデンシャル（bearer、API キー、mTLS）を提示しない場合、request_signature_required で拒否。このブランチに入る未署名リクエストは決してチェックリストに入りません。未署名だが他の方法で認証された呼び出し元を規定するルールは Composition with fallback authenticators を参照。
• Signature または Signature-Input のどちらかが他方なしに存在する場合、request_signature_header_malformed で拒否。2 つのヘッダーはバインドされたペアです。一方が他方なしは不正で、「推測できる欠けた部分で署名された」ではありません。このルールは、プロキシが Signature-Input を除去し Signature を残すダウングレードベクトルを閉じます。
• Signature-Input ヘッダーが存在するが不正な場合、request_signature_header_malformed で拒否。検証者は、不正な署名が存在するとき、required_for にないオペレーションでも、bearer のみの認証にフォールバックしてはなりません（MUST NOT）— 存在するが壊れた署名は署名者の意図を示します。黙ったフォールバックはダウングレード攻撃を可能にします。

1. Signature-Input と Signature ヘッダーを RFC 9421 §4 に従ってパース。不正なら拒否。
2. created, expires, nonce, keyid, alg, tag のいずれかが Signature-Input パラメーターから不在なら拒否（request_signature_params_incomplete）。
3. tag が正確に adcp/request-signing/v1 でないなら拒否（request_signature_tag_invalid）。
4. alg が許可リスト（ed25519, ecdsa-p256-sha256）にないなら拒否。ライブラリのデフォルトに頼ってはならない（request_signature_alg_not_allowed）。
5. expires ≤ created、created > now + 60 s、expires < now − 60 s、または expires − created > 300 s なら拒否（request_signature_window_invalid）。
6. カバーされるコンポーネントが @method, @target-uri, @authority のすべてを含まないなら拒否（request_signature_components_incomplete）。ボディが存在する場合、content-type がカバーされていないなら拒否。検証者の covers_content_digest ケイパビリティが "required" なら、content-digest がカバーされていないなら拒否。検証者の covers_content_digest ケイパビリティが "forbidden" かつ content-digest がカバーされているなら、request_signature_components_unexpected で拒否。
7. keyid を Agent key publication を介して JWK に解決。検証者が署名エージェントのキャッシュされたエージェント → JWKS マッピングを持たない場合、このステップの前に Discovering an agent’s signing keys via brand_json_url を実行 — その 8 ステッププリアンブル（ケイパビリティ → identity.brand_json_url → brand.json → agents[] → jwks_uri）は keyid 解決の前提条件で、そのセクションの request_signature_brand_* と request_signature_key_origin_* コードでショートサーキット。確立されたマッピング内の kid ミスでは、request_signature_key_unknown で拒否する前に 1 回再フェッチ（再フェッチ間の 30 秒クールダウンに従う）。keyid が特定の agents[] エントリに解決できないなら拒否。
8. JWK の use が "sig"、key_ops が "verify" を含み、adcp_use が "request-signing" に等しいことを検証。任意の不一致（不在の adcp_use を含む。非コンフォーマントとして扱わなければならない）で拒否（request_signature_key_purpose_invalid）。
9. Transport revocation リストを確認。keyid ∈ revoked_kids なら拒否（request_signature_key_revoked）。検証者が grace 内に失効リストをリフレッシュしていないなら request_signature_revocation_stale で拒否。 9a. keyid ごとの上限チェック。 keyid ごとのリプレイキャッシュ上限を確認。この keyid について上限に達しているなら request_signature_rate_abuse で拒否。暗号検証（ステップ 10）の前に実行 — ステップ 9 と同じ根拠: 上限を枯渇させる侵害されたまたは誤設定された署名者が、増幅された Ed25519/ECDSA 作業を検証者に強制してはならない（MUST NOT）。keyid 解決（ステップ 7）の後に実行し、上限状態オラクルが検証者がすでに認識をコミットした鍵についてのみ応答するように — 9a を早く実行すると、攻撃者が JWKS に公開されていない keyid を含む全 keyid 空間で検証者内部のレート制限状態を探れる。
10. 上記のプロファイルに従い @target-uri 正準化 AND @authority 導出を適用した後、カバーされるコンポーネントを使って RFC 9421 §2.5 に従い正準署名ベースを計算。@authority ルールは要: 検証者は、存在する場合 HTTP/2+ の :authority 疑似ヘッダーから、そうでなければ受信した HTTP/1.1 Host ヘッダーから @authority を導出しなければならない（MUST）— リバースプロキシルーティング状態、ロードバランサーメタデータ、フォワードプロキシが転送中に書き換えた任意の Host 値からではない。受信リクエストに :authority と Host の両方が存在する場合、正準化後にバイト等価でなければならない（RFC 7540 §8.1.2.3 等価性）。発散は request_target_uri_malformed で拒否。正準化された @authority は正準 @target-uri のオーソリティコンポーネントとバイト単位で一致しなければならない（MUST）。ミスマッチは request_target_uri_malformed で拒否。署名済み @target-uri に対するそのバイト一致 — ソースヘッダーの選択ではなく — が唯一の安全ゲートです。Host 自体が転送中に書き換えられ得るからです。このチェックリストだけから — プロファイルの正準化セクションを相互参照せずに — 構築する実装者はこのルールを適用しなければならない（MUST）。それをスキップするとクロス vhost リプレイベクトル（攻撃者が TLS 終端されたリクエストを傍受し、同じ検証者プール上の 2 つ目の vhost にリプレイ: 同じ証明書 SAN、異なる Host）を黙って受け入れる。正準化完了後、JWK に対して署名を検証（失敗で request_signature_invalid）。
11. content-digest がカバーされている場合、受信したボディバイトからダイジェストを再計算して比較（ミスマッチで request_signature_digest_mismatch）。
12. リプレイキャッシュに対してノンスを確認（Transport replay dedup を参照）。(keyid, nonce) がリプレイキャッシュ TTL 内で見られている場合拒否（request_signature_replayed）。
13. ステップ 1-9、9a、10-12 がすべて通過した後にのみ、(keyid, nonce) を TTL = (expires − now) + 60 s（+60 秒はステップ 5 で適用したスキュー許容に一致）でリプレイキャッシュに挿入。この挿入はステップ 14 のボディ整形式チェックの前に発生しなければならない（MUST）。不正なボディ上に有効な署名を運ぶキャプチャされたフレームが、各リトライで暗号検証 CPU を燃やすためにリプレイできないように — ノンスは、ボディ形状に関わらず、暗号学的に有効なフレームの最初の目撃で燃やされる。
14. ボディ整形式性。 検証者は重複オブジェクトキーを含むボディを拒否しなければならない（MUST、request_body_malformed）。RFC 8259 §4 に従い、重複キーパース動作は予測不能 — 署名はワイヤー上のバイトに対して有効だが、2 つのパーサーがパースされた値について一致しないことがあり、これはパーサー差分攻撃クラス（cf. CVE-2017-12635）。このチェックは、署名検証者のペイロードのビューとダウンストリームコンシューマーのビューの間のギャップを閉じる。リクエストボディは、パーサー差分の影響範囲が Webhook のステータスフリップの影響範囲より大きい状態変更・支出コミットペイロード（create_media_buy, update_media_buy_delivery など）を運び、このチェックを少なくとも Webhook 面と同じくらい要にする。request_body_malformed は request_signature_digest_mismatch とは別: 署名は有効。ボディが曖昧な状態にパースされる。構造化 request_body_malformed エラーを返すのではなくクラッシュする検証者はコンフォーマントだが最適でない — 送信者は actionable なエラーコードを受け取らない。Idempotency_key カバレッジはこのチェックから従う: ステップ 14 はスキーマ検証と冪等性キャッシュルックアップ（idempotency を参照）の前に実行されるので、idempotency_key 自体が重複する（異なるパーサーが異なるキーを見る）リクエストボディはここで拒否され、決してキャッシュに到達しない。別個の冪等性層監査は不要。 14a. Strict-parse 要件。 チェックは重複キーを露出するパーサーを使わなければならない（MUST）— それらを黙って破棄する last-wins/first-wins のデフォルトはこの要件を満たさない。Webhook 検証者チェックリストのステップ 14aの言語ごとの strict-parse エスケープハッチ列挙がここに同一に適用される。 14b. ロギング規律。 検証者は request_body_malformed 拒否で完全なリクエストボディバイトをログすべきではない（SHOULD NOT）。keyid、ノンス、バイト長、特定の重複キー名のみをログ。Webhook 検証者チェックリストのステップ 14bのキー名サニタイズルール（最初の非印字文字で <sanitized:N> に切り詰め、32 バイト以下の最後の UTF-8 コードポイントに切り詰め、数を 4 で上限）がここに同一に適用される — 攻撃者制御バイトチャネルはリクエスト面で同じ形状を持つ。

​

フォールバック認証器との合成

• required_for オペレーションへの未認証リクエストは request_signature_required で拒否しなければなりません（MUST）。
• required_for オペレーションへの未署名だが他の方法で認証されたリクエスト（有効な bearer、API キー、mTLS アイデンティティ。Signature-Input なし）は、署名欠落で拒否してはなりません（MUST NOT）。フォールバッククレデンシャルは検証者がその呼び出し元に十分と宣伝したもので、required_for は検証者自身の認証器設定を遡及的に無効化しません。
• 署名済みリクエストは verifier checklist に入り、オペレーションが required_for にあるかに関わらず暗号学的メリットで評価されます。
• 不正な署名は、チェックリストプリアンブルの不正署名ルールに従い、フォールバックをとにかくブロックします。壊れた署名は署名者の意図を示し、bearer に黙ってダウングレードしてはなりません（MUST NOT）。

​

Content-digest とプロキシ互換性

​

トランスポートリプレイ重複排除

• 各エントリの TTL = ウィンドウ検証で適用した対称クロックスキュー許容に一致する (expires − now) + 60 s。典型的な TTL ≤ 360 秒（5 分 + 60 秒スキュー）。
• TTL 退避付きの (keyid, nonce) でキーされたインメモリ LRU、期待リクエストレート × 最大署名有効性でサイズ。
• 署名者ごとに約 10K req/秒を超える場合: EX = remaining_validity_seconds + 60 の Redis SETNX。
• 分散検証者（マルチリージョン）: リージョンごとのリプレイキャッシュは許容。これが可能にする唯一の攻撃はリージョンをまたぐ (expires − now + 60 s) 内の単一リプレイで、約 6 分に制限され、攻撃者が中間ルーティングを制御する場合のみ有効。

​

トランスポート失効

• revoked_kids はその kid の下で署名されたすべてのリクエスト（失効タイムスタンプの前後）を無効にします。
• revoked_jtis は使われません（リクエスト署名は jti を持たず、ノンスの一意性は鍵ごと）。

​

トランスポートケイパビリティ宣伝

{
  "request_signing": {
    "supported": true,
    "covers_content_digest": "either",
    "required_for": [],
    "warn_for": ["create_media_buy"],
    "supported_for": [
      "create_media_buy",
      "update_media_buy",
      "sync_creatives",
      "activate_signal"
    ]
  }
}

• supported: true のとき、検証者は存在するとき署名を検証。false または不在のとき、署名は無視される。
• covers_content_digest: "required", "forbidden", "either"（デフォルト）のいずれか。"required": 署名者は content-digest をカバーしなければならない。ボディ非署名の署名は拒否。"forbidden": 署名者は content-digest をカバーしてはならない。ボディバインド署名は拒否。"either": 署名者が選択。検証者は両方を受け入れ。
• required_for: 他の有効なクレデンシャルを提示しない未署名リクエストが request_signature_required で拒否される AdCP プロトコルオペレーション名（トランスポート固有でない）。3.0 ではデフォルトで空。署名者はリストされた任意のオペレーションに署名しなければならない（MUST）。bearer、API キー、mTLS フォールバックとの合成は Composition with fallback authenticators が規定 — 特に、有効なフォールバッククレデンシャルを提示する未署名リクエストは受け入れられ、署名を無条件にしたいセラーはそのオペレーションで他のクレデンシャルタイプを拒否するようフォールバック認証器を設定しなければならない（MUST）。
• warn_for: 検証者が存在するとき署名を検証し、失敗をモニタリングでログするが、拒否しないオペレーション。supported_for から required_for へのシャドウモードブリッジとして使用。セラーが強制前に実トラフィック失敗率を見る相手方ごとのパイロットを可能にする。優先順位: required_for > warn_for > supported_for。署名者は warn_for のオペレーションに署名すべき（SHOULD）。検証者はこれらのオペレーションへの未署名または検証失敗リクエストを拒否してはならない（MUST NOT）。
• supported_for: 署名が存在するとき検証されるが必須でないオペレーション。署名者はこれらに署名すべき（SHOULD）。通常 required_for と warn_for のスーパーセット。

1. 署名準備を発表: オペレーションを supported_for に追加。相手方は署名を開始できるが、しなくても何も変わらない。
2. シャドウモードに昇格: オペレーションを warn_for に移す。検証者は検証失敗をログ。トラフィックは影響なし。オペレーターは失敗率を監視してデバッグ。
3. 強制: 失敗率がオペレーターの閾値を下回ったら required_for に移す。そのオペレーションへの未署名または無効署名リクエストは今拒否される。

​

トランスポートエラータクソノミー

​

Webhook コールバック

{
  "webhook_signing": {
    "supported": true,
    "profile": "adcp/webhook-signing/v1",
    "algorithms": ["ed25519", "ecdsa-p256-sha256"],
    "legacy_hmac_fallback": false
  }
}

• supported: セラーがケイパビリティ面の他所で変更系 Webhook 発行を宣伝するとき true でなければならない（MUST）。バイヤーは supported: false またはブロック欠落でセラー面が Webhook 発行を宣伝するときオンボーディングを拒否。Webhook を発行しないセラーはブロック全体を省略すべき（SHOULD）。
• profile: このプロファイルバージョンでは正確に adcp/webhook-signing/v1 でなければならない（MUST）。将来のプロファイルバージョンは文字列をバンプ。
• algorithms: ["ed25519", "ecdsa-p256-sha256"] のサブセット — このセラーが署名するアルゴリズムセット。Webhook 署名検証者許可リストに一致。宣伝された algorithms 配列がこのセット外の任意の値を含む場合、バイヤーはユーザーが対処可能なエラーでオンボーディングを拒否しなければならない（MUST）。セット外アルゴリズムは誤設定または非コンフォーマントなセラーを示し、黙った受け入れは許可リストを無効にする。
• legacy_hmac_fallback: バイヤーが push_notification_config.authentication.credentials または accounts[].notification_configs[].authentication.credentials を設定するときセラーがレガシー HMAC-SHA256 スキームをサポートする場合に限り true。false が 3.x の推奨姿勢。

非推奨: adcp_use: "webhook-signing" は非推奨で将来のメジャーバージョンで削除予定（#5555 で追跡。正確なウィンドウは WG/RFC 決定）。検証者は後方互換性のためそれを依然受け入れなければならない（MUST、"webhook-signing" 鍵の下で署名された Webhook はクリーンに検証される）が、新しい署名者は "request-signing" 鍵のみで公開・署名すべき（SHOULD）。

1. セラーエージェント URL A → A のオペレータードメインの /.well-known/brand.json を Webhook URL validation に従う SSRF 検証付きでフェッチ。brand.json 解決は 1 リダイレクト（authoritative_location または house リダイレクトバリアント）に従って停止。
2. フェッチした brand.json で、url が A とバイト単位で一致する agents[] エントリを見つける。
3. そのエントリの jwks_uri（または A のオリジンの /.well-known/jwks.json にデフォルト）を SSRF 検証付きでフェッチ。JWKS キャッシュ TTL は失効リストポーリング間隔（フロア 1 分、上限 30 分）で上限が制限される。長時間実行のタスクフローは JWKS ローテーションをまたぐ。検証者はタスクの寿命の間単一の JWKS スナップショットをピン留めしてはならない（MUST NOT）。
4. インカミング Signature-Input の keyid をフェッチしたセットの JWK に解決。kid ミスでは、webhook_signature_key_unknown で拒否する前に 1 回再フェッチ（再フェッチ間の 30 秒クールダウンに従う）。ミス時再フェッチパスはタスク中の鍵ローテーションを扱う要のメカニズム — それをスキップするクライアントは正当なローテーション後配信を拒否する。

• セラーは非空 authentication ブロックで到着するすべてのリクエストをログしなければなりません（MUST）。 予期しない HMAC 選択へのオペレーションアラームは、バイヤーが 9421 を得ていると思ったときにバイヤー側を保護します。
• リクエスト署名をサポートするセラーは、push_notification_config.authentication または任意の accounts[].notification_configs[].authentication に authentication が存在するとき、インバウンドリクエストが（request verifier checklist に従って）9421 署名されることを要求しなければならず（MUST）、request_signature_required（required_for オペレーションに使うのと同じコード — Transport error taxonomy を参照）で拒否します。署名済みリクエストがボディに暗号学的にコミットするとき、authentication ブロックは署名も無効化せずに注入または除去できません。リクエスト署名を全くサポートしないセラーはこのルールを強制する方法がなく、前の項目の log-and-alarm 姿勢にフォールバックします — 3.0 移行注記であり免除ではない: request-signing migration timeline は 4.0 で支出コミットオペレーションにリクエスト署名を必須にし、その時点で未署名のみのセラーはなくなります。
• バイヤーは、authentication.credentials で登録した後に 9421 署名済み Webhook を受け取ったとき、または authentication なしで登録した後に HMAC 署名済み Webhook を受け取ったとき、黙ってダウングレードするのではなく webhook_mode_mismatch で拒否してアラームしなければなりません（MUST）。 拒否が安全特性です。アラームはテレメトリ — アラームするがペイロードを受け入れるバイヤーは、すでにミスマッチした署名スキームに権限を渡しています。拒否は安定エラーコード付きの HTTP 401 として表面化し、送信者側のリトライロジックが同一にリプレイするのではなくインシデントレスポンスにルーティングできます。
• バイヤーは、9421 をまだ実装していないセラーと相互運用するとき、オンボーディングで HMAC モードを帯域外で交渉すべきです（SHOULD）。 オペレーターレコードでの耐久性のある相手方ごとのモード選択は、リクエストごとのフィールドのように MITM 変更可能ではありません。

1. Signature-Input と Signature ヘッダーを RFC 9421 §4 に従ってパース。不正なら拒否（webhook_signature_header_malformed）。Signature または Signature-Input が他方なしに存在する場合、同じコードで拒否 — 推測可能でなくバインドされたペア。
2. created, expires, nonce, keyid, alg, tag のいずれかが Signature-Input パラメーターから不在なら拒否（webhook_signature_params_incomplete）。
3. tag が正確に adcp/webhook-signing/v1 でないなら拒否（webhook_signature_tag_invalid）。バイト単位一致、ケースフォールディングなし。
4. alg が許可リスト（ed25519, ecdsa-p256-sha256）にないなら拒否。ライブラリのデフォルトに頼ってはならない（webhook_signature_alg_not_allowed）。
5. expires ≤ created、created > now + 60 s、expires < now − 60 s、または expires − created > 300 s なら拒否（webhook_signature_window_invalid）。
6. カバーされるコンポーネントが @method, @target-uri, @authority, content-type, content-digest のすべてを含まないなら拒否（webhook_signature_components_incomplete）。content-digest は REQUIRED。ポリシーブランチはない。
7. 上記の JWKS ディスカバリーステップで keyid を JWK に解決。kid ミスでは、拒否（webhook_signature_key_unknown）前に 1 回再フェッチ（再フェッチ間 30 秒クールダウン）。keyid が署名者の brand.json の特定の agents[] エントリに解決できないなら拒否。
8. JWK の use が "sig"、key_ops が "verify" を含み、adcp_use が "request-signing" であることを検証 — Webhook はエージェントのリクエスト署名鍵で署名される（Key publication を参照）。非推奨の "webhook-signing" 値も後方互換性のため受け入れなければならない（MUST）。他の任意の結果で webhook_signature_key_purpose_invalid で拒否: 不在の adcp_use、欠落した verify key_op、他の任意の adcp_use 値（例: "response-signing", "governance-signing"）。ここで "request-signing" を受け入れるのは安全です。クロスプロトコル混同が鍵目的判別子ではなく tag（ステップ 3）と必須の content-digest カバレッジ（ステップ 6）で防がれるからです: キャプチャされたリクエスト署名は tag=adcp/request-signing/v1 を運びステップ 3 で拒否されます。（webhook_mode_mismatch は HMAC-vs-9421 認証モードセレクターミスマッチに予約 — Downgrade and injection resistance を参照 — で鍵目的失敗には使われません。）
9. Transport revocation リスト（署名目的をまたいで再利用）を確認。keyid ∈ revoked_kids なら拒否（webhook_signature_key_revoked）。検証者が grace 内にリフレッシュしていないなら webhook_signature_revocation_stale で拒否。 9a. keyid ごとの上限チェック。 Webhook リプレイキャッシュ上限を確認。超過なら webhook_signature_rate_abuse で拒否。リクエスト署名と同じ安価な拒否の根拠で、暗号検証（ステップ 10）の前に実行。
10. リクエスト署名プロファイルに従い @target-uri 正準化 AND @authority 導出を適用した後、カバーされるコンポーネントを使って RFC 9421 §2.5 に従い正準署名ベースを計算。@authority ルールは Webhook セキュリティの要: 検証者は、存在する場合 HTTP/2+ の :authority 疑似ヘッダーから、そうでなければ受信した HTTP/1.1 Host ヘッダーから @authority を導出しなければならない（MUST）— リバースプロキシルーティング状態、ロードバランサーメタデータ、フォワードプロキシが転送中に書き換えた任意の Host 値からではない。受信リクエストに :authority と Host の両方が存在する場合、正準化後にバイト等価でなければならない（RFC 7540 §8.1.2.3 等価性）。発散は webhook_target_uri_malformed で拒否。正準化された @authority は正準 @target-uri のオーソリティコンポーネントとバイト単位で一致しなければならない（MUST）。ミスマッチは webhook_target_uri_malformed で拒否。署名済み @target-uri に対するそのバイト一致 — ソースヘッダーの選択ではなく — が唯一の安全ゲート。Host 自体が転送中に書き換えられ得るから。このチェックリストだけから — プロファイルを相互参照せずに — 構築する実装者はこのルールを適用しなければならない（MUST）。それをスキップするとクロス vhost リプレイベクトル（攻撃者が TLS 終端された Webhook を傍受し、同じ検証者プール上の 2 つ目の vhost にリプレイ: 同じ証明書 SAN、異なる Host）を黙って受け入れる。正準化完了後、JWK に対して署名を検証（失敗で webhook_signature_invalid）。
11. 受信したボディバイトから content-digest を再計算して比較（ミスマッチで webhook_signature_digest_mismatch）。REQUIRED — ポリシーブランチなし。
12. リプレイキャッシュに対してノンスを確認。(keyid, nonce) がリプレイキャッシュ TTL 内で見られている場合拒否（webhook_signature_replayed）。
13. ステップ 1-12 がすべて通過した後にのみ、(keyid, nonce) を TTL = (expires − now) + 60 s でリプレイキャッシュに挿入。この挿入はステップ 14 のボディ整形式チェックの前に発生しなければならない（MUST）。不正なボディ上に有効な署名を運ぶキャプチャされたフレームが各リトライで暗号検証 CPU を燃やすためにリプレイできないように — ノンスはボディ形状に関わらず暗号学的に有効なフレームの最初の目撃で燃やされる。この順序が保持する要となる上限不変条件はステップ 14b の後に文書化。
14. ボディ整形式性。 検証者は重複オブジェクトキーを含むボディを拒否しなければならない（MUST、webhook_body_malformed）。RFC 8259 §4 に従い、重複キーパース動作は予測不能 — 署名はワイヤー上のバイトに対して有効だが、2 つのパーサーがパースされた値について一致しないことがあり、これはパーサー差分攻撃クラス（cf. CVE-2017-12635）。このチェックは、署名検証者のペイロードのビューとダウンストリームコンシューマーのビューの間のギャップを閉じる。構造化 webhook_body_malformed エラーを返すのではなくクラッシュする検証者はコンフォーマントだが最適でない。このチェックのコンフォーマンスフィクスチャは static/test-vectors/webhook-hmac-sha256.json の duplicate-keys-conflicting-values ベクター — 9421 プロファイルは署名検証成功後に同じボディ整形式ルールを適用しなければならない（MUST）。webhook_body_malformed は webhook_signature_digest_mismatch とは別: 署名は有効。ボディが曖昧な状態にパースされる。 14a. Strict-parse 要件。 チェックは重複キーを露出するパーサーを使わなければならない（MUST）— それらを黙って破棄する last-wins/first-wins のデフォルトはこの要件を満たさない。「安全」または「厳格」とマーケティングされても、重複キー入力で衝突を表面化せずに値を返すクエリライブラリもこの要件を満たさない（cf. Go の tidwall/gjson — バリデーターではなくクエリライブラリ）。言語ごとの strict-parse エスケープハッチ、正準の非網羅リスト:
    • Python: stdlib json.loads(..., object_pairs_hook=...) — フック内で重複を検出して raise。チェックを満たす。
    • Node: JSON.parse に strict モードなし。重複キーイベントハンドラー付きのストリーミングパーサー（stream-json, jsonparse）を使う。secure-json-parse はデフォルトで不十分: その保護はプロトタイプ汚染キー（__proto__, constructor）を標的とし、データキー重複ではない（依然 last-wins で畳み込む）。データキー重複を明示的に拒否するよう設定するか、下にストリーミングパーサーを重ねる。
    • Go: encoding/json に strict モードなし、重複を検出しない。オブジェクトスコープごとの明示的な map[string]struct{} 一意キーガード付きの json.Decoder トークンウォーク、OR 明示的に有効化した decoder.DisallowDuplicateKey() 付きの goccy/go-json（デフォルトではない）を使う。このチェックに tidwall/gjson を使ってはならない — 衝突をシグナルせずに重複キー入力で最後の値を返すクエリライブラリ。
    • Java: Jackson DeserializationFeature.FAIL_ON_READING_DUP_TREE_KEY（デフォルト無効、明示的に有効化）。
    • Ruby: stdlib JSON.parse に検出フックなし。allow_nan: false / 重複拒否オプションを明示的に設定した Oj.load(..., mode: :strict) を使う。
    14b. ロギング規律。 検証者は webhook_body_malformed 拒否で完全なリクエストボディバイトをログすべきではない（SHOULD NOT）。keyid、ノンス、バイト長、特定の重複キー名のみをログ。侵害された署名者鍵を保持する攻撃者は、さもなくば攻撃者が選んだバイトを大規模に防御者のログに強制でき、フレームごとにリプレイキャッシュスロットを燃やしつつ、SIEM ポイズニングや認証情報流出のフォローオン攻撃のための攻撃者制御のログトレイルを残せます。重複キー名をログするとき、検証者は各名前を順に適用される次のルールでサニタイズしなければなりません（MUST）:
    • (a) 最初の非印字コードポイントで切り詰め、N が切り詰めプレフィックスのバイト長である <sanitized:N> を発行。これは位置情報を省く（キー名内の非印字文字の配置は、さもなくばそれ自体がビット位置としてエンコード可能な攻撃者チャネル）一方、「ここで何かが間違っていた」という診断シグナルを保持。非印字セットは少なくとも次を含まなければならない（MUST）: C0 制御（U+0000–U+001F）、DEL（U+007F）、C1 制御（U+0080–U+009F、マルチバイト形式でのターミナル制御セマンティクス）、bidi 制御と分離子（U+200E, U+200F, U+202A–U+202E, U+2066–U+2069 — ターミナルと SIEM UI での逆レンダリング）、行と段落の分離子（U+2028, U+2029 — 多くのログビューアで改行としてレンダリングされ行注入を可能にする）、ゼロ幅文字（U+200B–U+200D — 不可視難読化）、バイトオーダーマーク（U+FEFF — パーサー破損）。実装はセットをより広い Unicode 非印字分類に拡張してもよい（MAY）が、狭めてはならない（MUST NOT）— ASCII のみのチェックは、このルールが閉じるログ注入チャネルをまさに再び開く bidi オーバーライドと行分離子攻撃を見逃す。
    • (b) 最後の完全な UTF-8 コードポイント境界で最大 32 バイトに切り詰め。現実的な AdCP フィールド名はおよそ 24 文字（signed_authorized_agents）が上限なので、32 は寛大な上限でありつつ攻撃者制御バイト面を制限。切り詰めは 32 バイト以下の最後の完全な UTF-8 コードポイント境界で発生しなければならない（MUST）。マルチバイトシーケンスがコードポイント中間で分割されず、無効な UTF-8 がログに落ちないように（同じ入力を異なる無効 UTF-8 末尾に切り詰める異なる検証者もログ集約を壊す）。
    • (c) 拒否ごとにログされる重複キー名の数を 4 で上限、超過なら <...N more> を発行。4 vs 8 vs 16 の衝突キーを知る診断価値はほぼゼロ。
    これらの制約なしでは、キー名チャネルは攻撃者制御バイトサイドチャネルのまま — 完全ボディロギングより小さいが非ゼロで、ログ注入ベクトルとしてよく前例がある。上流入力の拒否をログする署名者（重複オブジェクトキー署名者側ルールを参照）は、署名者側エラー出力で表面化する任意のキー名に同じ (a)/(b)/(c) サニタイズルールを適用しなければならない（MUST）。ワイヤー方向が逆でもチャネル形状は同一。

Webhook リプレイ重複排除のサイジング

• keyid ごとのエントリ上限: 推奨 100,000 エントリ（リクエスト側 1,000,000 上限の 10 分の 1）。6 分ウィンドウで 100K の一意 Webhook を発行するセラーは単一署名者から 275/秒持続 — 通常オペレーションに十分な余裕でありつつ、誤設定または鍵侵害の強いシグナル。
• 集約キャッシュ上限: すべての署名者にわたって推奨 min(aggregate_memory_budget, 10,000,000) エントリ。集約上限超過で、検証者は新しい署名を webhook_signature_rate_abuse で拒否しなければならず（MUST）、オペレーターにアラートすべき（SHOULD）— 黙った退避はまさに検証者が攻撃下にあるときにリプレイウィンドウを作る。
• セラーごとの予算: オペレーターは、すべてのセラーを各 100K で等重み付けするのではなく、統合の重要度でセラーごとに予算すべき（SHOULD）。支出コミットセラーの Webhook ファンインはディスカバリーのみのセラーのそれとは異なる。
• 新規 keyid 認可プレッシャー（MUST 追跡、SHOULD アラート）。検証者は単位時間あたりに以前に見たことのない keyid から認められるキャッシュエントリのレート（例: 最初のエントリを挿入する別個の keyid の 5 分ローリングカウント）を追跡しなければならない（MUST）。新規 keyid 認可レートの急なスパイクは分散侵害攻撃のシグネチャです: N 個の侵害された署名者鍵を保持する攻撃者は、各鍵が keyid ごとの上限（ステップ 9a）内に十分収まりつつ、集合的に集約キャッシュを飽和させ、TTL ウィンドウごとに各鍵 N エントリを駆動できます。各鍵のトラフィックは個別には低ボリュームの正当な署名者に見えます。集約形状がシグナルです。 検証者は、新規 keyid 認可が 4 つの閾値のいずれか（最初にトリガーするもの）を超えたときアラートすべきで（SHOULD）、各々が別個の攻撃者パターンを閉じます:
  • (a) 現在の認可レートを短期地平の移動平均ベースラインと比較する短ウィンドウ比率閾値 — 安定ベースラインに対する急なスパイクを捕捉。
  • (b) 中期地平パーセンタイルベースラインに対する中ウィンドウ比率閾値 — その地平でトラフィックがベースライン末尾に支配される数週間のランプアップ攻撃を捕捉。
  • (c) 長期地平パーセンタイルベースラインに対する長ウィンドウ比率閾値 — 中期地平アンカーを自らとともにドリフトさせる数ヶ月のランプアップ攻撃を捕捉。
  • (d) 絶対フロアと文書化されたウィンドウにわたる一意 keyid カウントの一部を組み合わせた比例上限 — 比率ベースラインがゼロ近くのスパーストラフィック検証者を捕捉し、AND 任意のサイズのオペレーターに自動スケール（小さな検証者は低い比例フロアを得、エンタープライズ検証者は比例的に大きいものを得る）。
  4 つのカテゴリは規範的。具体的な閾値はそうではない。 オペレーターは任意の公開された例値を出発点として扱い、自身のトラフィックをベースライン化し、それに応じて調整しなければなりません（MUST）— 公開された規範閾値数は攻撃者に検出姿勢へのオラクルを渡します。具体的な開始値、ベースライン化方法論、攻撃シナリオウォークスルーは非規範的な Webhook Verifier Tuning Guide で公開されています。実装はガイドの開始値を初回デプロイデフォルトとして出荷してもよい（MAY）が、各閾値を調整可能な設定パラメーター（例: 環境変数、設定ファイル）として公開しなければなりません（MUST）— ハードコードされた開始値は事実上オペレーター可視のデフォルトになり攻撃者オラクルを再導入します。実装は、任意の閾値が検証者の最初の認可より 30 日を超えて出荷開始値のままであるとき threshold_tuning_overdue イベントをログまたはアラームすべきです（SHOULD）。これはオペレーター調整義務に、オペレーターの勤勉さだけに頼るのではなくテスト可能・監査可能なフックを与えます。 アラームペイロードは、オペレーターのトリアージが正しい脅威形状に応答できるよう、どの節（a、b、c、d）がトリップしたかを名指さなければなりません（MUST）。ここでのアラームは、集約上限がトリガーする前にスローバーン分散侵害パターンを捕捉します — 集約上限で webhook_signature_rate_abuse が発火すると、キャッシュはすでに満杯で、すべての正当な署名者が拒否されています。アラームは自動失効ではなくインシデントレスポンスにルーティングすべきです（SHOULD）: 「攻撃」と「新しいセラーのバッチをオンボーディング」の区別シグナルはオペレーターコンテキストで、マシン導出可能ではなく、アラームでの自動失効は DoS ベクトルを作ります（正当な新規署名者オンボーディングを駆動する任意の当事者がアラームをトリップして大量失効を引き起こせる）。

1. ある署名者が到達できるすべてのエンドポイントにわたって単一の論理リプレイキャッシュを共有（Redis / 共有重複排除サービス — プロセスごとインメモリではない）。エンドポイント A が挿入した (keyid, nonce) がステップ 12 実行前にエンドポイント B に見えるように。または
2. 正準宛先 URL をリプレイキーに含める、重複排除を (keyid, canonical destination URL, nonce) にスコープ。正準形は リクエスト署名プロファイルに従う正規化後の @target-uri（スキーム小文字、ホスト IDNA 正規化、デフォルトポート省略、フラグメント除去）。

Webhook の失効とローテーション

Webhook エラータクソノミー

Webhook 移行タイムライン

​

TMP クロスリファレンス

• ガバナンス JWS — adcp_use: "governance-signing"
• リクエスト署名（RFC 9421）— adcp_use: "request-signing"（Webhook にも署名。Webhook callbacks を参照）
• Webhook 署名（RFC 9421）— request-signing 鍵を使用。レガシー adcp_use: "webhook-signing" 値は非推奨（依然受け入れ、削除保留 — 非推奨注記のフォローアップイシューを参照）
• 指定タスクレスポンスペイロード JWS — adcp_use: "response-signing"（上記の Designated-task payload-envelope response signing を参照）
• TMP エンベロープ — TMP 独自の将来の adcp_use 値

​

トランスポート移行タイムライン

​

リクエスト検証者リファレンス（TypeScript）

import { createRemoteJWKSet } from "jose";

class RequestSignatureError extends Error {
  constructor(public code: string) { super(code); }
}

const ALLOWED_ALGS = new Set(["ed25519", "ecdsa-p256-sha256"]);
const REQUIRED_TAG = "adcp/request-signing/v1";
const REQUIRED_COMPONENTS = new Set(["@method", "@target-uri", "@authority"]);
const REQUIRED_PARAMS = ["created", "expires", "nonce", "keyid", "alg", "tag"] as const;

export async function verifyAdcpRequestSignature(req: Request, ctx: {
  operationName: string;
  requiredFor: Set<string>;
  contentDigestPolicy: "required" | "forbidden" | "either";
  resolveJwk: (keyid: string) => Promise<{ jwk: unknown; agentUrl: string }>; // throws _key_unknown after refetch
  isKeyRevoked: (keyid: string) => Promise<boolean>;
  isRevocationStale: () => Promise<boolean>;
  isKeyidAtCapacity: (keyid: string) => Promise<boolean>;
  isReplayed: (keyid: string, nonce: string) => Promise<boolean>;
  recordNonce: (keyid: string, nonce: string, ttlSeconds: number) => Promise<void>;
  verify9421: (req: Request, jwk: unknown, covered: string[]) => Promise<void>; // throws on signature or digest failure
  parseSignatureInput: (header: string) => {
    keyid?: string; alg?: string; created?: number; expires?: number;
    nonce?: string; tag?: string; components: string[];
  };
}) {
  const sigInput = req.headers.get("signature-input");

  // Pre-check: required_for / downgrade protection.
  if (!sigInput) {
    if (ctx.requiredFor.has(ctx.operationName)) throw new RequestSignatureError("request_signature_required");
    return; // operation doesn't require a signature; verify nothing.
  }

  let parsed;
  try { parsed = ctx.parseSignatureInput(sigInput); }
  catch { throw new RequestSignatureError("request_signature_header_malformed"); }

  // 2: presence
  for (const p of REQUIRED_PARAMS) {
    if ((parsed as any)[p] == null) throw new RequestSignatureError("request_signature_params_incomplete");
  }
  // 3: tag
  if (parsed.tag !== REQUIRED_TAG) throw new RequestSignatureError("request_signature_tag_invalid");
  // 4: alg
  if (!ALLOWED_ALGS.has(parsed.alg!)) throw new RequestSignatureError("request_signature_alg_not_allowed");
  // 5: window (including expires > created)
  const now = Math.floor(Date.now() / 1000);
  if (parsed.expires! <= parsed.created! ||
      parsed.created! > now + 60 ||
      parsed.expires! < now - 60 ||
      parsed.expires! - parsed.created! > 300) {
    throw new RequestSignatureError("request_signature_window_invalid");
  }
  // 6: components
  for (const c of REQUIRED_COMPONENTS) {
    if (!parsed.components.includes(c)) throw new RequestSignatureError("request_signature_components_incomplete");
  }
  const coversCd = parsed.components.includes("content-digest");
  if (ctx.contentDigestPolicy === "required" && !coversCd) {
    throw new RequestSignatureError("request_signature_components_incomplete");
  }
  if (ctx.contentDigestPolicy === "forbidden" && coversCd) {
    throw new RequestSignatureError("request_signature_components_unexpected");
  }
  // 7: JWK resolution
  const { jwk } = await ctx.resolveJwk(parsed.keyid!); // throws _key_unknown
  // 8: key purpose
  const j = jwk as any;
  if (j.use !== "sig" || !Array.isArray(j.key_ops) || !j.key_ops.includes("verify") || j.example_use !== "request-signing") {
    throw new RequestSignatureError("request_signature_key_purpose_invalid");
  }
  // 9: revocation (BEFORE crypto verify)
  if (await ctx.isRevocationStale()) throw new RequestSignatureError("request_signature_revocation_stale");
  if (await ctx.isKeyRevoked(parsed.keyid!)) throw new RequestSignatureError("request_signature_key_revoked");
  // 9a: per-keyid cap (BEFORE crypto verify) — prevents amplified crypto work by abusive/misconfigured signer.
  if (await ctx.isKeyidAtCapacity(parsed.keyid!)) {
    throw new RequestSignatureError("request_signature_rate_abuse");
  }
  // 10 + 11: crypto verify, content-digest recompute — both inside verify9421.
  try { await ctx.verify9421(req, jwk, parsed.components); }
  catch (e: any) {
    if (e?.code === "digest_mismatch") throw new RequestSignatureError("request_signature_digest_mismatch");
    throw new RequestSignatureError("request_signature_invalid");
  }
  // 12: replay check
  if (await ctx.isReplayed(parsed.keyid!, parsed.nonce!)) {
    throw new RequestSignatureError("request_signature_replayed");
  }
  // 13: replay insert (only after all checks pass)
  await ctx.recordNonce(parsed.keyid!, parsed.nonce!, (parsed.expires! - now) + 60);
}

​

予算検証

async function validateBudget(request, account) {
  const { budget } = request;

  // Check positive amount
  if (budget.amount <= 0) {
    throw new ValidationError('Budget must be positive');
  }

  // Check against account limits
  const limits = await getAccountLimits(account.account_id);
  if (budget.amount > limits.daily_spend_limit) {
    throw new BudgetError('Exceeds daily spend limit');
  }

  // Check available balance
  const balance = await getAvailableBalance(account.account_id);
  if (budget.amount > balance) {
    throw new BudgetError('Insufficient balance');
  }
}

​

トランスポートセキュリティ

​

TLS バージョンポリシー

• TLS 1.3 がすべての AdCP エンドポイントで RECOMMENDED。
• TLS 1.2 が最小。 エンドポイントはハンドシェイクで TLS 1.1 以下を拒否しなければなりません（MUST）。
• クライアント側検証者（例: 相手方の JWKS、brand.json、失効リストをフェッチする AdCP サーバー）は TLS 1.2 未満をネゴシエートすることを拒否しなければなりません（MUST）。「互換性」のため依然 TLS 1.0 をデフォルトとするライブラリは明示的に設定されなければなりません（MUST）。
• SSL 2.0、SSL 3.0、TLS 1.0、TLS 1.1 は有効化してはなりません（MUST NOT）— どのエンドポイントでも、どのレガシーパートナーでも、別のポートでも。

​

暗号スイートとアルゴリズム

• TLS 1.3: IETF 定義スイート（TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256）を使います。3 つとも AEAD。他の TLS 1.3 スイートは存在しません。それらを恣意的に無効化しないでください — 「速度」を理由に ChaCha20 を無効化するオペレーターは、1 つのクライアントの癖でモバイルクライアントを壊す寸前です。
• TLS 1.2: AEAD のみの ECDHE スイートに制限。許可セットは ECDHE-ECDSA-AES128-GCM-SHA256, ECDHE-ECDSA-AES256-GCM-SHA384, ECDHE-ECDSA-CHACHA20-POLY1305, ECDHE-RSA-AES128-GCM-SHA256, ECDHE-RSA-AES256-GCM-SHA384, ECDHE-RSA-CHACHA20-POLY1305。
• CBC-MAC、RC4、3DES、DES、NULL、EXPORT、匿名 DH、静的 RSA 鍵交換スイートは TLS 1.2 で無効化されなければなりません（MUST）— その存在はハンドシェイクの上に構築されたすべてのセキュリティ特性を黙って格下げします。
• サーバー証明書は ECDSA（P-256 または P-384）または RSA ≥ 2048 ビットを使わなければなりません（MUST）。RSA < 2048 は使ってはなりません（MUST NOT）。
• エンドポイントはサーバー側暗号順序（OpenSSL SSL_OP_CIPHER_SERVER_PREFERENCE、nginx ssl_prefer_server_ciphers on）を優先しなければなりません（MUST）。強いスイートが相互に利用可能なとき、弱いクライアントが弱いスイートを強制できないように。

​

証明書検証（アウトバウンドフェッチ）

• トラストチェーンはオペレーターが意図的に含めたパブリックルートで終端しなければなりません（MUST）。本番コードパスのどこにも --insecure、verify=False、rejectUnauthorized: false なし。これは単独で最も一般的な本番侵害です — エンジニアがステージングの証明書問題を回避するため検証を切り、そのフラグが出荷される。
• SAN 一致が権威的なアイデンティティチェックです。証明書は URL ホストに一致する Subject Alternative Name エントリを持たなければなりません（MUST）。CN のみのフォールバックは受け入れてはなりません（MUST NOT）。主要な HTTP クライアントはレガシーの理由で依然それをサポートしますが、AdCP 検証者は SAN を要求しなければなりません（MUST）。
• 有効期限は現在のクロックに対してチェックされなければなりません（MUST）。TLS 証明書が先週期限切れになったドメインから JWKS をフェッチすることは、互換性問題ではなくガバナンスのレッドフラグです。
• ホスト名検証はライブラリ設定で有効化されなければなりません（MUST）。いくつかの人気の HTTP クライアントライブラリはホスト名検証をデフォルトでオンにして出荷しますが、驚くほど多くがそれを無効にするフラグを持ちます。AdCP 実装はホスト名検証がオンであることを仮定するのではなくアサートしなければなりません（MUST）。
• OCSP ステープリングは提供されたとき受け入れるべきです（SHOULD）。オペレーター制御の証明書での OCSP must-staple は RECOMMENDED。Must-staple は欠落したステープルをハード失敗に変え、OCSP でのソフト失敗の抜け穴を閉じます。
• Certificate Transparency（CT） SCT は規制された支出を提供するエンドポイントでチェックされるべきです（SHOULD）。ブラウザはすでに CT を強制します。規制カテゴリのワークフローでガバナンス JWKS をフェッチする AdCP SDK もそうすべきで（SHOULD）、隠された誤発行証明書が検出可能に。
• ピン留めはプロトコル層で必須ではなく、正当なオペレーター証明書ローテーションと衝突するため相手方が供給する URL（brand.json、JWKS）では避けるべきです（SHOULD）。パブリック CA チェーンへのピン留め（中間ピン）は許容。特定のリーフ証明書へのピン留めは非推奨。

​

インバウンドサーバー側ヘッダー

app.use((req, res, next) => {
  // HSTS: 1 year, include subdomains, preload-eligible. MUST be on every HTTPS response.
  res.setHeader('Strict-Transport-Security', 'max-age=31536000; includeSubDomains; preload');

  // No framing of AdCP API responses — even though they're JSON, frame isolation
  // protects any error or debug HTML that could leak through.
  res.setHeader('X-Frame-Options', 'DENY');

  // MIME sniffing off: responses declare their type, clients MUST respect it.
  res.setHeader('X-Content-Type-Options', 'nosniff');

  // Prevent referrers leaking to external URLs supplied by counterparties.
  res.setHeader('Referrer-Policy', 'no-referrer');

  // AdCP endpoints serve no browser-facing HTML — block script-source loading outright.
  // If your operator reuses the same origin for a dashboard, adjust this per-path.
  res.setHeader('Content-Security-Policy', "default-src 'none'; frame-ancestors 'none'");

  next();
});

​

クライアント / アウトバウンド TLS ハードニング

• ホストごとの固定上限と全体の固定上限を持つ接続プールを使う。無制限のプールはリソース枯渇面。
• TLS ハンドシェイク時間をデフォルトで 10 秒、総リクエスト時間を 30 秒で上限 — 相手方が供給する URL はさもなくばタールピット DoS ベクトル。
• 接続を SSRF 制御を通過した IP アドレスにピン留め — SSRF チェックと実際の接続の間の DNS 再解決が TOCTOU バイパスが着地する方法。
• セキュリティ機微なフェッチでリダイレクトを拒否。JWKS、brand.json、失効リスト、Webhook コールバックのフェッチはリダイレクトに従ってはならず（MUST NOT）、brand.json 解決ルールはすでに「1 リダイレクト（authoritative_location または house バリアント）、チェーンなし」と述べ、初回の /.well-known/adagents.json フェッチは同一登録可能ドメインリダイレクトのみに従う（apex↔www、HTTPS 保持、3 ホップ以下、最初に要求されたドメインに固定）— 他のすべての場所ではゼロ。adagents.json の authoritative_location 参照は「他のすべての場所」: ゼロリダイレクト。
• 信頼境界をまたぐセッション再開を無効化。攻撃者制御の相手方との TLS セッションを後の検証済み相手方（DNS リバインド経由の同じ IP）に再開することはよく知られた混同のクラス。ライブラリのデフォルトは通常問題ないが、オペレーターは監査しなければなりません（MUST）。

​

TLS 再ネゴシエーションとダウングレード

• TLS 1.2 のセキュア再ネゴシエーション（RFC 5746）は、再ネゴシエーションがサポートされる場合有効化されなければなりません（MUST）。非セキュア再ネゴシエーション許容スタックは MUST-disable。
• TLS 圧縮（CRIME）はオフでなければなりません（MUST）。
• Heartbeat 拡張は TLS 1.2 エンドポイントでオフでなければなりません（MUST、Heartbleed 系統）。
• TLS 1.3 の 0-RTT / early-data は、変更系 AdCP オペレーションを受け入れる任意のエンドポイントで有効化してはなりません（MUST NOT）。0-RTT は設計上リプレイ可能です。冪等性と署名ノンス重複排除は、リクエストがアプリケーションロジックに到達した後は無料の救済ではありません。読み取り専用ディスカバリーエンドポイント（get_adcp_capabilities, list_creative_formats）は 0-RTT を使ってもよい（MAY）。他のすべては使ってはなりません（MUST NOT）。

​

mTLS トランスポート

• クライアント証明書 SAN / Subject は、adagents.json または brand.json で宣言されたバイヤーの登録済みドメインに一致しなければなりません（MUST）。任意のヘッダーフィールド（X-Forwarded-Client-Cert, X-Client-DN など）に頼ることは明示的に禁止されています — ヘッダーフィールドは誤設定プロキシをまたいで注入され得ます。
• 終端エッジ（ロードバランサー、メッシュサイドカー）は、検証済み証明書アイデンティティを、サーバーが認証できるクラスタ内チャネルで AdCP サーバーに転送しなければなりません（MUST）。未認証のサイドカーヘッダーはバイパス — mTLS をエンドツーエンドでデプロイするか、クラスタ内チャネルをピン留めします。
• クライアント証明書はオペレーターが運用する CRL または OCSP レスポンダーに対してチェックされなければなりません（MUST）。「私たちが発行した」は「まだ有効」と同じではありません。

​

プライベートネットワークとメタデータ保護

​

このセクションが置き換えないもの

• アプリケーション層のボディ完全性（リクエスト署名と Webhook コールバック）— TLS はワイヤーを保護し、侵害された中間者後のペイロードは保護しません。
• ガバナンス証明（署名付きガバナンスコンテキスト）— TLS は、バイヤーのガバナンスエージェントがこの支出を認可したかをセラーに伝えません。
• 冪等性（Request Safety）— TLS は、送信者がネットワークタイムアウト後にリトライするのを防ぎません。

​

入力検証

​

リクエスト検証

const INPUT_LIMITS = {
  targeting_brief_max_length: 5000,
  creative_upload_max_size: 100 * 1024 * 1024, // 100MB
  max_formats_per_request: 50,
  max_products_per_query: 100
};

function validateRequest(request) {
  // Check string lengths
  if (request.brief?.length > INPUT_LIMITS.targeting_brief_max_length) {
    throw new ValidationError('Brief exceeds maximum length');
  }

  // Validate IDs are proper UUIDs
  if (request.product_id && !isValidUUID(request.product_id)) {
    throw new ValidationError('Invalid product_id format');
  }

  // Reject unexpected fields
  const allowedFields = ['brief', 'product_id', 'budget', 'context_id'];
  for (const field of Object.keys(request)) {
    if (!allowedFields.includes(field)) {
      throw new ValidationError(`Unexpected field: ${field}`);
    }
  }
}

​

SQL インジェクション防止

// GOOD: Parameterized query (request-supplied account_id after auth precheck)
const result = await db.query(
  'SELECT * FROM media_buys WHERE id = $1 AND account_id = $2',
  [mediaBuyId, request.account.account_id]
);

// BAD: String concatenation (NEVER do this)
// const result = await db.query(
//   `SELECT * FROM media_buys WHERE id = '${mediaBuyId}'`
// );