> ## Documentation Index > Fetch the complete documentation index at: https://adcp-docs-ja.pier1.co.jp/llms.txt > Use this file to discover all available pages before exploring further. # TMP 仕様 > Trusted Match Protocol の権威あるメッセージタイプ定義、フィールド表、プライバシー要件、適合性レベル。 # Trusted Match Protocol 仕様 **実験的。** Trusted Match Protocol は実験的サーフェスとして AdCP 3.0 の一部です — 少なくとも 6 週間の予告をもって 3.x リリース間で変わることがあります。TMP を実装するセラーは `experimental_features` に `trusted_match.core` を宣言しなければなりません（MUST）。完全なコントラクトについては [実験的ステータス](/docs/reference/experimental-status) を参照。このサーフェスのフィールドは 3.0.0 GA まで非推奨サイクルの対象になりません。 これは Trusted Match Protocol（TMP）の権威あるリファレンスです。概念的な導入については、[概要](/docs/trusted-match/) と [コアコンセプト](/docs/trusted-match/context-and-identity) を参照。 進化が予想される特定の領域には、TMPX 露出トークン、国分割アイデンティティ、Offer マクロが含まれます — 計画された変更については [3.1.0 ロードマップ](https://github.com/adcontextprotocol/adcp/issues/2201) を参照。 ## Definitions | Term | Definition | | -------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Context Match** | 利用可能なパッケージをコンテンツコンテキストに対して評価する TMP 操作。ユーザーアイデンティティを運ばない。 | | **Identity Match** | ユーザー適格性をパッケージ基準に対して評価する TMP 操作。ページコンテキストを運ばない。 | | **TMP Router** | TMP リクエストをバイヤーエージェントにファンアウトしレスポンスをマージするインフラ。コンテキストとアイデンティティの両リクエストを、構造的に分離されたコードパスで扱う単一のバイナリ。 | | **Offer** | context match リクエストへのバイヤーの応答。シンプルなアクティベーション（package\_id のみ）から、ブランド、価格、summary、クリエイティブマニフェストを伴うリッチな提案まで及ぶ。 | | **Available package** | 特定のプレースメントで評価に適格な、アクティブなメディアバイからのパッケージ。パッケージメタデータ（発信元セラーエージェントを含む）はメディアバイ時に同期される。[Package Sync](#package-sync) を参照。 | | **Seller agent** | パッケージをパブリッシャーに販売したバイヤー側のエージェント。パブリッシャーの `adagents.json` `authorized_agents[].url` で宣言されたエージェント URL によって識別される。すべての `AvailablePackage` は同期時に正確に 1 つのセラーエージェントにバインドされる。 | | **Eligibility** | Identity Match が返す適格なパッケージ ID のリストと、サーブウィンドウスロットル。バイヤーはフリークエンシーキャップ、オーディエンスメンバーシップ、その他のシグナルから適格性を計算する。理由はパブリッシャーにとって不透明。 | | **Artifact** | パブリッシャープロパティに関連付けられた型付きコンテンツ参照（記事 URL、エピソード EIDR、番組 Gracenote ID、音楽 ISRC、プロダクト GTIN、会話ターン）。各アーティファクトは `type` と `value` を持つ。context match リクエストで参照される。 | | **Temporal decorrelation** | Context Match と Identity Match リクエスト間のランダムな遅延とランダムな順序で、タイミングと順序ベースの相関を防ぐ。 | ## Message Types すべての TMP メッセージタイプは、デシリアライゼーションのためにメッセージを識別する `type` フィールドを含みます。ルーターとエージェントはこのフィールドを使って JSON ボディをパースする正しいスキーマを選択します。 | Message | `type` value | | ----------------------- | ------------------------- | | Context Match request | `context_match_request` | | Context Match response | `context_match_response` | | Identity Match request | `identity_match_request` | | Identity Match response | `identity_match_response` | | Error response | `error` | ### ContextMatchRequest パブリッシャー（ルーター経由）からバイヤーエージェントに送られます。コンテンツコンテキストを含みます。ユーザーアイデンティティを含んではなりません（MUST NOT）。 | Field | Type | Required | Description | | ------------------ | ------------------ | -------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `type` | string | Yes | `"context_match_request"`。デシリアライゼーションのメッセージタイプ判別子。 | | `protocol_version` | string | No | TMP プロトコルバージョン。デフォルト: `1.0`。受信者がバージョン間の意味的差異を扱えるようにする。 | | `request_id` | string | Yes | ログ用の一意のリクエスト識別子。任意の Identity Match request\_id と相関してはならない（MUST NOT）。 | | `property_rid` | UUID | Yes | プロパティカタログ UUID（v7）。グローバルに一意、安定。 | | `property_id` | string | No | パブリッシャーの人間可読なスラッグ。`property_rid` が存在するとき任意。 | | `property_type` | enum | Yes | 次の 1 つ: `website`、`mobile_app`、`ctv_app`、`desktop_app`、`dooh`、`podcast`、`radio`、`linear_tv`、`streaming_audio`、`ai_assistant`。`property-type` enum を参照。 | | `placement_id` | string | Yes | パブリッシャーの `adagents.json` のプレースメントレジストリからのプレースメント識別子。リクエストごとに 1 プレースメント。 | | `seller_agent_url` | string (URI) | Yes | このリクエストを発行するセラーエージェントの API エンドポイント URL。プロバイダーはそれに対してこのセラーに同期したアクティブなパッケージセットを解決する。同期されていないセラーは、別のセラーのセットへのフォールバックではなく空のオファーセットを生成しなければならない（MUST）。ユーザーアイデンティティを運ばない単一のプレースメントごとの値。AdCP URL 正準化で比較される。Identity Match リクエストの `seller_agent_url` および `adagents.json` の `agent_url` と一貫。 | | `artifact` | Artifact | No | この広告機会に隣接する完全なコンテンツアーティファクト。コンテンツ標準評価と同じスキーマ。パブリッシャーはバイヤーに実際のコンテンツを評価させたいとき完全なアーティファクトを送る。契約上の保護がバイヤーの使用を統治する。TEE デプロイが契約的信頼を暗号学的検証に格上げする。 | | `artifact_refs` | List\ | No | バイヤーが独立して解決できる公開コンテンツ参照。各は `type`（次の 1 つ: `url`、`url_hash`、`eidr`、`gracenote`、`isrc`、`gtin`、`rss_guid`、`isbn`、`custom`）と `value` を持つ。URL アドレス可能なコンテンツについては、バイヤーがこれらを事前分類している場合がある。パブリッシャーが URL を明かしたくないとき（コンテキストクリーンルーム）は `url_hash` を使う。 | | `context_signals` | ContextSignals | No | コンテンツ環境の事前計算された分類器出力。コンテンツが一時的（会話ターン、検索クエリ）なとき、またはアーティファクトベースのマッチングを補完するために使う。`artifact_refs` を完全に置き換えられる。生のコンテンツを含んではならない（MUST NOT） — 分類された出力のみ。パブリッシャーが分類器境界。 | | `geo` | Geo | No | 視聴者の粗い地理的位置。パブリッシャーが粒度を制御 — 規制コンプライアンスには国、キャンペーンターゲティングと評価には地域/メトロ。郵便番号や座標なし — ユーザー識別を防ぐため粗くされる。 | | `package_ids` | List\ | No | 評価を特定のパッケージに制限する。省略されたとき、プロバイダーはこのプレースメントのすべての適格なパッケージを評価する（一般的なケース）。パッケージメタデータ（フォーマット、カタログ）はメディアバイ時に同期される — リクエストごとに送られない。 | #### ContextSignals コンテンツ環境の事前計算された分類器出力。生のコンテンツ（会話テキスト、記事本文、URL）を含んではなりません（MUST NOT）。分類された出力のみ。パブリッシャーが分類器境界。 | Field | Type | Required | Description | | ------------------ | ------------- | -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `topics` | List\ | No | コンテンツトピック識別子。`taxonomy_id` が 7（デフォルト）のとき IAB Content Taxonomy 3.0 ID を、カスタムタクソノミーには人間可読な文字列を使う。 | | `taxonomy_source` | enum | No | トピックタクソノミーを定義する組織。デフォルト: `iab`。 | | `taxonomy_id` | integer | No | ソース内のタクソノミーバージョン。IAB については AdCOM cattax enum に従う: `7` = Content Taxonomy 3.0（CC-BY-3.0）。デフォルト: `7`。 | | `sentiment` | enum | No | コンテンツセンチメント: `positive`、`negative`、`neutral`、`mixed`。 | | `keywords` | List\ | No | パブリッシャーの分類器が抽出したコンテンツキーワード。 | | `language` | string | No | ISO 639-1 言語コード。 | | `content_policies` | List\ | No | このコンテンツが満たす [AdCP Policy Registry](/docs/governance/policy-registry) のポリシー ID。ルーターはこれをパブリッシャーのプロパティガバナンス設定またはコンテンツメタデータから投入する。バイヤーはパッケージの `required_policies` で要求するポリシーをフィルターする。これは **事前フィルタリング最適化** — 要求されるポリシーを欠くコンテキストは下流ガバナンスに到達する前に除外される。決定的な強制は [`check_governance`](/docs/governance/campaign/tasks/check_governance) 経由でガバナンス層で起こる。 | | `summary` | string | No | 関連性判断のための自然言語 summary。セマンティックに評価する LLM ネイティブなバイヤーに有用。 | | `embedding` | string | No | base64 エンコードされた int8 ベクターとしてのコンテンツ embedding。トピックとキーワードを超えたセマンティックコンテンツを捉える。 | | `embedding_model` | string | No | Embedding モデル識別子（例: `nomic-embed-text-v1.5`）。`embedding` が存在するとき必須。 | | `embedding_dims` | integer | No | Embedding ベクターの次元数。`embedding` が存在するとき必須。 | 3 つのレベルのコンテンツ開示 — パブリッシャーはバイヤーが必要とするものとパブリッシャーが共有して快適なものに基づいて選ぶ: * **`artifact`** — 完全なコンテンツ（記事本文、トランスクリプト、会話フロー、プロダクトページ）。コンテンツ標準アーティファクトと同じスキーマ。バイヤーがコンテンツを直接評価する。契約上の保護がバイヤーができることを統治する。TEE デプロイが暗号学的検証を上に追加する。 * **`artifact_refs`** — バイヤーが独立して解決する公開参照（URL、EIDR ID、URL ハッシュ）。バイヤーが自分でクロールして分類できる公開アドレス可能なコンテンツに使う。 * **`context_signals`** — 分類された出力（トピック、センチメント、キーワード、summary）。パブリッシャーがコンテンツやその参照を共有せずにコンテンツを記述したいときに使う。 `context_signals` はベースライン — すべてのバイヤーエージェントがそれを扱わなければならない（MUST）。`artifact_refs` と `artifact` は漸進的な強化。`artifact_refs` を送るパブリッシャーは、参照を解決できないバイヤーのためのフォールバックとして `context_signals` も送るべき（SHOULD）。 LLM ベースのバイヤーエージェントは、`context_signals.summary` と `context_signals.topics` を最初に評価すべき（SHOULD）。これらのフィールドは、最小のトークンコスト（約 30 トークン）でほとんどの関連性決定に十分なシグナルを提供する。`artifact_refs` からの完全なコンテンツ解決や `artifact` 評価は、精度がコストを正当化する高価値のパッケージのために予約すべき（SHOULD）。バイヤーは `artifact` コンテンツと `context_signals.summary` を信頼できないパブリッシャー生成の入力として扱わなければならない（MUST）。 リクエストは任意の組み合わせを含められる。ニュースサイトは `artifact_refs`（URL）と `context_signals`（事前分類されたトピック）を送る。CTV アプリは `artifact_refs`（EIDR ID）のみを送る。AI アシスタントは、コンテンツを直接評価するバイヤーには `artifact`（会話）を、加えてフォールバックとして `context_signals` を送る。コンテンツや参照を共有したくないパブリッシャーは `context_signals` のみを送る。 #### Artifact Ref Type Conventions バイヤーは `artifact_refs` 文字列をパターンでパースします。次の慣例は規範的です: | Type | Pattern | Example | | ------------- | -------------------- | ------------------------------------------------------ | | URL | `https://` で始まる | `https://oakwood.example/articles/sustainable-kitchen` | | URL hash | 44 文字 base64（Blake3） | `k7Xp9mQ2vL8nR3wY5tB1aH6jK0pZ4xC9dF2eG7iMqw==` | | EIDR | `eidr:` で始まる | `eidr:10.5240/XXXX-XXXX-XXXX-XXXX-XXXX-C` | | Gracenote TMS | `tms:` で始まる | `tms:SH012345670000` | | RSS + GUID | `rss:` で始まる | `rss:https://feed.example/rss+guid:ep-2026-03-15` | | GTIN | 8-14 桁の数値 | `00012345600012` | バイヤーは、リクエストを失敗させるのではなく、サポートしない ref タイプを無視すべき（SHOULD）。 #### Artifact 型付きコンテンツ参照。各アーティファクトは標準またはカスタムの識別子スキームを使ってコンテンツの一片を識別します。 | Field | Type | Required | Description | | ------- | ------ | -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | `type` | enum | Yes | 次の 1 つ: `url`、`url_hash`、`eidr`、`gracenote`、`isrc`、`gtin`、`rss_guid`、`isbn`、`custom`。 | | `value` | string | Yes | 識別子の値。`url`: 正準コンテンツ URL（ユーザー固有のパスやクエリパラメーターを含んではならない。URL を明かすのを避けるには `url_hash` を使う）。`url_hash`: base64 エンコードされた Blake3 ハッシュ（正準化: スキーム除去、[www./m./amp](http://www./m./amp). プレフィックス除去、小文字化、末尾スラッシュ除去、クエリパラメーターとフラグメント除去）。`eidr`: EIDR DOI（例: `10.5240/xxxx`）。`gracenote`: Gracenote TMS ID（例: `SH032541890000`）。`isrc`: ISRC コード（例: `USRC17607839`）。`gtin`: GTIN（例: `00012345678905`）。`rss_guid`: RSS フィードのエピソード GUID。`isbn`: ISBN（例: `978-0-123456-78-9`）。`custom`: パブリッシャー定義の文字列。 | #### Geo インプレッション機会の地理的コンテキスト。パブリッシャーが粒度を制御します。 | Field | Type | Required | Description | | --------- | ------ | -------- | -------------------------------------- | | `country` | string | No | ISO 3166-1 alpha-2 国コード（例: `US`、`GB`）。 | | `region` | string | No | ISO 3166-2 区分コード（例: `US-CA`、`GB-SCT`）。 | | `metro` | Metro | No | AdCP のメトロ分類システムを使ったメトロエリア。 | ### ContextMatchResponse バイヤーエージェントが返します。一致したパッケージのオファーと任意のレスポンスレベルのターゲティングシグナルを含みます。 | Field | Type | Required | Description | | ------------ | ------------ | -------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `type` | string | Yes | `"context_match_response"`。デシリアライゼーションのメッセージタイプ判別子。 | | `request_id` | string | Yes | リクエストの `request_id` のエコー。 | | `offers` | List\ | Yes | バイヤーからのオファー、アクティベートされたパッケージごとに 1 つ。空リストはパッケージが一致しなかったことを意味する。 | | `cache_ttl` | integer | No | ルーターのデフォルト Context Match レスポンスキャッシュ TTL のプロバイダーオーバーライド（秒）。存在するとき、ルーターはデフォルトの代わりにこの値を使わなければならない（MUST）。`0` はキャッシュを無効化（例: ターゲティング設定がちょうど変わったとき）。スキーマ強制の最大は 86400 秒。[Caching](#caching) を参照。 | | `signals` | Signals | No | アドサーバー通過用のレスポンスレベルのターゲティングシグナル。オファーごとではない — レスポンス全体に適用。GAM のケースでは、これらがラインアイテムをトリガーするキー値ペアを運ぶ。 | #### Offer 単一のパッケージに対するバイヤーの応答。 | Field | Type | Required | Description | | ------------------- | -------------------- | -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | `package_id` | string | Yes | メディアバイからのパッケージ識別子。 | | `seller_agent` | SellerAgentRef | No | パブリッシャー側の可観測性のためのパッケージのセラーエージェントの任意のエコー。非権威的 — キャッシュされた AvailablePackage のバインディングが真実の源泉。ルーターはプロバイダーが省略したときキャッシュされた package→seller マップからこのフィールドをスタンプしてもよい（MAY）。[Package Sync](#package-sync) を参照。 | | `brand` | BrandRef | No | このオファーのブランド。プロダクトが動的ブランドを許すとき必須。単一ブランドパッケージについては、メディアバイから既知。 | | `price` | OfferPrice | No | このオファーの可変価格。プロダクトが可変価格をサポートするときのみ存在。 | | `summary` | string | No | パブリッシャーが関連性を判断するためのバイヤー生成のオファーの説明。例: 「Goldenfield マヨ 50% オフ — レシピ統合」。 | | `creative_manifest` | CreativeManifest | No | 完全なクリエイティブ詳細、インライン。存在するとき、パブリッシャーはレンダリングに必要なすべてを持つ。大きなクリエイティブ（VAST、動画）については、マニフェストは URL 経由で外部アセットを参照。 | | `macros` | Map\ | No | 動的クリエイティブレンダリングまたはアトリビューショントラッキングのキー値ペア。GAM のケースでは、これらがマクロ値として流れる。フリークエンシートラッキング用の暗号化された露出トークンを運ぶ Identity Match `tmpx` フィールドとは別。 | #### OfferPrice | Field | Type | Required | Description | | ---------- | ------ | -------- | ---------------------------------------- | | `amount` | number | Yes | 指定された通貨での価格額。 | | `currency` | string | No | ISO 4217 通貨コード。デフォルト: `USD`。 | | `model` | enum | Yes | 次の 1 つ: `cpm`、`cpc`、`cpcv`、`cpa`、`flat`。 | #### Signals アドサーバー通過用のレスポンスレベルのターゲティングシグナル。 | Field | Type | Required | Description | | --------------- | ------------------- | -------- | ------------------------- | | `segments` | List\ | No | オーディエンスまたはコンテキストセグメント ID。 | | `targeting_kvs` | List\ | No | アドサーバーターゲティングのキー値ペア。 | #### KeyValuePair | Field | Type | Required | Description | | ------- | ------ | -------- | ----------- | | `key` | string | Yes | ターゲティングキー。 | | `value` | string | Yes | ターゲティング値。 | ### IdentityMatchRequest パブリッシャー（ルーター経由）からバイヤーエージェントに送られます。セラーエージェント URL、1 つ以上の不透明なアイデンティティトークン、任意のパッケージ ID リストを含みます。ページコンテキストを含んではなりません（MUST NOT）。 | Field | Type | Required | Description | | -------------------- | ----------------------- | -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `type` | string | Yes | `"identity_match_request"`。デシリアライゼーションのメッセージタイプ判別子。 | | `protocol_version` | string | No | TMP プロトコルバージョン。デフォルト: `1.0`。 | | `request_id` | string | Yes | 一意のリクエスト識別子。任意の Context Match request\_id と相関してはならない（MUST NOT）。 | | `seller_agent_url` | string (URI) | Yes | このリクエストを発行するセラーエージェントの API エンドポイント URL。バイヤーの identity-match サービスはこれを使ってこのセラーに登録したアクティブなパッケージセットを解決する。`package_ids` が省略されたとき、その完全なセットに対して評価が起こる。バイト等価ではなく [AdCP URL 正準化ルール](/docs/reference/url-canonicalization) を使って比較される。`AvailablePackage` の `seller_agent.agent_url` および `adagents.json` の `agent_url` と一貫。 | | `identities` | List\ | Yes | ユーザーの 1 つ以上のアイデンティティトークン。パブリッシャーは利用可能なすべてのトークンを含めるべき（SHOULD） — バイヤーは一致するグラフで解決し、マッチ率を最大化する。各エントリは同じユーザーの独立した識別子。バイヤーはその組み合わせを新しい相関アイデンティティとして扱ってはならない（MUST NOT）。 | | `consent` | Consent | No | プライバシー同意シグナル。規制された管轄区域のバイヤーは同意情報なしにアイデンティティトークンを処理してはならない（MUST NOT）。 | | `package_ids` | List\ | No | 省略されたとき、バイヤーは `seller_agent_url` に登録したアクティブなパッケージの完全なセットに対して適格性を評価する。提供されたとき、構成は現在のプレースメントと統計的に独立でなければならない（MUST）。2 つの許容モード: **all-active**（このパブリッシャーでのこのバイヤーのすべてのアクティブパッケージ）または **fuzzed**（アクティブなパッケージのランダムサンプル、任意で合成の存在しない ID でパディング、現在のプレースメントに依存しない分布から抽出）。ページ固有のサブセットは禁止 — それはバイヤーがパッケージセットを比較して Context Match と相関させることを許す。 | | `country` | string | No | ISO 3166-1 alpha-2 国コード。ルーティングディレクティブ — ルーターはこれを使って正しい地域プロバイダーを選択する。ルーターはバイヤーエージェントに転送する前にこのフィールドを剥がさなければならない（MUST）。アイデンティティシグナルではない。 | | `sealed_credentials` | List\ | No | **実験的（`trusted_match.verified_identity`）。** 特定のオーディエンスに宛てられた HPKE 封印された検証済みアイデンティティ認証情報 — network-as-RP キャリア。パブリッシャーにとって不透明なパススルー。[Verified Identity Attestation](#verified-identity-attestation) を参照。 | `identities` の各エントリは `{user_token, uid_type, attestation?}` トリプルです: | Field | Type | Required | Description | | ------------- | ----------- | -------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `user_token` | string | Yes | アイデンティティプロバイダー（ID5、LiveRamp、UID2）からの、またはパブリッシャー生成の不透明なトークン。バイヤーは内部アイデンティティグラフにマップしてもよいが PII に逆変換できない。 | | `uid_type` | enum | Yes | ユーザー識別子のタイプ: `uid2`、`rampid`、`id5`、`euid`、`pairid`、`maid`、`hashed_email`、`publisher_first_party`、`world_id_nullifier`、`other`。バイヤーにどのアイデンティティグラフに対して解決するかを伝える。`uid-type` enum を参照。 | | `attestation` | Attestation | No | **実験的（`trusted_match.verified_identity`）。** このアイデンティティ *について* の検証可能な証明（人格証明および/または年齢）。受信者はそれを検証しなければならず（MUST）、検証不能なアテステーションを、asserted-true としてではなく absent として扱わなければならない。[Verified Identity Attestation](#verified-identity-attestation) を参照。 | ### IdentityMatchResponse バイヤーエージェントが返します。サーブウィンドウスロットルを伴う適格なパッケージ ID のリスト。 | Field | Type | Required | Description | | ---------------------- | ------------------------------------------- | -------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `type` | string | Yes | `"identity_match_response"`。デシリアライゼーションのメッセージタイプ判別子。 | | `request_id` | string | Yes | リクエストの `request_id` のエコー。 | | `eligible_package_ids` | List\ | Yes | ユーザーが適格なパッケージ ID。リストされないパッケージは不適格。 | | `serve_window_sec` | integer | Yes | パッケージごとのシングルショット fcap ウィンドウ、秒。範囲: 1–300。デフォルト: 60。このウィンドウ内で各適格パッケージにユーザーへ 1 インプレッションを提供した後、パブリッシャーはそれらのパッケージから再び提供する前に Identity Match を再クエリしなければならない（MUST）。これはルーターレスポンスキャッシュ TTL では **ない** — バイヤーがアサートするサーブスロットル。マルチインプレッションフリークエンシーキャップは、このウィンドウにかかわらず境界で IdentityMatch キャップ状態ストアにキャップ発火イベントを書き込むバイヤーのインプレッショントラッカーによって別途扱われる — [フリークエンシーキャップデータフロー](/docs/trusted-match/identity-match-implementation) を参照。 | | `tmpx_macros` | List\ | No | プロバイダーが発する（アイデンティティエージェント側フィールド）。各チャンクが埋めるアドサーバーマクロ名とペアになったエージェントの順序付けられた TMPX チャンク。名前は同じ順序でプロバイダーの登録された `tmpx_macros` リスト（[Provider Registration](#provider-registration) を参照）から取られなければならない（MUST）。v1 では 2 エントリに上限。各 `value` はパブリッシャーが逐語的に代入する不透明な URL セーフなワイヤー文字列 — パブリッシャーはパース、デコード、変換、エンコーディングの選択をしてはならない（MUST NOT）。ルーターのマージされたレスポンスを読むコンシューマーは `tmpx_providers` を消費し、ルートの `tmpx_macros` を無視すべき（SHOULD）。 | | `tmpx_providers` | Map\ }> | No | ルーターが投入。発信元アイデンティティプロバイダーの `provider_id` でグループ化された TMPX マクロ/値ペア。パブリッシャーが各プロバイダーのトークンをそのプロバイダーの特定のアドサーバーマクロ（例: あるプロバイダーの `PIN_TMPX_1`、`PIN_TMPX_2`、別のプロバイダーの `NOVA_TMPX_1` — GAM / VAST URL / DOOH play log でプロバイダーごとに設定）を通じて発火する。このリクエストで任意のアイデンティティプロバイダーが TMPX を発したときルーター適合性によって必須。プロバイダーごとのトークンを単一の文字列に折り畳むとアトリビューションが失われプロバイダーごとのインプレッション会計が壊れる。マクロ名は各プロバイダーの登録された `tmpx_macros` から来なければならない（MUST） — パブリッシャーは実行時に `provider_id` からマクロ名を導出してはならない（MUST NOT）。#5689 で出荷された実験的 v1 サーフェス（`Map` を使った）からの SHAPE CHANGE。実験的コントラクトによって認可。 | | `tmpx` | string | No | `tmpx_providers` を優先して非推奨。単一の HPKE 暗号化された露出トークン。ルーターは単一トークン形状のみを知るコンシューマーとの後方互換性のためこのフィールドを投入し続けてもよい（MAY）。両方のフィールドが存在するとき、`tmpx_providers` が権威的。ワイヤー形式: `kid.base64url_nopad(ciphertext)`（パディングなし、`=` 文字なし）。4.0 で削除。 | #### TmpxMacro | Field | Type | Required | Description | | ------- | ------ | -------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `name` | string | Yes | パブリッシャーのアドサーバーで設定されたアドサーバーマクロ名（例: `PIN_TMPX_1`）。発行プロバイダーの登録された `tmpx_macros` リストに現れなければならない（MUST）。パターン: `^[A-Z][A-Z0-9_]*$`。プロバイダーが distinct なスロットをプロバイダーごとにターゲットできるようプロバイダー名前空間化。 | | `value` | string | Yes | パブリッシャーが名前付きマクロスロットに逐語的に代入する不透明で URL セーフなワイヤー文字列。長さは 1024 文字に上限 — 255 文字の GAM キー値制限を快適に上回り、HPKE オーバーヘッド + チャンクされたペイロードに十分大きい。パブリッシャーはこの値をパース、デコード、変換してはならない（MUST NOT）。プロトコルはプラットフォームが相互運用するようワイヤー形式を固定する。生のバイトを運べるプラットフォームはプライベートに最適化してもよい（MAY）が、ワイヤーコントラクトは URL セーフな文字列のまま。 | レスポンスは適格なパッケージ ID、サーブウィンドウスロットル、プロバイダーごとの TMPX 形状（ルーターマージ後の `tmpx_providers`、またはプロバイダーごとのレベルでの `tmpx_macros`）を含みます。慣例により、プロバイダー→ルーターのペイロードは `tmpx_macros` を投入し `tmpx_providers` を欠如させる。ルーター→パブリッシャーのペイロードは `tmpx_providers`（各プロバイダーの `tmpx_macros` を収集して構築）を投入する。ルーターレスポンスはルートに `tmpx_macros` を運んではならない（MUST NOT） — 上流プロバイダーのルート配列を `tmpx_providers` と並んで漏らすと、パブリッシャーにどれを読むべきかのスキーマシグナルを与えず、同じ値を 1 つのスロットに二重発火し、マップが保護するために存在するプロバイダーごとの会計を破損するリスクがある。スキーマはこれを強制できない（同じスキーマが両方のホップに提供される）のでルーター適合性不変条件として存在する。ルーターはアウトバウンドレスポンスから `tmpx_macros` を落とさなければならない（MUST）。各 TMPX 値は、クリエイティブトラッキング URL を通じてバイヤーのインプレッションピクセルに流れる HPKE 暗号化された露出トークンで、ユーザーアイデンティティをパブリッシャーに露出せずにリアルタイムのユーザーごとのフリークエンシー状態更新を可能にする。バイヤーは持っている任意のアイデンティティシグナル（フリークエンシーキャップ、オーディエンスメンバーシップ、購入履歴）から適格性を計算し、通過するパッケージのみを返す。パブリッシャーはパッケージがなぜ除外されたかを知る必要はない — どのパッケージが適格かだけ。 **TMPX マクロトラフィッキング。** マクロ名は運用セットアップの一部であり、プロトコルが合成する識別子ではない。各アイデンティティプロバイダーは、そのプロバイダー登録エントリの `tmpx_macros` に安定したプロバイダー名前空間化されたマクロ名を登録する（例: Pinnacle は `["PIN_TMPX_1", "PIN_TMPX_2"]` を、Nova は `["NOVA_TMPX_1"]` を登録）。パブリッシャーはそれらの正確な名前をそのアドサーバー（GAM キー値、VAST URL マクロ、DOOH play-log フィールド）で設定する。レスポンスが到着すると、パブリッシャーは各プロバイダーの `macros[].value` を一致する `macros[].name` スロットに発火する — コントラクトは「この正確な文字列をこの正確なマクロに代入する」。順序付けられたマルチチャンクサポートにより単一の TMPX が 1 つのマクロスロットを超えられる（v1 ではプロバイダーごとに 2 チャンクに上限、shape change なしに上げられる MAY）。実行時に `provider_id` からマクロ名を導出することは、GAM/アドサーバーラインアイテムが実行時合成文字列ではなく登録された名前に対して事前に設定されるため、このトラフィッキングモデルを壊す。 `tmpx_providers` は、ファンアウトが複数のアイデンティティプロバイダーに到達したときルーターがアトリビューションを保つよう、マクロ/値ペアを `provider_id` でキー付けする。レガシー `tmpx` フィールドは、移行していないコンシューマーのため 3.x を通じてサポートされたまま。両方のフィールドが存在するとき、`tmpx_providers` が権威的で、単数フィールドは移行的な便宜としてのみ 1 つのプロバイダーの最初のスロット値を反映すべき（SHOULD）。 `serve_window_sec` フィールドは **パッケージごとのシングルショット fcap** であり、ルーターキャッシュ TTL ではない。バイヤーはこう言っている: 「各適格パッケージにユーザーへ 1 インプレッションを提供した後、それらのパッケージから再び提供する前に私に再クエリせよ。」ルーターは内部の重複排除/コスト節約ウィンドウのためにレスポンスをキャッシュしてもよい（MAY）が、パブリッシャー側の拘束コントラクトは「ウィンドウごとの適格パッケージごとに 1 インプレッション」。マルチインプレッションフリークエンシーキャップ（キャンペーンごとに 1 日 5、広告主ごとに 1 か月 100 など）はバイヤーのインプレッショントラッカーに存在し、`serve_window_sec` にかかわらず境界でキャップ発火イベントとして IdentityMatch サービスにサーフェスする。 パブリッシャーは適格性リストを入力として割り当てルール（競合分離、ポッド構成）を強制する。これはポッド固有またはバッチ固有のプロトコルセマンティクスの必要を除去する — パブリッシャーは、one-impression-per-package コントラクトを尊重しながら、サーブウィンドウ中に存在する任意のプレースメント（CTV 広告ポッド、20 スロットの web ページ、単一のプレロール）にわたって割り当てる。 #### Conformance invariants for IdentityMatch eligibility 準拠する IdentityMatch サービスは、各 `package_id ∈ request.package_ids` について、次の **すべて** が成立する場合かつその場合に限りパッケージが `eligible_package_ids` に含まれるように `eligible_package_ids` を計算しなければなりません（MUST）: 1. **オーディエンス適格性。** パッケージがオーディエンス要件を持たないか、または `a` がパッケージの必要オーディエンスセットにありかつ `a` が少なくとも 1 つのアイデンティティ `i ∈ request.identities` のオーディエンスメンバーシップにあるようなオーディエンス識別子 `a` が少なくとも 1 つ存在する（ユーザーの解決されたアイデンティティにわたる union がパッケージの必要オーディエンスと交差する）。 2. **フリークエンシーキャップ適格性。** 任意のアイデンティティ `i ∈ request.identities` に対してパッケージに `(identity, package)` キャップ状態エントリが存在しない。キャップ状態エントリは、バイヤーのインプレッショントラッカーがインプレッションがキャップを使い果たしたと判断したときに書き込まれ、有効期限タイムスタンプを運ぶ。エントリはそのタイムスタンプまで「存在」する。プロトコルは、インプレッショントラッカーがどうインプレッションをカウントし、ウィンドウを評価し、いつキャップが発火するかを決めるかを制約しない — 境界コントラクト（キャップ発火エントリがキャップ状態ストアに流れ込み、IdentityMatch サービスがクエリ時に存在を確認）のみ。境界コントラクトについては [フリークエンシーキャップデータフロー](/docs/trusted-match/identity-match-implementation) を参照。 3. **アクティブ状態。** inactive とマークされたパッケージまたはポリシーは absent であるかのように扱わなければならない（MUST）。 4. **オーディエンス鮮度。** バイヤーのオーディエンスパイプラインが鮮度期限を公開し現在時刻がそれを過ぎている場合、そのオーディエンスメンバーシップエントリは (1) に寄与してはならない（MUST NOT）。 5. **年齢適格性**（実験的 — `trusted_match.verified_identity` が有効なときのみ適用）。パッケージが年齢ポリシーを要求しないか、または何らかのアイデンティティ `i ∈ request.identities` が、`(パッケージの必要年齢ポリシー, request geo)` から解決されたしきい値以上の年齢クレームを持つ **検証済み** `attestation`（[Verified Identity Attestation](#verified-identity-attestation) の適合性ルール準拠）を運ぶ。未検証または欠如のアテステーションはこの条項を満たさない。機能が有効でないとき、この条項は自明に真なので、コア適合性は変わらない。 レスポンスとともに返される TMPX は、帯域外のインプレッショントラッカーが fcap ポリシー状態を更新し IdentityMatch キャップ状態ストアにキャップ発火イベントをシグナルできるよう、解決されたアイデンティティをエンコードしなければなりません（MUST） — § TMPX tokens と [フリークエンシーキャップデータフロー](/docs/trusted-match/identity-match-implementation) を参照。 ストレージバックエンド（valkey、Aerospike、DynamoDB、インメモリ、何でも）は実装。同じ入力についてこれらの不変条件を満たす異なるストレージバックエンドを持つ 2 つのサービスは、同じ適格性出力を返さなければなりません（MUST）。 #### Consent identity match のプライバシー同意シグナル。パブリッシャーは、規制された管轄区域（EU/EEA、カリフォルニアなど）で動作するとき同意情報を含めなければなりません（MUST）。バイヤーは、適用法が要求するとき、同意情報なしにユーザートークンを処理してはなりません（MUST NOT）。 | Field | Type | Required | Description | | ------------- | ------ | -------- | -------------------------------------------- | | `gdpr` | bool | No | GDPR がこのリクエストに適用されるか。 | | `tcf_consent` | string | No | IAB TCF v2.2 同意文字列。`gdpr` が true のとき存在。 | | `gpp` | string | No | IAB Global Privacy Platform 文字列。 | | `us_privacy` | string | No | US Privacy 文字列（CCPA）。GPP を優先して非推奨だが依然広く使われる。 | ### Verified Identity Attestation **実験的 — `experimental_features` に `trusted_match.verified_identity` を宣言**（`trusted_match.core` とは別、そのためバイヤーがサポートを独立に検出できる）。パブリッシャー — または relying party として動作するネットワーク/発行者 — が、バイヤーがアサーションを信頼するのではなくクレームを暗号学的に検証するよう、ユーザー *について* の **検証可能な** 証明（人格証明および/または年齢）を運べるようにする。発行者非依存: World ID が最初のスキーム。mDL / VC スタイルの発行者は同じ形状を使う。設計理由: `specs/tmp-verified-identity-attestation.md`。 これは、そうでなければ `additionalProperties: false` である `identity-match-request.json` を拡大します。拡大は意図的: アテステーションはプライバシー境界の **アイデンティティ** 側の証明であり — ページコンテキストではない — なので厳格なスキーマが保護する境界を破らない。 #### Topologies | Topology | Relying party | Carrier | | ---------------------------- | --------------- | ------------------------------------------------ | | Publisher-as-RP | パブリッシャー | `identities[]` エントリの `attestation`（パブリッシャーごとの仮名） | | Network-as-RP / issuer-as-RP | ネットワーク、または発行者自体 | `sealed_credentials[]`（オーディエンスの鍵に HPKE 封印） | #### Attestation 各 `identities[]` エントリの任意オブジェクト。 | Field | Type | Required | Description | | -------------------- | ------------------ | -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `issuer` | BrandRef | Yes | ベンダー BrandRef としてのアイデンティティ発行者 / アテステーション権威（例: `{"domain": "world.org"}`） — AdCP が測定/シグナルベンダーに使うのと同じ形状。ドメインがアンカー。`brand.json` ホスティングは任意。`scheme` が検証者バージョンを選択。 | | `scheme` | string | Yes | 証明スキームとバージョン、例: `world_id_v4`。 | | `relying_party_id` | string | No | 証明が鋳造された relying-party id。`relying_party_id` 所有者の `brand.json` の公開された `identity_relying_parties[]` に対して確認される（来歴）。 | | `action` | string | No | 証明がバインドされた発行者アクション/スコープ。 | | `claims` | List\ | Yes | 閉じた、発行者非依存のセット: `unique_human`、`age_over_13`、`age_over_16`、`age_over_18`、`age_over_21`。`attestation-claim` enum を参照。 | | `verification_level` | enum | No | `orb` \| `device` \| `document`。認証情報の強度。 | | `signal_binding` | string | No | 証明がコミットするシグナルのハッシュ（リプレイ防御）。 | | `proof` | object | Yes | スキーム固有の検証可能な証明素材。このスキーマにとって不透明。 | | `expires_at` | string (date-time) | No | 有効期限。受信者は過ぎたとき拒否しなければならない（MUST）。 | #### SealedCredential トップレベルの `sealed_credentials[]` のエントリ。 | Field | Type | Required | Description | | -------------- | ------ | -------- | ------------------------------------------------------------------------------------------ | | `audience_kid` | string | Yes | HPKE 秘密鍵が `payload` を開く受信者（ネットワーク / relying party）の鍵 id。 | | `payload` | string | Yes | TMPX エンベロープ形式 `kid.base64url_nopad(ciphertext)` で HPKE 封印されたアテステーション。パブリッシャーにとって不透明なパススルー。 | #### Conformance invariants (verified attestation) アテステーションを受け入れる受信者は次をしなければなりません（MUST）: 1. **信頼の前に検証。** 受け入れるすべての `scheme` について証明を検証する。検証に失敗するアテステーション — または `signal_binding`、`relying_party_id` 来歴、`expires_at` — は、asserted-true クレームとしてではなく **absent**（アテステーションなし）として扱わなければならない（MUST）。 2. **黙った格上げなし。** 未検証または検証不能なアテステーションを決して `true` として扱わない。 3. **relying\_party\_id 来歴。** 信頼する前に、アテステーションの `relying_party_id` がトラフィックを主張するエンティティに属することを確認する。所有者の `brand.json` `identity_relying_parties[]` が v1 のディスカバリーサーフェスだが、HTTPS 上で自己公開される — 権威あるルートは発行者自身の relying-party レジストリ（例: World ID のオンチェーンレジストリ）で、それに対して `brand.json` はクロスチェック。受信者は、発行者側のアンカーなしに、何らかの `brand.json` がリストするからという理由だけで `relying_party_id` を信頼してはならない（MUST NOT）。双方向の発行者メタデータクロスチェックは追跡されたオープン項目。 4. **封印された認証情報。** 受信者が鍵を持つ `audience_kid` の `sealed_credentials[]` エントリのみを復号する。残りは無視。 5. **有界リソース。** DoS を防ぐためアテステーションと封印された認証情報の数とサイズを有界化する。 **リプレイ（v1 制限）。** 証明を検証することは、*ある* 認証情報保持者がそれを生成したことを確立し、*この* インプレッションのために生成されたことではない。強制された `signal_binding` 鮮度ウィンドウと nullifier 再利用追跡 — 両方とも v1 では検証者に委ねられる（鮮度ポリシーは WG オープン） — なしでは、このサーフェスはせいぜい日次エポックのリプレイ耐性（`request_id` 重複排除経由）を提供する。受信者は `signal_binding` を新鮮で受信者確認可能な値にバインドし nullifier 再利用を追跡すべきで（SHOULD）、そうするまでアテステーションをインプレッションごとのライブネスシグナルとして過度に信頼してはならない（MUST NOT）。 #### Router handling of `sealed_credentials[]` ルーターは各 `sealed_credentials[]` エントリを、その `audience_kid` を所有するプロバイダーにのみ転送しなければなりません（route-by-audience、ブロードキャストでない）（MUST）。改ざん証拠とキャッシュ分割のルールは [Identity Match signed fields](#identity-match-signed-fields) と [Caching](#caching) で正準的に定義される: `sealed_credentials` はプロバイダーごとの再署名の正準バイトに折り込まれる（そのため注入または交換された blob がリクエスト署名を壊す）、`sealed_credentials_hash` は重複排除キャッシュキーの一部（そのためネットワーク認証情報の変更が古いレスポンスを提供するのではなくキャッシュを再分割する）。同じ正準アイデンティティバイトは既に任意のアイデンティティごとの `attestation` をカバーする。 #### Age as eligibility 検証済み年齢クレーム（`age_over_N`）は `eligible_package_ids` に解決される — 平文の年齢や生年月日として **決して** 運ばれない。検証する当事者は `(required age policy, geo) → required threshold claim` をマップし、アテステーションが必要しきい値以上のクレームを運ぶときのみパッケージを含める。管轄区域 → しきい値のテーブルは [AdCP Policy Registry](/docs/governance/policy-registry) で維持される（パッケージは `required_policies` 経由で年齢ポリシーを要求する）。sub-country（例: 米国州）解決は、Identity Match `country` フィールドが粗く転送前に剥がされるため、より細かい geo が利用可能な場所で起こる。 ### Error Response リクエストが処理できないときプロバイダーまたはルーターが返します。空の結果とは別 — 空の `offers` 配列や空の `eligible_package_ids` リストは、エラーではなく一致なしを意味する有効なレスポンス。 | Field | Type | Required | Description | | ------------ | ------ | -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | `type` | string | Yes | `"error"`。デシリアライゼーションのメッセージタイプ判別子。 | | `request_id` | string | Yes | 元のリクエストの `request_id` のエコー。 | | `code` | enum | Yes | 機械可読なエラーコード: `invalid_request`、`unknown_package`、`seller_not_authorized`、`rate_limited`、`timeout`、`internal_error`、`provider_unavailable`。`seller_not_authorized` は、AvailablePackage がパブリッシャーの adagents.json に存在しない `seller_agent.agent_url` を宣言するとき [package sync](#package-sync) 時に返される。 | | `message` | string | No | デバッグ用の人間可読なエラー説明。 | ルーターは、そのリクエストのマージされたレスポンスからエラーを返すプロバイダーを除外すべき（SHOULD）。ルーターはプロバイダーごとのエラー率を追跡し、持続的なエラーを持つプロバイダーを先制的にスキップしてもよい（MAY）。 ## Provider Registration TMP プロバイダーはパブリッシャー設定を通じてルーターに登録されます。パブリッシャーは、各プロバイダーのエンドポイントとサポートするケイパビリティとともに、ルーターがどのプロバイダーを呼ぶべきかを指定します。これは運用上の関係です — パブリッシャーはプロバイダーがその広告決定パスでコードを実行することを信頼します。 標準の登録パスは **静的設定** — パブリッシャーが Prebid モジュール設定、ルーター YAML、または同等のサーフェス固有の設定でプロバイダーを宣言する。動的登録（API 駆動、データベース裏付け）は、多くのプロバイダーを管理するかランタイム更新が必要なパブリッシャーのための等しく有効なバリアント。両アプローチは同じプロバイダー登録スキーマ（`/schemas/trusted-match/provider-registration.json`）を使う。 | Setting | Type | Required | Description | | ---------------- | ------------- | ----------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `provider_id` | string | Yes | このプロバイダー登録の安定した識別子。ログ、メトリクス、キャッシュキー、そして identity-match レスポンスの `tmpx_providers` のキーとして使われ、パブリッシャーが各プロバイダーの TMPX `macros[]` をそのプロバイダーの事前設定されたアドサーバースロット（`tmpx_macros` に登録 — マクロ名は実行時に `provider_id` から導出してはならない）にルーティングできる。パターン: `^[A-Za-z0-9_]+$`、最大長 64 — 値がクォートなしで運用サーフェス（ログ、メトリクス、ダッシュボード）に現れられる安全な英数字/アンダースコア文字セット。 | | `endpoint` | URL | Yes | プロバイダーのベース URL。ルーターはディスパッチ時に `/context` または `/identity` を追加する。 | | `context_match` | bool | No | プロバイダーが Context Match リクエストを扱う。`context_match` または `identity_match` の少なくとも一方が true でなければならない。 | | `identity_match` | bool | No | プロバイダーが Identity Match リクエストを扱う。`context_match` または `identity_match` の少なくとも一方が true でなければならない。 | | `countries` | List\ | Conditional | このプロバイダーが提供する ISO 3166-1 alpha-2 国コード。`identity_match` が true のとき存在し空でないことが必須（MUST）。 | | `uid_types` | List\ | Conditional | このプロバイダーが解決できるアイデンティティタイプ（`uid-type` enum から）。ルーターは、`uid_types` がリクエストの `identities` 配列の任意の `uid_type` と重なるプロバイダーを選択し、転送された `identities` を交差にフィルターする — プロバイダーは宣言しなかったタイプのトークンを受け取ってはならない（MUST NOT）。`identity_match` が true のとき存在し空でないことが必須（MUST）。 | | `properties` | List\ | No | このプロバイダーが提供するプロパティ RID。欠如のとき、プロバイダーはすべてのプロパティを提供する。 | | `timeout_ms` | integer | No | ミリ秒単位のプロバイダーごとのタイムアウト。ルーターの全体 `latency_budget_ms` 以下でなければならない。デフォルト: 50。 | | `priority` | integer | No | マージ衝突解決のプロバイダー順序。低い値 = 高優先。デフォルト: 0。 | | `tmpx_macros` | List\ | No | このプロバイダーの TMPX レスポンスが埋める、安定したプロバイダー名前空間化されたアドサーバーマクロ名、順序付き（例: `["PIN_TMPX_1", "PIN_TMPX_2"]`）。パブリッシャーはこれらの正確な名前をそのアドサーバーでトラフィックする。ルーターは各プロバイダーの TMPX チャンクを identity-match レスポンスの一致するスロットに置く。名前はパターン `^[A-Z][A-Z0-9_]*$` に一致しなければならない（MUST）。v1 では 2 エントリに上限。上限は shape change なしに上げられる（MAY）。TMPX を発する（すなわち identity-match レスポンスに `tmpx_macros` を投入する）プロバイダーはこのリストも登録しなければならない（MUST）。さもなければルーターは `tmpx_providers` に転送するスロット名を持たない。「TMPX を発する」がスキーマ可視の述語でないためスキーマはこれを強制できない。マクロ名は実行時に `provider_id` から導出してはならない（MUST NOT） — トラフィッキングはこれらの登録された名前に対して事前に設定される。 | | `status` | enum | No | プロバイダーライフサイクルステータス: `active`、`inactive`、または `draining`。デフォルト: `active`。 | `context_match` または `identity_match` の少なくとも一方が true でなければなりません — どちらの操作も扱わないプロバイダーは無効です。`identity_match` が true のとき、`countries` と `uid_types` は **必須** です — ルーターはそれらなしに国分割アイデンティティルーティングを実行できません。スキーマは両方の制約を強制します。 プロバイダーは `context_match` と `identity_match` の任意の組み合わせをサポートしてもよい（MAY）。`context_match` のみをサポートするプロバイダーは純粋なエンリッチメントまたはコンテキストターゲティングプロバイダー。`identity_match` のみをサポートするプロバイダーはフリークエンシーキャッピングプロバイダー — パブリッシャーはメディアバイのターゲティングルールからコンテキストをローカルで評価し、アイデンティティチェックのためだけにバイヤーを呼ぶ。 ### Provider lifecycle プロバイダーは 3 つのライフサイクル状態を持ちます: * **Active**: プロバイダーが通常どおりリクエストを受け取る。 * **Draining**: プロバイダーが新しいリクエストの受け取りを停止する。飛行中のリクエストは通常どおり完了する。プロバイダーを保守のためオフラインにするとき使う — ルーターはこのプロバイダーへの新しいファンアウトを開始せずに現在の作業を終える。 * **Inactive**: プロバイダーが完全にスキップされる。設定を削除せずにプロバイダーを無効化するとき使う。 状態遷移は静的設定では即時（設定をリロード）で、動的登録では 1 リフレッシュサイクル内に有効になる。 ### Provider registration security **エンドポイント URL 検証（SSRF）。** 静的設定と動的登録の両方が、プロバイダー `endpoint` URL を正準の [Webhook URL 検証（SSRF）](/docs/building/by-layer/L1/security#webhook-url-validation-ssrf) ルールに対して検証しなければなりません（MUST） — 本番では HTTPS のみ、予約された IPv4 と IPv6 範囲を拒否（`::ffff:0:0/96` の IPv4 マップバイパスと `169.254.169.254` / `fd00:ec2::254` クラウドメタデータアドレスを含む）、リダイレクトなし。ルーターがすべてのリクエストでプロバイダーを呼ぶため、DNS リバインディングが主要なリスク: ルーターは、検証を通過した IP に TCP 接続をピン留めするか、リクエストボディを送る前にソケットのハンドシェイク後のピアアドレスを再検証するかのいずれかをしなければならない（MUST）。ピン留めなしに DNS を再解決するのは不十分。 **動的登録認証。** 動的登録 API は特権的なサーフェス。未認証の登録は攻撃者がパブリッシャートラフィックを任意の HTTPS エンドポイントに向けることを許す。動的登録を公開するルーターは呼び出し元を認証しなければならず（MUST）（mTLS または短命の OAuth 2.0 トークン。静的 API キーは IP 許可リストとともにのみ）、変更のエージェントごとのレート制限と登録ストーム悪用を有界化するためパブリッシャーごとの総登録プロバイダー数の上限を適用すべき（SHOULD）。 **ルーター対プロバイダー認証。** [Request Authentication](#request-authentication) の既存の「デプロイ固有（mTLS、API キーなど）」の言葉がメカニズムを設定する。最低ラインは、本番プロバイダーが匿名呼び出しを受け入れてはならない（MUST NOT）こと。静的 bearer トークンは IP 許可リストとともにのみ使ってもよい（MAY）。 **`/health` エンドポイント。** ルーターの生存性のためにプロバイダーが公開することが推奨される `/health` エンドポイントは未認証でもよい（MAY）が、レスポンスは内部状態を漏らしてはならない（MUST NOT）。プロバイダーは準備完了のとき `200` をボディ `{"status": "ok"}` とともに、準備未完了のとき `503` を返すべき（SHOULD）。他のステータスコードはバグ。プロバイダーは内部サブシステムによってステータスコードやレスポンスボディを区別してはならない（MUST NOT）（例えば、データベースがダウンしているときとアイデンティティキャッシュがダウンしているときの distinct なコードは、外部プロービングを内部トポロジーにマップするサイドチャネル）。バージョン文字列、ビルドハッシュ、内部ホスト名、依存関係ステータスはボディに現れてはならない（MUST NOT）。DoS 増幅器にならないようエンドポイントをレート制限（推奨: ソース IP ごとに 1 req/秒）する。 ## Product Integration パブリッシャーは `trusted_match` フィールド経由でそのプロダクトに TMP サポートを宣言します。バイヤーは `get_products` でこれを見て、どの TMP ケイパビリティが利用可能かを知ります。 | Field | Type | Required | Description | | ---------------- | -------------------- | -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | `context_match` | bool | Yes | プロダクトが Context Match リクエストをサポートする。 | | `identity_match` | bool | No | プロダクトが Identity Match リクエストをサポートする。デフォルト: false。 | | `response_types` | List\ | No | パブリッシャーが受け入れられるもの: `activation`（デフォルト）、`catalog_items`、`creative`、`deal`。 | | `dynamic_brands` | bool | No | バイヤーがマッチ時にブランドを選択できるか。false（デフォルト）のとき、ブランドはメディアバイになければならない。true のとき、バイヤーのオファーは任意のブランドを含められる — パブリッシャーがマッチ時に承認ルールを適用する。マルチブランド合意を可能にする。 | | `providers` | List\ | No | このプロダクトのインベントリと統合された TMP プロバイダー。各エントリは `agent_url`（レジストリから）でプロバイダーを識別しどのマッチタイプをサポートするかを宣言する。プロダクトレベルの `context_match` と `identity_match` boolean が全体的なサポートを宣言し、プロバイダーごとの boolean がどのプロバイダーが各を扱うかを宣言する。バイヤーディスカバリーを可能にする。 | #### ProviderEntry | Field | Type | Required | Description | | ---------------- | ------------- | -------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `agent_url` | string (URI) | Yes | レジストリからのプロバイダーのエージェント URL。この TMP プロバイダーの正準識別子。バイト等価ではなく [AdCP URL 正準化ルール](/docs/reference/url-canonicalization) を使ってルーターのプロバイダーレジストリに対して比較される。 | | `context_match` | bool | No | このプロバイダーがこのプロダクトの context match を扱うか。デフォルト: false。 | | `identity_match` | bool | No | このプロバイダーがこのプロダクトの identity match を扱うか。デフォルト: false。 | | `countries` | List\ | No | このプロバイダーが提供する ISO 3166-1 alpha-2 国コード。ルーターはリクエストの `country` フィールドでプロバイダーをフィルターする。`identity_match` が true のとき必須。 | | `uid_types` | List\ | No | このプロバイダーが解決できるアイデンティティタイプ（`uid-type` enum から）。ルーターは、`uid_types` がリクエストの `identities` 配列の任意の `uid_type` と重なるプロバイダーを選択し、転送された `identities` を交差にフィルターする — プロバイダーは宣言しなかったタイプのトークンを受け取ってはならない（MUST NOT）。`identity_match` が true のとき必須。 | ## Package Sync パッケージメタデータは、メディアバイ作成時、およびメディアバイが実質的に変わるたびに、セラーエージェントから TMP プロバイダーに同期されます。プロバイダーはプレースメントごとに `AvailablePackage` セットをキャッシュしリクエスト時に使う — `context_match_request` や `identity_match_request` を通じてパッケージメタデータは流れない。同期トランスポート、認証、バッチエラー形状はデプロイ固有。このセクションはペイロードコントラクトと各参加者が継承する義務を定義する。 `AvailablePackage` の `seller_agent` は実験的 `trusted_match.core` サーフェスの下で必須です。既存のデプロイで TMP を実行するセラーは、それを投入するよう同期ペイロードを更新しなければなりません — 3.x-to-3.x 進化ポリシーについては [実験的機能コントラクト](/docs/reference/experimental-status) を参照。 ### AvailablePackage | Field | Type | Required | Description | | -------------- | --------------- | -------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `package_id` | string | Yes | パッケージの一意識別子。 | | `media_buy_id` | string | Yes | このパッケージが属するメディアバイ。 | | `seller_agent` | SellerAgentRef | Yes | このパッケージを所有するセラーエージェント。`agent_url` は、このパッケージが提供しうるすべてのプロパティについて権威ある adagents.json の `authorized_agents[].url` の 1 つに一致しなければならない（MUST）。[Seller Agent Attribution](#seller-agent-attribution) を参照。 | | `format_ids` | List\ | No | このパッケージに適格なクリエイティブフォーマット識別子。標準の `{agent_url, id}` 形状を使う。 | | `catalogs` | List\ | No | このパッケージに添付されたバイヤーカタログ、どのアイテムが対象かをスコープするセレクター付き。別途同期されたカタログデータに対して `catalog_id` で参照される。 | #### SellerAgentRef | Field | Type | Required | Description | | ----------- | ------------ | -------- | --------------------------------------------------------------------------------------------------------- | | `agent_url` | string (URI) | Yes | セラーエージェントの API エンドポイント URL、プロパティパブリッシャーの adagents.json `authorized_agents[].url` で宣言されたとおり正確に。本番では HTTPS。 | | `id` | string | No | 将来のレジストリ割り当ての安定したセラー識別子のために予約。今日は使われない。参照が破壊的リネームなしに後で不透明 ID 層を吸収できるよう含まれている。 | ### Seller Agent Attribution TMP プロバイダーは多くのセラーエージェントからのパッケージを多くのパブリッシャーに対してキャッシュします。`seller_agent` フィールドは各キャッシュされた `AvailablePackage` にその来歴を明示的にし、プロバイダー — メディアバイストアへのアクセスを持たない — が、帯域外ルックアップなしにオファーを帰属させ、セラーごとの可観測性を適用し、紛争を解決できるようにします。 AdCP の正準セラーアイデンティティは、プロパティパブリッシャーの [adagents.json](https://adcontextprotocol.org/schemas/v3/adagents.json) `authorized_agents[].url` エントリで宣言されたエージェント URL です。TMP は並行する識別子空間を導入するのではなくその URL を直接再利用します。`SellerAgentRef` の `id` スロットは将来のレジストリ割り当ての不透明な識別子のために予約され、今日は使われません。 **配置理由。** `context_match_request` と `identity_match_request` の両方が `seller_agent_url` を運びます。それは、受信エージェントが尋ねるセラーに登録したアクティブなパッケージセットを解決するのに使うキー: コンテキストパスのプロバイダー、アイデンティティパスのバイヤーエージェント。`package_ids` が省略されたとき、評価はそのセラーの完全なアクティブセットに対して実行される。受信者がパッケージを同期していない `seller_agent_url` は、別のセラーのセットへのフォールバックではなく空の結果を生成しなければならない（MUST）。 `seller_agent` は、アトリビューションのためキャッシュされた `AvailablePackage`（同期時）にも存在する — そのバインディングがどのセラーがパッケージを所有するかの真実の源泉で、下のオファーエコーがそれから読む。2 つは異なる仕事を運ぶ: リクエスト側の `seller_agent_url` はどのセラーのセットを評価するかを選択し、パッケージ側の `seller_agent` は個々のパッケージを帰属させる。同期時はプロバイダーが最初にパッケージについて学ぶとき。そのバインディングは一度確立され後続のすべての評価で再利用される。 `seller_agent_url` は [Package set decorrelation](#package-set-decorrelation) 保証と相互作用しません。その保証は、ユーザーごとに変わるデータ — 主に `package_ids`、その構成は現在のプレースメントと独立でなければならない — を制約します。`seller_agent_url` は尋ねるセラーを識別する単一の安定した値で、特定のプレースメントのすべてのユーザーで同一でありユーザーアイデンティティを運ばないので、コンテキストとアイデンティティのリクエストが相関されうるユーザーごとのシグナルを追加しない。これは受信者側のアクティブセットスコーピングで、ユーザーごとのフィルターではない。 **オファーエコー。** `seller_agent` は、メディアバイストアに再結合せずにワンホップアトリビューションを望むパブリッシャー側のログパイプラインのため、キャッシュされたパッケージからのエコーとして `offer.json` に現れてもよい（MAY）。エコーは非権威的 — キャッシュされた `AvailablePackage` バインディングが真実の源泉。プロバイダーとルーターは、ログ、転送、または下流へのオファー発出の前に、不一致のエコーをキャッシュされたバインディングで上書きしなければならず（MUST）、課金、レポート、紛争解決に消費される任意のフィールドでエコー値を使ってはならない（MUST NOT）。不一致は異常検出のため `seller_agent_echo_mismatch` メトリクスにカウントすべき（SHOULD）。ルーターはプロバイダーが省略したときマージで `seller_agent` をスタンプしてもよい（MAY）。 ### Sync-Time Validation プロバイダーは同期時に `seller_agent.agent_url` をプロパティパブリッシャーの adagents.json に対して検証すべきです（SHOULD）: 1. パッケージが提供しうる各プロパティについて、プロパティドメインの `/.well-known/adagents.json` をフェッチする。ファイルが `authoritative_location` ポインターを含む場合、同一スキームの HTTPS URL への最大 1 ホップでそれをたどる。それ以上チェーンしない。初期フェッチと `authoritative_location` ホップの両方が [Webhook URL 検証（SSRF）](/docs/building/by-layer/L1/security#webhook-url-validation-ssrf) ルールを適用しなければならない（MUST） — HTTPS のみ、予約された IPv4 と IPv6 範囲を拒否（`::ffff:0:0/96` IPv4 マップバイパスと `169.254.169.254` / `fd00:ec2::254` クラウドメタデータアドレスを含む）、透過的リダイレクトなし、TCP 接続を検証された IP にピン留め。[Provider registration security](#provider-registration-security) で参照されるインバウンドフェッチルールは、このアウトバウンドフェッチにも等しく適用される。 2. `seller_agent.agent_url` が `authorized_agents[].url` に現れ、そのエントリの任意の `property_ids`、`collections`、`placement_ids`、`placement_tags`、`countries`、`effective_from`、`effective_until` 制約がパッケージのスコープを許すことを確認する。URL 比較は [AdCP URL 正準化ルール](/docs/reference/url-canonicalization) を使う — マッチング前に両方の値を正準化する、決してバイト等価でない。`https://` スキームを使わない `seller_agent.agent_url` 値を `seller_not_authorized` で拒否する。非 HTTPS セラー URL はトランスポート完全性保証を持たず認可キーとして信頼できない。 3. 不一致で、その `AvailablePackage` の同期操作を `code: seller_not_authorized` を使う `error` レスポンスで拒否する。同じ同期バッチの他のパッケージは影響を受けない。同期エラーの正確なワイヤー形状はデプロイ固有。`code` が機械可読な理由。 **キャッシュと再検証。** 検証結果は最大 5 分キャッシュすべき（SHOULD）、推奨 adagents.json キャッシュウィンドウに一致。プロバイダーはキャッシュ期限切れで再検証しなければならず（MUST）、持続的な `seller_not_authorized` 拒否をパブリッシャー運用にサーフェスすべき（SHOULD） — 繰り返しの失敗は通常、パブリッシャーの adagents.json とセラーの同期パイプラインが分岐したことを示す。認可の `effective_until` が過ぎるかセラーが `authorized_agents` から削除されるとき、プロバイダーは、再同期・再検証されるまで、そのセラーからの以前キャッシュされたパッケージをリクエスト時に `unknown_package` として扱わなければならない（MUST）。 **フェッチ失敗。** 検証が完了できないとき（フェッチエラー、タイムアウト、証明書失敗、不正な形式のファイル）、プロバイダーは、検証されていないバインディングをキャッシュするのではなく `seller_not_authorized` で同期を拒否すべき（SHOULD）。fail-open するプロバイダーは、検証されていないウィンドウを 5 分のキャッシュ TTL に有界化し、次の機会に再検証しなければならない（MUST）。一度も検証に成功していないバインディングは、そのウィンドウを過ぎてキャッシュされたままであってはならない（MUST NOT）。 **事前アテスト済み関係のバイパス。** プロバイダーは、同じ `agent_url → authorized_agents[].url` バインディングを帯域外オンボーディングプロセス（例: パブリッシャーのアテステーションを運ぶ相互認証されたプロバイダー-セラー登録）を通じて検証できるときのみ adagents.json チェックをスキップしてもよく（MAY）、パブリッシャーがオンボーディングをゲートできるよう、その適合性自己レポートに強制モード（`enforcing` / `advisory`）を公開すべき（SHOULD）。このエスケープハッチは `trusted_match.core` v1 で許可され、最初の非実験的 TMP リリースで削除され、その時点で検証は MUST になる。 ### Participant Responsibilities | Actor | Sync time | Request time | | ---------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Seller agent** | 同期するすべての `AvailablePackage` に、自身の adagents 登録された `agent_url` を `seller_agent.agent_url` として含める。パブリッシャーが `authorized_agents[].url` にアテストした URL でなければならない（MUST）。 | 新しい動作なし。オファーは `seller_agent` をエコーしてもよい（MAY）。省略も問題ない — ルーターがキャッシュからスタンプできる。 | | **Publisher** | adagents.json の `authorized_agents` を、スコープ制約（`property_ids`、`placement_ids`、`countries`、有効ウィンドウ）を含め正確に保つ。 | 新しい動作なし。 | | **Router** | 新しい動作なし。 | キャッシュされた package→seller バインディングを使って、それなしに到着したオファーに `seller_agent` をスタンプしてもよい（MAY）。`context_match_request` と `identity_match_request` の両方がそのスキーマごとに `seller_agent_url` を直接運ぶ。ルーターはそれを変更せずに転送しなければならず（MUST）、リクエストをフィルターまたは再ルーティングするのに使ってはならない（MUST NOT）。 | | **Provider** | [Sync-Time Validation](#sync-time-validation) ごとに `seller_agent.agent_url` をプロパティの adagents.json に対して検証する。認可されていないパッケージを `seller_not_authorized` で拒否する。バインディングをキャッシュされたパッケージとともに保存する。 | 生成するオファーに `seller_agent` をエコーする。キャッシュされたバインディングは飛行中の決定について不変だが、プロバイダーは、認可が期限切れになったパッケージ（`authorized_agents` からの削除または `effective_until` 経過）を、パッケージが再同期されるまで後続リクエストで `unknown_package` として扱わなければならない（MUST）。 | ### What This Is Not * **ユーザーごとのフィルターではない。** `seller_agent_url` は受信者が評価するどのセラーの登録されたアクティブセットかを選択する — プレースメントのすべてのユーザーで同じ値でユーザーアイデンティティを運ばない。パブリッシャー、ルーター、プロバイダーはそれをユーザーごとまたはリクエストごとのフィルターとして、またはリクエストを再ルーティングするために使ってはならない（MUST NOT）。そうすることは [Package set decorrelation](#package-set-decorrelation) が防ぐために存在するユーザーごとの変動を再導入する。パッケージ側の `seller_agent` アトリビューションも同様にリクエストをスコープまたはフィルターするのに使ってはならない（MUST NOT） — オファーアトリビューションのためだけに存在する。 * **sellers.json ブリッジではない。** IAB sellers.json `seller_id` と TAG-ID は distinct な財務監査アイデンティティ空間に提供する。それらは `adagents.json` `contact` に残る — TMP はそれらを複製しない。 * **暗号学的アテステーションではない。** バインディングは adagents.json 経由で HTTPS 上でパブリッシャーアテストされる。署名付き TMP セラークレームは将来の強化で、破壊的変更なしに予約された `id` スロットまたは `ext` フィールドを通じて `SellerAgentRef` に重ねられる。将来のリリースが `agent_url` と `id` の両方を投入するとき、`agent_url` が権威的のままで `id` は助言的 — 2 つの間の不一致は、URL の adagents.json バインディングが提供するものを超えて信頼を格上げするのに使ってはならない（MUST NOT）。 ## Privacy Requirements 次の要件は RFC 2119 キーワード（MUST、SHOULD、MAY）を使います。 ### Structural separation * Context Match リクエストはユーザーアイデンティティデータ（ユーザートークン、デバイス ID、IP アドレス、セッショントークン、特定のユーザーを識別しうる任意のデータ）を含んではならない（MUST NOT）。 * Identity Match リクエストはページコンテキストデータ（URL、コンテンツハッシュ、トピック ID、コンテンツシグナル、ユーザーが何を見ているかを識別しうる任意のデータ）を含んではならない（MUST NOT）。 * TMP ルーターは、共有状態のない構造的に分離されたコードパスで Context Match と Identity Match を処理しなければならない（MUST）。 * Context Match と Identity Match のリクエスト ID は相関または互いから導出可能であってはならない（MUST NOT）。 ### Package set decorrelation * Context Match はユーザーアイデンティティやオーディエンスでフィルターしてはならない（MUST NOT）。プロバイダーはプレースメントの同期されたパッケージセット — すべてのユーザーで同じパッケージ — を評価する。リクエストごとのパッケージリストは送られないので、パブリッシャーはパッケージフィルタリングを通じて誤ってアイデンティティを漏らせない。 * パブリッシャーは Identity Match から `package_ids` を省略し、バイヤーに `seller_agent_url` に登録した完全なアクティブセットに対して評価させるべき（SHOULD）。`package_ids` が提供されるとき、その構成は現在のプレースメントと統計的に独立でなければならない（MUST） — ページ固有のサブセットのみを送ることは、バイヤーがパッケージセットを比較して Identity Match を Context Match と相関させることを許す。2 つの許容モード: * **All-active。** このバイヤーがこのパブリッシャーに持つすべてのアクティブパッケージを含める。 * **Fuzzed。** アクティブなパッケージのランダムサンプル、任意で合成の存在しない ID でパディング、現在のプレースメントに依存しない分布から抽出。下の silent-drop ルールが合成 ID パディングを安全にする — 未知の ID はレスポンス形状に影響せずレジストリメンバーシップを漏らせない。 * `seller_agent_url` と `package_ids` の両方が存在するとき、バイヤーは登録されたアクティブセットと `package_ids` の交差に対して評価する。`package_ids` の未知の ID は、レスポンスがレジストリメンバーシップをパブリッシャーに漏らさないよう、黙って無視されなければならない（MUST）（エラーサーフェスしない）。 * バイヤーごとのすべてのアクティブパッケージ ID のキャッシュされたリストを維持するパブリッシャーは、多層防御としてすべての Identity Match リクエストで完全なセットを送ってもよい（MAY）が、`seller_agent_url` からのバイヤー側解決が主要なメカニズム。 * パブリッシャーは、両方のレスポンスが到着した後、context match オファーと identity match 適格性の交差をローカルで実行する。 ### Temporal decorrelation * パブリッシャーは Context Match と Identity Match リクエスト間にランダムな遅延を導入すべき（SHOULD）。推奨: 100-2000ms、一様分布。 * パブリッシャーは Context Match と Identity Match の順序もランダム化すべき（SHOULD）: 各機会は Context Match が先に送られるか Identity Match が先に送られるかのほぼ等しい確率を持つべき。固定順序 — 例えば Identity Match が常に Context Match の後 — は、遅延がランダム化されても順序を通じてペアリングを漏らす。 * パブリッシャーは複数のページビューにわたって Identity Match リクエストをバッチしてもよい（MAY）。 * パブリッシャーは Context Match と Identity Match を異なるネットワークパス経由でルーティングしてもよい（MAY）。 ### TEE attestation * TMP ルーターは、利用可能なとき、デプロイされたバイナリが公開されたソースに一致することを証明する TEE アテステーションを提供すべき（SHOULD）。 * アテステーションドキュメントは、リクエストに応じてパブリッシャーと監査者に利用可能であるべき（SHOULD）。 * アテステーションは、サービスコードの完全性と分離を確認する測定を含むべき（SHOULD）。 ### Consent handling * Identity Match リクエストから `consent` が省略されたとき、バイヤーはこれを「同意不要」ではなく「同意ステータス不明」として扱わなければならない（MUST）。 * 同意が要求される管轄区域のバイヤーは、`consent` を省略する Identity Match リクエストを、同意を仮定するのではなく拒否しなければならない（MUST）。 ### User token requirements * ユーザートークンはバイヤーエージェントにとって不透明でなければならない（MUST）。トークンはアイデンティティプロバイダー（ID5、LiveRamp、UID2）から発生するか、パブリッシャー生成であってよい。 * ユーザートークンは PII を含んではならず、バイヤーエージェントによって PII に逆変換可能であってはならない（MUST NOT）。 ## Request Authentication TMP リクエストは、リクエストが認可されたルーターから発生したことを証明する署名を運びます。これは、認可されていない当事者がプロバイダーに偽造リクエストを送ってターゲティングロジックをプローブし、スポンサーコンテンツを抽出し、フリークエンシー状態を操作するのを防ぎます。 ### Signing model ルーターは Ed25519 を使ってすべてのリクエストに署名します。Context Match と Identity Match の両リクエストが署名されますが、その異なるコンテンツとキャッシュ特性を反映する異なる署名フィールドで。 署名はリクエストを特定のプロバイダーにバインドします。ルーターは、ルーターのプロバイダー登録からのプロバイダーのエンドポイント URL を使って、ファンアウトターゲットごとに別個の署名に署名します。プロバイダーは、署名された `provider_endpoint_url` が自身のアドバタイズされたエンドポイントに一致することを検証し、そうでなければリクエストを拒否しなければなりません（MUST）。これは、キャプチャされた署名がエポック内でレジストリの異なるプロバイダーに対してリプレイされるのを防ぎます。 署名は、尋ねるセラーのエージェント URL である `seller_agent_url` にもバインドします。`seller_agent_url` は受信者がどのセラーの登録されたアクティブパッケージセットに対して評価するか（[Seller Agent Attribution](#seller-agent-attribution) を参照）を選択し、受信者が検証のためパブリッシャーの署名鍵を解決するのに使うルックアップキーです。それを署名バイトに含めることは、キャプチャされた署名が別のセラーのアイデンティティの下でリプレイされて別のセラーのオファーやアクティブパッケージセットを読むのを防ぎます。 日次エポックがリプレイ保護を提供します — キャプチャされた署名はせいぜい約 48 時間（現在 + 前のエポックが検証者に受け入れられる）有効です。 ### Signature envelope 署名は JSON ボディと並んで HTTP ヘッダー経由で送信されます。 | Header | Value | | ------------------ | ----------------------------------------- | | `X-AdCP-Signature` | Base64 エンコード（URL セーフ、パディングなし）の Ed25519 署名 | | `X-AdCP-Key-Id` | エージェントの `agent-signing-key.json` からの鍵識別子 | #### Context Match signed fields この順序で連結、UTF-8、改行区切り: | Field | Source | | ----------------------- | ------------------------------------------------------------------------------------------------------------------------------------ | | `type` | `context_match_request` | | `seller_agent_url` | リクエストボディから、[AdCP URL 正準化ルール](/docs/reference/url-canonicalization) を使って比較。署名を尋ねるセラーにバインド — 異なる `seller_agent_url` の下で署名を再利用すると検証に失敗。 | | `property_rid` | リクエストボディから | | `placement_id` | リクエストボディから | | `package_ids` | ソートされた、カンマ区切りのアクティブなパッケージ ID のリスト | | `provider_endpoint_url` | プロバイダーの登録されたエンドポイント URL（プロバイダー登録との正確な文字列一致、末尾スラッシュなし） | | `daily_epoch` | `floor(unix_timestamp / 86400)` | `package_ids` がリクエストから欠如するとき、署名は署名されたペイロードのそのフィールドに空文字列を使わなければならない（MUST）。 署名フィールドはセラーごとプレースメントごとプロバイダーごとに静的なので、同じ署名は 24 時間エポック内の同じ `(seller_agent_url, placement_id, provider_endpoint_url)` トリプルへのすべてのリクエストにキャッシュして再利用できます。キャッシュキーは `seller_agent_url` と `provider_endpoint_url` を含まなければならない（MUST） — セラーやプロバイダーをまたいで署名を再利用することはバインディングに違反し検証に失敗する。 #### Identity Match signed fields 署名された入力は、次の正準オブジェクトの [RFC 8785 JCS](https://datatracker.ietf.org/doc/html/rfc8785) シリアライゼーションの hex エンコードされた SHA-256 です。JCS を使うことでデリミタ注入リスクが除去されます — 生の `tcf_consent` / `gpp` / `us_privacy` / `package_id` 値は任意のバイトを含みうるが、JCS の JSON 文字列エスケープが任意のフレーミングバイトを無害にする。 | Field | Source | | ------------------------- | ------------------------------------------------------------------------------------------------------------------------------------ | | `type` | `"identity_match_request"` | | `request_id` | リクエストボディから | | `seller_agent_url` | リクエストボディから、[AdCP URL 正準化ルール](/docs/reference/url-canonicalization) を使って比較。署名を尋ねるセラーにバインド — 異なる `seller_agent_url` の下で署名を再利用すると検証に失敗。 | | `identities_hash` | 正準 `identities` バイトの hex エンコードされた SHA-256（下記参照） | | `consent` | リクエストの `consent` オブジェクト逐語的、または欠如のとき `null` | | `package_ids` | UTF-8 バイト順で辞書順ソートされたリクエストの `package_ids` | | `sealed_credentials_hash` | 正準 `sealed_credentials` バイトの hex エンコードされた SHA-256（下記参照）、または欠如のとき `null`。**実験的（`trusted_match.verified_identity`）。** | | `provider_endpoint_url` | プロバイダーの登録されたエンドポイント URL（プロバイダー登録との正確な文字列一致、末尾スラッシュなし）。署名を特定のプロバイダーにバインド — プロバイダーをまたいで署名を再利用すると検証に失敗。 | | `daily_epoch` | JSON 整数としての `floor(unix_timestamp / 86400)` | **正準 `identities` バイト:** バイト正確なマッチ（case folding なし、trimming なし）を使って `(uid_type, user_token)` で重複排除 — これは重複トークンのみを折り畳む — エントリを `uid_type`（UTF-8 バイト順）、次に `user_token`（UTF-8 バイト順）でソートし、結果の **完全なアイデンティティオブジェクト** の配列を [RFC 8785 JCS](https://datatracker.ietf.org/doc/html/rfc8785) としてシリアライズ。各オブジェクトは、**任意の `attestation` を含め** 完全にシリアライズされる — そのため署名がアテステーションをカバーし、剥がされた、交換された、または注入されたアイデンティティごとのアテステーションが署名検証を壊す（`(uid_type, user_token)` の重複排除キーは重複トークンを折り畳むためで、`attestation` がハッシュから除外されるという声明ではない）。UTF-8 バイトを SHA-256 し、署名された入力には hex エンコード、キャッシュキーには生バイトを使う（両方の慣例が同じプリイメージをハッシュする）。 **正準 `sealed_credentials` バイト**（実験的、`trusted_match.verified_identity`）: エントリを `audience_kid`（UTF-8 バイト順）でソートし、結果の配列を [RFC 8785 JCS](https://datatracker.ietf.org/doc/html/rfc8785) としてシリアライズ、UTF-8 バイトを SHA-256。リクエストが `sealed_credentials` を運ばないとき、`sealed_credentials_hash` は `null`。`sealed_credentials` が署名された入力の一部なので、注入または交換された封印 blob が署名検証を壊す。`sealed_credentials_hash` が重複排除キャッシュキーの一部（[Caching](#caching) を参照）なので、ネットワーク認証情報の変更がキャッシュを再分割し古い適格性が提供されない。ルーターは [route-by-`audience_kid`](#verified-identity-attestation) フィルタリングの後、各プロバイダーの転送されたセットに対して再署名する。 ルーターは転送前にプロバイダーごとに `identities` をフィルターします（[Identity Match ファンアウト](/docs/trusted-match/router-architecture#identity-match-fan-out) を参照）。署名は各プロバイダーのフィルターされた `identities` セットに対して計算される — ルーターはアウトバウンド転送ごとに再署名する。同じフィルターされた `identities_hash` 値がキャッシュキー（[Caching](#caching) を参照）で使われるので、各プロバイダーは実際に受け取ったサブセットでキー付けされた独自のキャッシュパーティションを持つ。 Identity Match 署名は `request_id` と `identities_hash` を含むので、リクエストごとに一意でキャッシュできない。これは意図的 — Identity Match レスポンスはバイヤー側のフリークエンシー状態に影響し冪等でなければならない。バイヤーは日次エポックウィンドウ内で `request_id` によって Identity Match リクエストを重複排除しなければならない（MUST）。繰り返された `request_id` は、フリークエンシー状態を更新せずに同じレスポンスを返さなければならない（MUST）。バイヤーは生の識別子を保持するのではなく `hash(request_id)` で重複排除すべき（SHOULD）。 ### Signature verification ルーターは、署名しファンアウトする前に、パブリッシャーからのインバウンドリクエストを認証しなければなりません（MUST）。パブリッシャー対ルーター認証のメカニズムはデプロイ固有（mTLS、API キーなど）で TMP 署名のスコープ外だが、強制されなければならない（MUST）。これは、侵害されたパブリッシャー側のコンポーネントが未認証リクエストをルーターの署名を通じてロンダリングするのを防ぎます。 ルーターはファンアウトする前にリクエストに署名します。プロバイダーは、プロパティレジストリから得たパブリッシャーの公開鍵を使って署名を検証します。これは、リクエストが認可されたルーターから発生したことを証明します — プロバイダーのターゲティングロジックをプローブするサードパーティではなく。プロバイダーは、すべてのリクエストを検証するのではなくサンプル検証すべき（SHOULD） — Ed25519 検証はリクエストごとに約 30μs 追加し、完全なパイプラインに比べれば小さいがボリュームでは積み重なる。5% のサンプルレートが、無視できるオーバーヘッドを追加しながら数秒以内に不正なパブリッシャーを検出する。 検証失敗で、プロバイダーは設定可能な期間（推奨: 24 時間）プロパティを抑制し運用にアラートすべき（SHOULD）。 ### Key rotation エージェントは、その well-known エージェント URL の `agent-signing-key.json` 経由で新しい署名鍵を公開します。ルーターは 5 分の TTL で鍵をキャッシュすべき（SHOULD）。署名が検証に失敗するとき、ルーターは拒否する前に鍵を再フェッチすべき（SHOULD） — エージェントがローテートしたかもしれない。 ### Key revocation ローテーションは鍵を置き換え、失効は 1 つを殺します。失効は、秘密鍵が漏洩したと知られているか疑われる侵害のケースのためです。 パブリッシャーは、`agent-signing-key.json` の鍵エントリに `revoked_at`（ISO 8601 タイムスタンプ）を設定し、古いキャッシュが依然としてそれを見つけられるよう猶予期間中に鍵を trust anchor に残すことで、侵害された鍵をマークします。検証者は次をしなければなりません（MUST）: * `revoked_at` が存在し署名エポックが失効タイムスタンプ以降に落ちる鍵で生成された任意の署名を拒否する。 * 最後のキャッシュリフレッシュの後に伝播した失効を拾うため、拒否する前に検証失敗で `agent-signing-key.json` を再フェッチする。 * 問題のあるリクエストについて失効を再試行不可として扱う — 「リトライで動くかも」の状態はない。 キャッシュ TTL（推奨: 5 分）がすべての検証者にわたって経過したら、鍵は trust anchor から完全に削除されてもよい。鍵を早く削除すると、キャッシュされたコピーを持つ検証者が新鮮なフェッチなら拒否する署名を受け入れるウィンドウを生みうる — キャッシュ伝播が完了するまで `revoked_at` マーカーを維持する。 **失効の制限。** 失効は 5 分以内（キャッシュ TTL）に伝播するが、失効が観測される前にプロバイダーによって既に受け入れられた署名を遡及的に無効化しない。`revoked_at` より前の署名エポックを持つキャプチャされた署名は、48 時間のリプレイウィンドウの残りの間検証可能なまま。侵害を疑うオペレーターは次をすべき（SHOULD）: * 確認された漏洩だけでなく、任意の疑いで先制的にローテートする。 * そもそも侵害の可能性を最小化するため、署名鍵をディスクではなく HSM または KMS に保つ。 * 日次エポックのロールオーバーがそれを含む署名されたペイロードを退役させるまで、漏洩した鍵が最大約 48 時間の偽造能力を付与することを受け入れる。このウィンドウが受け入れられないとき、より短いカスタムエポックウィンドウがデプロイオプション。 ### Key distribution パブリッシャーの公開鍵はプロパティレジストリ経由で配布されます。各プロパティレコードはパブリッシャーの Ed25519 公開鍵を含みます。プロバイダーは起動時にレジストリをダウンロードし、増分同期経由で最新に保ちます。 ## Wire Format コンテンツタイプ: `application/json` すべての TMP メッセージは JSON エンコーディングを使います。フィールド名とタイプはこの仕様の JSON Schema 定義に従います。実装は JSON をサポートしなければなりません（MUST）。 TMP メッセージは小さい（リクエスト/レスポンスごとに 200-600 バイト）。これらのサイズでは、シリアライゼーション形式は総レイテンシーの 1% 未満 — プロトコルのパフォーマンスは、エンコーディング効率ではなく、より小さいメッセージと構造的分離から来る。JSON はユニバーサルで、デバッグ可能で、すべての言語とツールでサポートされる。 ## Country-Partitioned Identity アイデンティティデータは国（ISO 3166-1 alpha-2）で論理的に分割されます。プロトコルはすべての Identity Match リクエストとすべての TMPX トークンに国コードを運びます（バイヤーの読み取りレプリカは、データレジデンシールーティングのため暗号化された平文に国を含める — これはバイヤー内部でパブリッシャーやルーターに可視でない）。国が物理的にどうデータベースクラスターにグループ化されるかはデプロイ決定 — プロトコルはそれを制約しない。 パブリッシャーはルーティングディレクティブとして Identity Match リクエストに `country` フィールドを含めます。ルーターはそれを使って `countries` リストがその国コードを含むプロバイダーを選択し、次に転送前にフィールドを剥がします。バイヤーエージェントは決して国を見ません — アイデンティティシグナルではありません。 各プロバイダーエントリは、`countries` と `uid_types` フィールド経由でどの国とアイデンティティタイプを提供するかを宣言します。マルチカントリーのバイヤーはクラスターごとに別々のプロバイダーエントリを運用します（例: 米国に 1 つ、EU 諸国に 1 つ）。これにより、バイヤーはデータレジデンシー要件に準拠し、提供する国のみにパブリッシャーをサブスクライブし、プロトコル変更なしにクラスター間で国を移動できます。 ## TMPX Exposure Tokens TMP は暗号化された露出トークン（TMPX）を使ってフリークエンシーキャッピングのループを閉じます。Identity Match 読み取りレプリカは、解決されたアイデンティティトークンを、クリエイティブトラッキング URL を通じて流れる不透明な TMPX マクロに暗号化します。バイヤーのインプレッションピクセルがトークンを復号しユーザーごとの露出をログします。 ### Encryption TMPX は `mode_base` で HPKE（RFC 9180）を使います: | Parameter | Value | | --------- | --------------------------- | | Mode | `mode_base` — 受信者の公開鍵のみで暗号化 | | KEM | DHKEM(X25519, HKDF-SHA256) | | KDF | HKDF-SHA256 | | AEAD | ChaCha20-Poly1305 | バイヤーのクラスターマスターが受信者秘密鍵を保持します。読み取りレプリカはマスターの公開鍵を使って暗号化します。マスターのみが復号できます。TMPX トークンの偽造は、マスターの公開鍵（公開）とアイデンティティプロバイダー（UID2、ID5、RampID）からの現実的なアイデンティティトークンの両方を要求します — これらを捏造することは詐欺自体より難しい。系統的なフリークエンシー操作は、暗号化層ではなく IVT（Invalid Traffic）層で検出されます。 ### Binary format TMPX 平文はコンパクトなバイナリ構造です。タイプ ID がトークン長を暗黙的に定義します — 長さプレフィックスは不要です。 **ヘッダー（16 バイト）:** | Field | Size | Description | | --------- | ------- | -------------------------------------------- | | Version | 1 byte | フォーマットバージョン（`0x01`） | | Timestamp | 4 bytes | uint32 Unix 秒 — トークン作成時刻 | | Country | 2 bytes | ISO 3166-1 alpha-2、ASCII — アイデンティティデータレジデンシー | | Nonce | 8 bytes | ランダム — マスターでのリプレイ重複排除 | | Count | 1 byte | アイデンティティエントリの数 | **エントリ（繰り返し、バイヤー設定の優先順位順）:** | Field | Size | Description | | ------- | ------- | ----------------------------------- | | Type ID | 1 byte | 固定整数、トークンバイナリサイズを定義 | | Token | N bytes | 生バイナリアイデンティティトークン（サイズは Type ID で決定） | **Type ID レジストリ:** | ID | Token Type | Binary size | | -- | ----------------------- | ---------------------------------------------------------- | | 1 | uid2 | 32 bytes | | 2 | euid | 32 bytes | | 3 | id5 | 32 bytes | | 4 | rampid | 32 bytes | | 5 | rampid\_derived | 48 bytes | | 6 | maid | 16 bytes | | 7 | pairid | 32 bytes | | 8 | hashed\_email | 32 bytes | | 9 | publisher\_first\_party | 32 bytes | | 10 | world\_id\_nullifier | 48 bytes（16 バイトの relying-party ダイジェスト + 32 バイトの nullifier） | Type ID は安定 — 新しいタイプは追加され、既存の ID は決して変わらない。トークンはバイナリで保存される（UUID は 16 バイト、base64 エンコードされたトークンはデコード）。RampID は、維持された（XY、32 バイト）形式と派生された（Xi、48 バイト）形式がサイズで異なるため 2 エントリを持つ。 `world_id_nullifier` は **relying-party スコープ**: そのトークンは、証明の `relying_party_id` の 16 バイト SHA-256 ダイジェストに続く 32 バイトの nullifier。このエントリは **検証済み** アテステーションからのみ生成される — 受信者確認された `rp_id` の下の検証者由来の nullifier（[Verified Identity Attestation](#verified-identity-attestation) を参照）。`identities[]` の送信者アサートの `world_id_nullifier` は信頼を運ばず決して解決も封印もされない。検証済み `rp_id` を欠くため、このトークンさえ形成できない。`uid2`/`id5`/`rampid` とは異なり、エントリはバイヤーが解決するグラフ識別子ではない — 人格証明の仮名で、付随する検証済みアテステーションとともにのみ有効。World ID nullifier はそれが鋳造された `rp_id` 内でのみ意味を持ち、その `rp_id` はリクエスト側の `attestation` に乗り、トークンにラウンドトリップしない。トークンに `rp_id` ダイジェストを運ぶことで、帯域外のインプレッショントラッカーが nullifier をその relying party に帰属させ（受け入れる relying parties に対してダイジェストをマッチング）、`(rp_id, nullifier)` ペアでフリークエンシー状態をキー付けできる。そのため、ある relying party の下の nullifier は別のものとキャップ状態を決して共有しない。トークンは `rp_id` 平文を運ばず、ダイジェスト幅はワーキンググループのオープン項目。 パーサーが未知の Type ID に遭遇した場合、パースを停止し残りのエントリを absent として扱わなければならない（MUST）。ヘッダー Count フィールドは総エントリを示すが、実装はすべてのエントリがパース可能と仮定してはならない（MUST NOT） — 前方互換性は、より新しい Type ID が存在するときの優雅な劣化を要求する。 ### Wire format TMPX マクロ値は `.` 形式を使います。ciphertext はパディングなし base64url エンコーディング（RFC 4648 セクション 5、`=` パディング文字なし）を使わなければなりません（MUST）。パディング文字は `=` がキー値デリミタである URL クエリパラメーターを壊します。`kid`（鍵識別子、最大 8 文字）は不透明 — 地理的またはデプロイ情報をエンコードしてはなりません（MUST NOT）。内部的にクラスターマスター秘密鍵にマップします。 **サイズ予算（255 文字 GAM マクロ制限）:** HPKE オーバーヘッド（48 バイト）とヘッダー（16 バイト）の後、アイデンティティエントリに約 120 バイト残る。3 つの 32 バイトトークン = 99 バイト — 快適に収まる。バイヤーが予算に収まるより多くのアイデンティティを解決するとき、TMPX 平文はバイヤーデプロイ設定に従って最高優先のエントリに切り詰められる。優先順位はバイヤー側の設定の関心事（プロトコルレベルでない）で、通常決定論的グラフ（UID2、RampID）を確率的またはパブリッシャースコープの識別子より上にランク付けする。バイヤーは明示的な優先リストを設定しなければならず（MUST） — デフォルト実装は恣意的に切り詰めてはならない（MUST NOT） — リストはバイヤーの運用ランブックに文書化すべき（SHOULD）。 ### Key management クラスターごとに 1 つの X25519 キーペア: * クラスターマスターが復号のための **秘密鍵** を保持する。 * **公開鍵** は `adagents.json` のエージェント認可エントリの `encryption_keys` に公開される。 * 読み取りレプリカは公開鍵を使って暗号化する。レプリカごとの鍵管理なし。 鍵ローテーションは TMP 署名鍵と同じパターンに従う: 5 分のキャッシュ TTL、バージョニングのための kid プレフィックス、古いマスター鍵の 30 日の猶予期間。 ### Replay protection 8 バイトのランダム nonce がマスターでの重複排除を可能にする。マスターは設定可能なウィンドウ（推奨: 7 日）nonce を保存し重複を拒否する。nonce は AEAD 保護された ciphertext の内側にある — 仲介者はそれを観測できない。 ### Caching behavior TMPX トークンは Identity Match 評価ごとに一度生成され、`serve_window_sec` ウィンドウの間適格性レスポンスに付随する。そのウィンドウ内の適格なパッケージのすべてのインプレッションは同じ TMPX 値（同じ nonce、同じトークン）を共有する。 バイヤーのマスターは、サーブウィンドウ内で TMPX 値や nonce で重複排除してはならない（MUST NOT） — 各ピクセル発火は 1 インプレッション。CTV ポッドまたは複数の広告ユニットを持つ web ページで同じユーザーに提供される複数の広告はすべて、同じ TMPX トークンで distinct なピクセル発火を生成する。nonce 重複排除は、サーブウィンドウが期限切れになった *後* の同じ TMPX トークンのリプレイのみを防ぐ — 同じ nonce が元のウィンドウ外に現れたら、それはリプレイで拒否されなければならない（MUST）。 ### Publisher obligations パブリッシャーは TMPX 値をパース、復号、またはそれに基づいて決定してはならない（MUST NOT）。トークンは、他のマクロと正確に同様にクリエイティブトラッキング URL に代入される不透明なパススルーデータ。DOOH インベントリについては、プレーヤーは露出再照合のためバイヤーに送信される play log レコードに不透明な TMPX 値を含めてもよい（MAY） — パブリッシャーは送信ウィンドウを超えて TMPX 値を保持してはならない（MUST NOT）。 ### Inventory-specific behavior 各ターミナルサーフェスについて、パブリッシャーは各アイデンティティプロバイダーがその `tmpx_macros` 登録エントリで宣言したマクロ名（例: `PIN_TMPX_1`、`NOVA_TMPX_1`）をトラフィックする — それらの名前はアドサーバーラインアイテムがターゲットにする運用コントラクト。提供時に、パブリッシャーはレスポンスから `tmpx_providers[provider_id].macros[]` をたどり、各エントリの `value` を `name` で名付けられたスロットに逐語的に代入する。レガシー `{TMPX}` マクロ（非推奨の単数 `tmpx` フィールドから）は、移行していないコンシューマーのためサポートされたまま。 * **Web、モバイル、CTV（SSAI）、音声（DAI）:** 標準インプレッションピクセル — 各 `tmpx_providers[*].macros[].value` を一致するアドサーバーマクロスロットに代入する。 * **CTV（クライアント側 VAST）:** パブリッシャーは VAST ドキュメントがプレーヤーに到達する前に同じマクロごとの代入を実行する。 * **DOOH:** Play-log ベース — TMPX 値はピクセル URL ではなく DOOH プレーヤーによってログされ play log レコードに含まれる。プロバイダーごとのマクロ/値ペアは、バイヤーが正しい復号マスターにルーティングできるよう、その `provider_id` とともにログされなければならない（MUST）。 ## Transport * HTTP/2 POST 上の JSON。すべての実装はこのトランスポートを使わなければならない（MUST）。 * 各プロバイダーはそのベース URL の下に 2 つのパスベースのエンドポイントを公開する: Context Match の `POST /context` と Identity Match の `POST /identity`。ルーターは、メッセージボディを検査するのではなく、パスでリクエストをディスパッチする。 * 各プロバイダーはそのベース URL で `GET /health` を公開すべき（SHOULD）。エンドポイントは、プロバイダーがリクエストを受け入れる準備ができたとき HTTP `200` を JSON ボディ `{"status": "ok"}` とともに返す。任意の非 `200` レスポンスまたは接続失敗はプロバイダーが準備未完了を意味する。ルーターとオペレーターはこれをプリフライトチェックと監視に使う — リクエストのホットパスでは呼ばれない。 * 各メッセージの `type` フィールドはデシリアライゼーションのためにメッセージを識別する — ルーターとエージェントはそれを、ルーティングではなく正しいスキーマを選択するのに使う。エージェントは `type` フィールドがエンドポイントに一致することを検証しなければならない（MUST）: `/context` の `context_match_request`、`/identity` の `identity_match_request`。不一致は HTTP `400` で拒否されなければならない（MUST）。 * 接続は HTTP/2 多重化経由で再利用すべき（SHOULD）。 * ルーターは各バイヤーエージェントへの接続プールを維持すべき（SHOULD）。 * [adcp-go](https://github.com/adcontextprotocol/adcp-go) SDK がリファレンスクライアントとサーバー実装を提供する。適合性テストが互換性を検証する — 他の言語の実装は同じテストスイートに合格しなければならない（MUST）。 ### HTTP Status Codes TMP はトランスポートレベルのエラーにのみ HTTP ステータスコードを使います。アプリケーションレベルの結果（TMP エラーレスポンスを含む）は常に HTTP `200` で返されます: | HTTP Status | Meaning | | ----------- | -------------------------------------------------------------------- | | `200` | リクエスト処理済み。ボディは TMP レスポンス（成功、空の結果、または TMP エラー）を含む。 | | `400` | 不正な形式のリクエスト（無効な JSON、欠けている `type` フィールド）。TMP レスポンスではない — パースするボディなし。 | | `503` | プロバイダー一時的に利用不可。ルーターはリトライまたはスキップすべき。 | これは、空の `offers` 配列を持つ `200` が有効な「一致なし」レスポンスで、TMP エラーボディ（`"type": "error"`）を持つ `200` が有効なアプリケーションエラーであることを意味します。ルーターは結果にかかわらず 1 つのレスポンス形式を扱います。 ## Latency * TMP は 50ms 未満のエンドツーエンドレイテンシー（publisher → router → agents → router → publisher）をターゲットにする。 * ルーターは、観測されたレイテンシーパーセンタイルに基づいてエージェントごとの適応的タイムアウトを適用すべき（SHOULD）。 * タイムアウトを超えるエージェントは、そのリクエストのマージされたレスポンスから除外される。 * ルーターは、p95 レイテンシーが一貫して予算を超えるエージェントを先制的にスキップしてもよい（MAY）。 ## Caching Context Match レスポンスは、同じパッケージが特定のプレースメントのすべてのユーザーについて評価されるためキャッシュ可能です。推奨キャッシュキーは `{property_rid, placement_id, provider_id}`。 * ルーターは Context Match レスポンスを **5 分** の TTL でキャッシュすべき（SHOULD）。 * プロバイダーは Context Match レスポンスに `cache_ttl` フィールド（integer、秒）を含めてデフォルトを上書きしてもよい（MAY）。ルーターは存在するときこの値を尊重しなければならない（MUST）。 * Identity Match レスポンスは `serve_window_sec`（パッケージごとのシングルショット fcap、最大 300s、デフォルト 60s）で束縛される。ルーターは `{identities_hash, provider_id, package_ids_hash, consent_hash, sealed_credentials_hash}` でキー付けされた内部重複排除キャッシュを適用してもよい（MAY）。ここで `identities_hash` は [Identity Match signed fields](#identity-match-signed-fields) で定義された正準 `identities` バイトの SHA-256（プロバイダーごとにフィルターされたサブセットに対して計算）。`package_ids_hash` はソートされた `package_ids` 配列の JCS シリアライゼーションに対する SHA-256。`consent_hash` はリクエストの `consent` オブジェクトの JCS シリアライゼーション（フィールドが欠如のとき JCS `null` — これは「同意不明」を明示的に空の consent オブジェクトと区別する）に対する SHA-256。`sealed_credentials_hash`（実験的、`trusted_match.verified_identity`）は [Identity Match signed fields](#identity-match-signed-fields) で定義された正準 `sealed_credentials` バイトの SHA-256、または欠如のとき `null` — そのため適格性をシフトさせるネットワーク認証情報の変更が、古いレスポンスを提供するのではなくキャッシュを再分割する。JCS フレーミングがデリミタ注入を防ぐ: `|`、`,`、`\n` を含む生の consent 文字列やパッケージ ID が 2 つの distinct な入力を衝突させられない。アイデンティティセットを含めることは、トークンの追加や削除が distinct なキャッシュエントリを生成することを保証する。パッケージリストハッシュを含めることは、アクティブなパッケージセットが変わるとき（例: 新しいメディアバイがアクティベート）キャッシュされたレスポンスが無効化されることを保証する。consent ハッシュを含めることは、ある consent 状態の下で取られた適格性決定が別の下で提供されるのを防ぐ。パブリッシャーの拘束コントラクトは、ルーターの内部キャッシュウィンドウではなくサーブウィンドウスロットル。 * プロバイダーのターゲティング設定が変わるとき（新しいパッケージ、更新されたターゲティングルール）、プロバイダーは変更が伝播するまで `"cache_ttl": 0`（Context Match）または `"serve_window_sec": 1`（Identity Match）を返し、その後通常値を再開すべき（SHOULD）。 * `cache_ttl`（Context Match）はスキーマ強制の最大 86400 秒を持つ。`serve_window_sec` は 300 秒に束縛される — より長いウィンドウはパッケージごとの fcap を典型的なキャンペーンに粗すぎにし、IdentityMatch 往復より短いものはスロットルを無駄にする。 ## Conformance Levels ### TMP Buyer Agent (Basic) * `context_match` ケイパビリティをサポート * ContextMatchRequest に有効な ContextMatchResponse で応答 * レイテンシー予算を満たす（エージェント側処理で p95 \< 30ms） * プライバシー制約を尊重する（他のソースからのアイデンティティデータでリクエストをログまたは相関しない） ### TMP Buyer Agent (Full) Basic のすべて、加えて: * `identity_match` ケイパビリティをサポート * IdentityMatchRequest に有効な IdentityMatchResponse（適格なパッケージ ID + TTL）で応答 * プロダクトが一致する `response_types` を宣言するときリッチなオファー（ブランド、価格、summary、クリエイティブマニフェスト）をサポート ### TMP Router (Basic) * プロバイダーエンドポイントで設定 * Context Match と Identity Match を認可されたプロバイダーにファンアウト * レスポンスをマージ * エンドツーエンドレイテンシー予算を満たす（p95 \< 50ms） ### TMP Router (Trusted) Basic のすべて、加えて: * TEE アテスト済み環境（例: AWS Nitro Enclaves）で実行 * リクエストに応じてアテステーションドキュメントを提供し、デプロイされたバイナリが公開されたソースに一致することを証明 * コンテキストとアイデンティティのコードパス間の構造的分離がアテステーション測定経由で検証可能