feat(schema): trust.json v1 identifies agents by origin and carries no keys

.changeset/trust-json-origin-identity.md

@@ -0,0 +1,5 @@
+---
+"adcontextprotocol": minor
+---
+
+trust.json v1 (experimental): an agent is identified by the canonical origin of its `url`, one agent per origin, and every agent URL in the record (agents, grant narrowing, acknowledgements) matches by origin. The record carries no keys. Remove `agents[].jwks_uri` and its `/.well-known/jwks.json` default (keys come from the Web Bot Auth key directory at the agent's origin), and drop the planned `identity.trust_url` back-pointer. Define "canonical origin" once in `url-canonicalization.mdx`, with a Form column in its "Where it applies" table. Examples move to one origin per agent, and a validator for the one-agent-per-origin and acknowledgement rules, using the SDK's canonicalization, runs in `npm run test:schemas`. Nothing consumes trust.json yet. See `specs/agent-identity-3-3.md` and #8118.

docs/reference/experimental-status.mdx

@@ -124,7 +124,7 @@ Schemas marked with `x-status: experimental` are the authoritative source. The c
 | `media_buy.reporting_delivery` | **Reliable Reporting 1.0**: [`get_reporting_status`](/docs/media-buy/task-reference/get_reporting_status), opt-in [`sync_reporting_status`](/docs/media-buy/task-reference/sync_reporting_status), [`sync_reporting_receipts`](/docs/media-buy/task-reference/sync_reporting_receipts), `sync_accounts.reporting_delivery_configs[]`, reporting notifications, and the `media_buy.reporting_delivery` capability block | Proper-name AdCP 3.2 reporting reliability surface (#6911), explicitly discovered through `reliable_reporting_version: "1.0"`. Core, Managed Delivery, and Reconciled Billing have separate capability-gated conformance storyboards. The [consumer-status migration](/docs/reference/migration/reliable-reporting-status-loop) is an active breaking-change notice: current source adds an opt-in task, which becomes required Core only in the next eligible minor after October 24, 2026. Its `content_mismatch` status, stale-`received` grace window, buyer posting deadline, issue lifecycle fields, escalation contact, and the reserved `authoritative_party` field ([#7440](https://github.com/adcontextprotocol/adcp/issues/7440)) are all additive within that experimental surface. [Superseded snapshot compaction](/docs/reference/migration/3-2-to-3-3#superseded-reporting-snapshots-may-be-compacted) ([#8081](https://github.com/adcontextprotocol/adcp/issues/8081)) is a second active breaking-change notice: sellers may compact older superseded snapshot content only in the next eligible minor after November 20, 2026. Multi-party production operation and provider-specific compatibility still need implementation experience before freezing. |
 | `creative.broadcast_loudness` | The optional `loudness` object (`target_lufs`, `tolerance_db`, `max_true_peak_dbfs`, `standard`) on the `video_hosted` canonical format params (schema: `formats/canonical/video_hosted.json`), documented in [Broadcast creative](/docs/creative/channels/broadcast#loudness-experimental) (#8011) | New broadcast-television delivery requirement with very few adopters so far. The `standard` enum (`ebu_r128`, `atsc_a85`, `custom`) is expected to grow, and the object shape may be reconciled with the flat `loudness_*` fields on `audio_hosted` in a later 3.x release. The `mxf` container and the `mpeg2` / `avc_intra` / `xavc` codec values added alongside it are stable additive enum values, not part of this experimental surface. |
 | `media_buy.daypart_granularity` | The `start_time` / `end_time` clock-time fields on `core/daypart-target.json` (and so on every `daypart_targets` entry), the `time_granularity` field in `overlay_support.daypart_targets` and `required_overlay_support.daypart_targets`, and the `enums/daypart-time-granularity.json` enum ([#6707](https://github.com/adcontextprotocol/adcp/issues/6707)). See [Minute-resolution dayparts](/docs/media-buy/advanced-topics/targeting#minute-resolution-dayparts-experimental). | Minute-level schedules for linear TV (programme-junction breaks, overnight broadcast days) arrive with one named adopter and are expected to be reshaped by the network/station targeting work in [#5679](https://github.com/adcontextprotocol/adcp/issues/5679). The `HH:MM` representation, the overnight rule (a window belongs to its start day), the three-value granularity ladder, and the error code for an unsupported granularity (today `UNSUPPORTED_FEATURE`, which may be superseded by the targeting-dimension codes in [#6978](https://github.com/adcontextprotocol/adcp/issues/6978)) may change before they freeze. The whole-hour `start_hour` / `end_hour` fields stay stable, although they are no longer individually schema-required. |
-| `identity.trust_json` | The `trust/v1/trust.json` and `trust/v1/trust-acknowledgements.json` schemas, described in [trust.json (experimental)](/docs/reference/trust-json) ([RFC #7809](https://github.com/adcontextprotocol/adcp/issues/7809), [#7819](https://github.com/adcontextprotocol/adcp/pull/7819)). **Schemas only: nothing consumes this in 3.3.** No task, capability field, resolver, or storyboard reads it, there is no `identity.trust_url` capability field, `brand.json` behavior is unchanged, and no one is required to publish `/.well-known/trust.json`. Because no seller implements anything from this surface, there is nothing to declare in `experimental_features`: publishing a `trust.json` is not implementing this surface, and declaring `identity.trust_json` has no defined meaning until a consumer lands. | The document shape for agents, keys, grants, and acknowledgements is published ahead of the behavior that would use it, so implementers can review it. The document name and its `/.well-known` path may change before graduation: the JournalList `trust.txt` naming outreach is still open. Resolver precedence, no-downgrade rules, and the capability pointer are planned for a later release and may reshape the fields. |
+| `identity.trust_json` | The `trust/v1/trust.json` and `trust/v1/trust-acknowledgements.json` schemas, described in [trust.json (experimental)](/docs/reference/trust-json) ([RFC #7809](https://github.com/adcontextprotocol/adcp/issues/7809), [#7819](https://github.com/adcontextprotocol/adcp/pull/7819)). **Schemas only: nothing consumes this in 3.3.** No task, capability field, resolver, or storyboard reads it, there is no `identity.trust_url` capability field, `brand.json` behavior is unchanged, and no one is required to publish `/.well-known/trust.json`. Because no seller implements anything from this surface, there is nothing to declare in `experimental_features`: publishing a `trust.json` is not implementing this surface, and declaring `identity.trust_json` has no defined meaning until a consumer lands. | The document shape for agents, grants, and acknowledgements is published ahead of the behavior that would use it, so implementers can review it. Agents are identified by origin, one per origin, and the record carries no keys ([`specs/agent-identity-3-3.md`](https://github.com/adcontextprotocol/adcp/blob/main/specs/agent-identity-3-3.md)). The document name and its `/.well-known` path may change before graduation: the JournalList `trust.txt` naming outreach is still open. The record's location is derived from the agent's origin, so no capability pointer is planned. Resolver and no-downgrade rules land with the first consumer and may reshape the fields. |
 
 Graduation progress and notice of upcoming breaking changes will be called out in the [release notes](/docs/reference/release-notes) for each 3.x release starting with 3.0 GA.
 

docs/reference/trust-json.mdx

@@ -17,7 +17,7 @@ description: "Experimental trust.json v1 schemas, shipped in AdCP 3.3 as schemas
 |---|---|
 | Feature id | `identity.trust_json` (see [experimental status](/docs/reference/experimental-status#current-experimental-surfaces)) |
 | Schemas | `trust/v1/trust.json`, `trust/v1/trust-acknowledgements.json`; both carry `x-status: experimental` |
-| Capability field | None. `identity.trust_url` is not part of 3.3 |
+| Capability field | None, and none is planned: the record's location is derived from the agent's origin |
 | Name and path | May change before graduation |
 | `v1` in the path | A path namespace, not a stability promise. While the schemas are experimental they may change in breaking ways |
 
@@ -27,11 +27,11 @@ Because no seller implements a task or capability from this surface, there is no
 
 ## What the schemas describe
 
-The record answers one question: which agents does this organization run, with which keys, who may act for it, and whose grants does it accept. The core is protocol-neutral. Roles and scopes are namespaced tokens such as `adcp:sales`, and AdCP defines the `adcp` namespace as the first profile.
+The record answers one question: which agents does this organization run, who may act for it, and whose grants does it accept. The core is protocol-neutral. Roles and scopes are namespaced tokens such as `adcp:sales`, and AdCP defines the `adcp` namespace as the first profile.
 
 | Field | Purpose |
 |---|---|
-| `agents[]` | Agents the organization runs: `url`, namespaced `roles`, optional `protocols`, `jwks_uri`, `countries`, and per-protocol `profiles` |
+| `agents[]` | Agents the organization runs: `url`, namespaced `roles`, optional `protocols`, `countries`, and per-protocol `profiles`. One agent per origin, and no keys |
 | `grants[]` | Authority the organization delegates: `grantee` domain, optional `agents[]` narrowing, namespaced `scopes`, `countries`, `valid_from` and `valid_until`. Grants never carry keys |
 | `exclusive_grants` | When true, `grants[]` is exhaustive for the scopes it names |
 | `acknowledgements[]` or `acknowledgements_url` (not both) | Grants the organization accepts, by reference: `grantor`, `agent_url`, and `via`. Terms stay in the grantor's document |
@@ -54,8 +54,7 @@ A publisher that runs one sales agent. Validated against the schema:
     {
       "url": "https://ads.streamhaus.example/mcp",
       "roles": ["adcp:sales"],
-      "protocols": ["mcp"],
-      "jwks_uri": "https://ads.streamhaus.example/.well-known/jwks.json"
+      "protocols": ["mcp"]
     }
   ]
 }
@@ -79,7 +78,7 @@ A brand house that delegates authority and runs no agents. A grant names a grant
     {
       "grantee": "sentinel-governance.example",
       "scopes": ["adcp:governance"],
-      "agents": [{ "url": "https://gov.sentinel-governance.example/t/7f3a9c" }]
+      "agents": [{ "url": "https://7f3a9c.sentinel-governance.example/mcp" }]
     }
   ]
 }
@@ -93,9 +92,8 @@ An ad network that accepts publisher grants by reference, with the bulk entries
   "last_updated": "2026-09-30T00:00:00Z",
   "agents": [
     {
-      "url": "https://northwind.example/mcp/streamhaus",
-      "roles": ["adcp:sales"],
-      "jwks_uri": "https://keys.northwind.example/jwks/streamhaus.json"
+      "url": "https://streamhaus.northwind.example/mcp",
+      "roles": ["adcp:sales"]
     }
   ],
   "acknowledgements_url": "https://northwind.example/.well-known/trust-acknowledgements.json"
@@ -109,19 +107,25 @@ An ad network that accepts publisher grants by reference, with the bulk entries
   "acknowledgements": [
     {
       "grantor": "streamhaus.example",
-      "agent_url": "https://northwind.example/mcp/streamhaus",
+      "agent_url": "https://streamhaus.northwind.example/mcp",
       "via": "adcp:adagents",
       "profiles": { "adcp": { "delegation_type": "delegated" } }
     }
   ]
 }
 ```
 
+## Identity and keys
+
+An agent is identified by the [canonical origin](/docs/reference/url-canonicalization#canonical-origin) of its `url`, and every agent URL in the record (agents, grant narrowing, acknowledgements) matches by origin. A record lists at most one agent per origin. A vendor that runs an agent per tenant gives each tenant its own subdomain, as the examples above do. The schema cannot express the one-agent-per-origin rule, so validators check it separately.
+
+The record carries no keys. An agent publishes its signing keys in the Web Bot Auth key directory at its own origin, `/.well-known/http-message-signatures-directory`. The record also carries no key pin: a second list of keys would break Web Bot Auth key rotation, where a new key is published alongside the old one. This follows the design in [`specs/agent-identity-3-3.md`](https://github.com/adcontextprotocol/adcp/blob/main/specs/agent-identity-3-3.md) (tracking issue [#8118](https://github.com/adcontextprotocol/adcp/issues/8118)). Until a consumer lands, these rules describe the document shape only.
+
 ## What is not in 3.3
 
 These are planned for a later release and are deliberately absent. The MUST and SHOULD wording in the schema descriptions records the intended design for them and is not enforced by anything today.
 
-- The `identity.trust_url` capability field.
+- Resolution from an agent's origin to its trust record. The planned design derives the record's location from the origin, so there is no `identity.trust_url` back-pointer.
 - Resolver changes, the agent-to-trust-record binding, precedence over `brand.json`, and no-downgrade rules.
 - Storyboard dual-source modes and the seller-setup rewrite.
 - Any requirement to publish `/.well-known/trust.json`.