> ## 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.
# セラー検証
> バイヤーが馴染みのないセラーをエンドツーエンドでどう検証するか — brand.json、adagents.json、リクエスト署名を 1 つのチェーンとして、チェーンが証明しないものについての境界された正直さとともに。
`get_products` レスポンスがちょうど Sam のオーケストレーターにヒットしました。セラー — Northwind Media — は Acme Outdoor が乗りたいスポーツネットワーク StreamHaus 全体で CTV 在庫を見積もりました。CPM は公正に見え、アベイルはフライトに合い、レスポンスは 1 秒未満で到着しました。
Sam は Northwind とトランザクションしたことがありません。このレスポンスに署名したエージェントが実際に StreamHaus 在庫を販売する認可を受けているか、StreamHaus が彼が認識する親ハウスの下の実パブリッシャーか、賢い攻撃者が先週 `northw1nd.example` を登録し \$25,000 を持ち去ろうとしているかを知りません。
彼は Northwind にセールスデッキで説得してもらう必要はありません。プロトコルにコードでチェーンを検証可能にしてもらう必要があります — レスポンスの署名鍵から、Northwind のブランドアイデンティティを通じて、StreamHaus の認可へ、彼が認識できる親ハウスに戻るまで、すべてのリンク。彼のバイヤーエージェントはチェーンを自動的に歩きます。Sam は判定を読みます。
このウォークスルーはそのチェーンを Sam の目を通じてたどります。
**これが検証するものとしないもの。** チェーンは *誰が販売する認可を受けているか* に答えます。それは *エージェントの背後の法人が誰か*（KYC、実オペレーター）、*アベイルが配信時に現実を反映するか*（カタログ精度、CPM、配信）、*ホスティングインフラが信頼できるか*（DNS、CDN、レジストラ）には答えません。[境界された正直さステップ](#step-5-know-what-the-chain-does-not-prove) がすべての制限を明示的に名指します。これは在庫に適用された C2PA の「クレーム非認証」姿勢です — プロトコルは認可クレームを運びそれを検証可能にし、そこで止まります。
## 一目でわかるチェーン
3 つの発見可能な表面と 1 つの暗号チェック。Sam のエージェントは都合のよい順序でそれらを実行します:
| Surface | Source | Question it answers |
| --------------- | ---------------------------------------------- | --------------------------------------- |
| RFC 9421 署名 | レスポンスヘッダー | 「このレスポンスは主張する鍵から来たか?」 |
| `brand.json` | `northwind.example/.well-known/brand.json` | 「Northwind は誰で、何を代表すると主張しているか?」 |
| `adagents.json` | `streamhaus.example/.well-known/adagents.json` | 「パブリッシャーは Northwind に在庫を販売する認可を与えているか?」 |
| 相互主張 | 両 `brand.json` ファイルのクロス参照 | 「関係の 2 つの側は一致するか?」 |
チェーンは設計上双方向です: 各事実はそれに対する権限を持つちょうどその当事者によって主張されます。パブリッシャーが誰が在庫を販売できるか決定します。ブランドオーナーが何を所有するか決定します。セラーがどの鍵がレスポンスに署名するか決定します。第三者レジストリがそれらの間を裁定しません — 誤動作する認可されたセラーは、プロトコル内クレームチェックではなく、パブリッシャーが `adagents.json` エントリーを取り消すことで修復されます。
下の 4 ステップのうち 1 つのみが暗号的に基礎付けられています（署名）。他の 3 つは整合性チェックされた発見です — well-known な場所の権威ファイルに対する文字列等価マッチ。チェーンは、パブリッシャーとセラーの自身の DNS、ホスティング、well-known エンドポイントの制御と同じだけ強いです。それが含意するものについては [Step 5](#step-5-know-what-the-chain-does-not-prove) を参照。
## ステップ 1: レスポンス署名を検証
`get_products` レスポンスは RFC 9421 `Signature` と `Signature-Input` ヘッダーを運びます。`keyid` パラメーターは Northwind の公開された JWKS の JWK を指します。Sam のクライアントはボディを解析する前に署名を検証します:
```javascript theme={null}
const response = await fetch("https://northwind.example/mcp", { /* get_products call */ });
const verified = await verifyMessageSignature(response, {
fetchJwks: (keyid) => fetchJwksForAgent("northwind.example", keyid),
requiredFields: ["@method", "@target-uri", "content-digest", "@authority"],
requireCreated: true, // RFC 9421 `created` parameter MUST be present
maxAge: 300, // seconds — receiver MUST enforce a window
});
if (!verified) throw new Error("signature failed — discard response");
```
パスは Sam に 1 つの狭いことを伝えます: `keyid` とペアの秘密鍵を保持するエンティティがこのレスポンスを生成し、レスポンスは転送中に改ざんされていない。それはまだ `keyid` が正当な Northwind に属することを伝えません。そのバインディングはステップ 3 の `adagents.json` から来ます。
署名が失敗すると、他のすべてのチェックは無駄な作業です — レスポンスは自身を正しく識別することさえ信頼できません。最初に検証することはまた Sam にクリーンな中止を与えます: 任意のビジネスロジックがそれに触れる前にレスポンスを破棄します。
`maxAge` と `requireCreated` はオプションではありません — 鮮度ウィンドウなしでは同じ署名付きレスポンスが無期限にリプレイされうる。`maxAge` をクロックスキュー予算にチューニング。300s が一般的な出発点です。
AdCP 3.0 では、`get_products` の署名は RECOMMENDED です。支出コミット操作の必須署名は 4.0 に向けて [#2307](https://github.com/adcontextprotocol/adcp/issues/2307) で追跡されます。今日署名を要求するデプロイはそれをプラットフォーム層で強制します。
## ステップ 2: Northwind の brand.json を読む
Sam のエージェントは `https://northwind.example/.well-known/brand.json` をフェッチします。これは Northwind の自己宣言です: それが誰で、署名鍵がどこに存在するか。
```json theme={null}
{
"$schema": "/schemas/brand.json",
"version": "1.0",
"id": "northwind_media",
"names": [{ "en_US": "Northwind Media" }],
"url": "https://northwind.example",
"keller_type": "master",
"industries": ["advertising"],
"agents": [
{
"type": "sales",
"id": "northwind_sales",
"url": "https://northwind.example/mcp",
"jwks_uri": "https://northwind.example/.well-known/jwks.json"
}
]
}
```
ここで 2 つが重要:
1. **ステップ 1 の `keyid` は `https://northwind.example/.well-known/jwks.json` で解決しなければならない** — Northwind 自身の brand.json が指す JWKS。Sam は今や署名から自己宣言のブランドアイデンティティへのバインディングを持ちます。
2. **Northwind はスタンドアロンエージェンシー** — `house_domain` フィールドなし。Northwind 側で検証する親ハウスクレームはありません。重要な認可クレームはパブリッシャー側、ステップ 3 に存在します。
`brand.json` はそれが記述するエンティティによって HTTPS 上で公開されます。生のフィールドをまずスキーマ検証せずに LLM プロンプトにパイプするバイヤーエージェントは、相手方から敵対的入力を取っています。解析前に [brand.json スキーマ](/docs/brand-protocol/brand-json) に対して検証し、攻撃者制御の文字列フィールド（`names`、`description`、カスタムキー）をサニタイズなしに LLM コンテキストに決して渡さないでください。
## ステップ 3: StreamHaus の adagents.json に対して確認
Sam のエージェントは `https://streamhaus.example/.well-known/adagents.json` をフェッチします — 誰が在庫を販売する認可を受けているかのパブリッシャー自身の宣言:
```json theme={null}
{
"$schema": "/schemas/adagents.json",
"contact": {
"name": "StreamHaus Publishing",
"email": "adops@streamhaus.example",
"domain": "streamhaus.example"
},
"properties": [
{
"property_id": "streamhaus_ctv",
"property_type": "ctv_app",
"name": "StreamHaus CTV App",
"publisher_domain": "streamhaus.example",
"identifiers": [{ "type": "roku_store_id", "value": "12345" }]
}
],
"authorized_agents": [
{
"url": "https://northwind.example/mcp",
"authorized_for": "StreamHaus CTV inventory via delegated authority",
"authorization_type": "property_ids",
"property_ids": ["streamhaus_ctv"],
"delegation_type": "delegated",
"signing_keys": [
{
"kid": "northwind-sell-prod-2026",
"kty": "OKP",
"alg": "EdDSA",
"crv": "Ed25519",
"x": "Xe2lAKRJR_zr3FQRdSNwp3zsrv_IXnVCWJXDcWXwkLI",
"use": "sig"
}
]
}
],
"last_updated": "2026-04-12T10:00:00Z"
}
```
これが双方向ロックです:
* **`url` が一致** Northwind の `brand.json` が `agents[].url` で名指した MCP エンドポイントと。両側で同じエージェント。
* **`delegation_type: "delegated"`** が商業関係を宣言 — Northwind は StreamHaus に代わって販売する認可を受けている。enum は `direct | delegated | ad_network`。パブリッシャーがどれが合うか選ぶ。
* **`signing_keys[]`** が、その `kid` がステップ 1 の署名で使われたものに一致する JWK を含む。これが Sam が欠いていたリンクです: パブリッシャーの StreamHaus が、自身のファイルでこの特定の公開鍵が自身に代わって署名できると証明します。
今や Sam は「誰が販売する認可を受けているか」の答えを持ちます: **このレスポンスに署名したエンティティはパブリッシャー自身の認可ファイルで、一致する商業関係と明示的な署名鍵認可とともに名指されている**。チェーンが閉じました。
ブランドプロトコルの [相互主張モデル](https://github.com/adcontextprotocol/adcp/issues/3533) は、Sam の下流ロジックが行動できる離散シグナルを生成します:
| State | Meaning | Buyer action |
| ------------------ | ----------------------------------------------------- | -------------------------------------------- |
| `inline` | セラーがブランドオーナー — 委譲が関与しない | 進む。委譲するものなし |
| `mutual_assertion` | 両側が一致する宣言を公開 | 進む |
| `one_sided_brand` | セラーの brand.json がパブリッシャーを主張。パブリッシャーが相互にしていない | **認可として扱わない。** 任意のドメインが任意のパブリッシャーを一方的に主張できる。 |
| `one_sided_house` | パブリッシャーの adagents.json がセラーを名指す。セラーの brand.json が認めない | 人間レビューのため保留 |
| `standalone` | どちらの側も公開しない — bearer トークン信頼のみ | 帯域外認可または拒否 |
Sam のチェーンは `mutual_assertion` に解決します — inline に次ぐ最強の状態。`inline` と `mutual_assertion` のみがチェーンを閉じます。
## ステップ 4: 親ハウスを歩く
Acme Outdoor の包含リストは親ハウスレベルで解決します — 彼らは Sportshaus Holdings のブランドファミリーを信頼します。StreamHaus はサブブランドなので、Sam のエージェントは 1 ホップさらに歩きます。
StreamHaus 自身の brand.json がその親を宣言します:
```json theme={null}
{
"$schema": "/schemas/brand.json",
"version": "1.0",
"id": "streamhaus",
"names": [{ "en_US": "StreamHaus" }],
"url": "https://streamhaus.example",
"house_domain": "sportshaus-holdings.example",
"keller_type": "endorsed",
"industries": ["media", "broadcasting"]
}
```
次に親の brand.json が相互にします:
```json theme={null}
{
"$schema": "/schemas/brand.json",
"version": "1.0",
"house": {
"domain": "sportshaus-holdings.example",
"name": "Sportshaus Holdings",
"architecture": "branded_house"
},
"brand_refs": [
{ "domain": "streamhaus.example", "brand_id": "streamhaus", "effective_at": "2025-01-01T00:00:00Z" },
{ "domain": "courtsidehq.example", "brand_id": "courtsidehq" }
]
}
```
相互性ルール: **StreamHaus の `house_domain` ↔ Sportshaus Holdings の `brand_refs[].domain`**。両側が一致します。
このステップに 2 つの別個の概念が乗り、文書はそれらを混同しないよう注意します:
* **子の `keller_type`**（`endorsed`）はブランドアーキテクチャ関係を記述 — サブブランドが親の隣にどう位置付けられるか。それは Keller アーキテクチャメタデータで、商業認可ではありません。
* **Northwind が販売できるようにする商業関係** はステップ 3 の `delegation_type: "delegated"` で、親ハウスではなくパブリッシャー（StreamHaus）に存在します。
Sportshaus Holdings は Acme Outdoor の包含リストにあります。Sam のエージェントがちょうど歩いたチェーンは: 署名付きレスポンス → Northwind の `brand.json` → StreamHaus の `adagents.json` → StreamHaus と Sportshaus Holdings の相互 `brand.json` 宣言。4 つの発見可能な表面、1 つの暗号アンカー、認可質問のための電話ゼロ。
## Step 5: Know what the chain does not prove
認可チェーンが閉じました。Northwind は初めて Acme Outdoor が実際に意味ある支出でトランザクションする相手方なので、Sam は電話を取ります。プロトコルのためではありません — チェーンは伝えられることを彼に伝えました。チェーンが伝えられないすべてのために。
| The chain proves | The chain does not prove |
| -------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------ |
| Northwind は `delegated` 関係の下で StreamHaus 在庫を販売する認可を受けている | Northwind の実際の人間がこのエージェントを運用しそれに答える |
| 署名鍵はセラーとパブリッシャーの両方によって名指されている | その鍵の背後のオペレーターが Sam が信頼する誰かによって KYC された |
| StreamHaus は Sportshaus Holdings を親として宣言し、親が相互にする | 法的相手方が Sam がトランザクションしていると思う相手に一致する |
| レスポンスは転送中に改ざんされなかった | レスポンスのアベイルがフライト開始日に利用可能である、または見積もられた CPM が保持される |
| Northwind のドメインは今日署名鍵を制御する | 鍵が明日攻撃者にローテートできない — 初回遭遇信頼は [鍵透明性](https://github.com/adcontextprotocol/adcp/issues/3925) が 4.0 で到達するまで TOFU |
そのテーブルの右側に 3 つの名指しされたギャップが存在します。
**人間層ギャップ。** AdCP はオペレーター/人間 KYC プリミティブを運びません。暗号チェーンは「このドメインは販売する認可を受けており、この鍵がこのレスポンスに署名した」と言います — 「検証された会社の検証された人間がこのエージェントの反対側にいる」とは言いません。KYC はメンバーシップとアカウント層です。Acme のしきい値を超える新しい相手方には、Sam は依然として、任意の意味ある新ベンダーに対してするのとまったく同様に人間チェックにエスカレートします。
**ホスティング層ギャップ。** チェーンは `northwind.example`、その DNS、TLS、CDN を制御する誰でも信頼します。レジストラ乗っ取り、CDN 侵害、誤発行された TLS 証明書はチェーン全体を置き換えます — 攻撃者が有効に見えるパイプライン上で攻撃者制御の `brand.json`、`adagents.json`、JWKS をサーブします。3.x に公開鍵透明性ログはありません。初回遭遇信頼は trust-on-first-use で、失効は再フェッチによってのみ検出可能です。以前 Northwind とトランザクションしたバイヤークライアントは見た `kid` をピン留めしローテーションで警告します。初回遭遇のバイヤークライアントはそのシグナルを持ちません。[#3925](https://github.com/adcontextprotocol/adcp/issues/3925) を参照。
**配信時ギャップ。** カタログ精度はプロトコル証明されません。パブリッシャーは個別の製品エントリーに署名せず、製品ごとの証明は在庫が本番でどう運用されるかに一致しません — 予測はドリフトし、価格は動き、供給は動的です。誤動作する認可されたセラーは、プロトコル内クレームチェックではなく、パブリッシャーが `adagents.json` エントリーを取り消すことで修復されます。配信時の真実は [測定](https://github.com/adcontextprotocol/adcp/issues/2391) と課金照合に存在します。
これは C2PA の「クレーム非認証」姿勢です。プロトコルは認可クレームを運びそれを暗号的に検証可能にします。それは — そしてプロトコル層ではすべきでない — 任意の意味ある新相手方に対してバイヤーがする人間層、ホスティング層、配信層のチェックを置き換えません。
## Sam が次にすること
Sam のクライアントは、決定時にキャプチャした `brand.json`、`adagents.json`、JWKS バイトを含めて — ライブファイルへのポインターだけでなく — `get_products` レスポンスとともに検証結果をログします。数か月後、監査人はそれらのキャプチャされたアーティファクトに対して署名を再検証し Sam の決定を正確に再現できます。ライブ `.well-known/` ファイルの再フェッチは不十分です — それらは可変で、単一の鍵ローテーションまたはドメイン移転が素朴なリプレイを無効化します。
検証結果と 5 状態トラストシグナルは候補プランとともに Sam の [ガバナンスフロー](/docs/governance/overview) に移動し、そこで Jordan のガバナンスエージェントが任意の支出がコミットされる前に Acme のポリシーチェックを適用します。
## ここからどこに行くか
* [brand.json リファレンス](/docs/brand-protocol/brand-json) — 自己宣言、親ハウスポートフォリオ、Keller アーキテクチャメタデータの完全なスキーマ
* [セラーセットアップ](/docs/brand-protocol/seller-setup) — パブリッシャー、ネットワーク、SSP がセラーアイデンティティと認可ファイルをどう公開するか
* [adagents.json リファレンス](/docs/governance/property/adagents) — パブリッシャー側認可、`authorization_type` 判別子、`signing_keys[]` JWK 形状
* [verify\_brand\_claim](/docs/brand-protocol/tasks/verify_brand_claim) — 検証をブランドエージェントに委譲する Tier-2 実装者ガイド
* [セキュリティモデル](/docs/building/concepts/security-model) — 三者ガバナンスとトラスト姿勢
* [リクエスト署名](/docs/building/by-layer/L1/request-signing) — RFC 9421 詳細、鍵ローテーション、透明性ログロードマップ
* [トラスト & セキュリティ](/docs/trust) — CISO 向け表面マップ。このウォークスルーはバイヤー向けの相棒
* [AAO Verified](/docs/building/verification/aao-verified) — 上のアイデンティティチェーンの上に層化された継続的動作適合性証明