Trust model for cross-agent claims (buyer-side attestation and history)

[bokelley]

Problem

#2392 addressed the sell-side trust gap: how does a buyer verify a seller's
inventory claims. The symmetric gap on the buy-side remains open.

When a buyer agent presents itself to a seller — claiming budget authority,
brand representation, audience-quality signals, or measurement preferences —
there is no protocol-level mechanism for the seller to evaluate those claims
beyond bearer-token auth and (post-#2307) request-origin authentication.

The risk is concrete: low-trust or adversarial buyer agents are a foreseeable
attack surface. Sellers need a way to evaluate buyer claims; the protocol
should make those claims legible and portable without designating which
sources are "valid."

Anti-goal

The protocol MUST NOT designate trust providers, mandate specific attestation
issuers, or maintain a canonical list of "recognized" trust bodies. Any such
list re-creates the centralization problem it would purport to solve and
disadvantages markets where the named providers do not operate.

Trust evaluation is a seller-policy decision, not a protocol decision.

Proposed primitives

1. Attestation envelope. A signed structure carrying:

   • issuer (typed; see enum below)
   • claim_type (identity, audience, measurement, brand-representation, etc.)
   • payload (issuer-defined claim contents)
   • signature (composes with Mandatory request signing for mutating calls (RFC 9421 HTTP Signatures or JWS) #2307 / RFC 9421)
   • validity (issued_at, expires_at, revocation pointer)

2. Open issuer enum, following the precedent of
   static/schemas/source/enums/metro-system.json:

   • Recognized issuer schemes are enumerated for interop
   • self is a first-class issuer (signed first-party history is a claim a
     buyer agent makes about itself)
   • custom escape hatch for issuers the protocol has not formally listed
   • Adding a recognized issuer to the enum does not endorse it — it makes
     the claim legible

3. Self-attestation via signed transaction history. A buyer agent with a
   long, signed, auditable record is its own attestation. The protocol's job
   is to make that history portable and verifiable, not to require it be
   witnessed by a third party.

Design precedent

The geo metro-system enum already ships a "federation of regional
standards" pattern: Nielsen DMA, UK ITL1/2, Eurostat NUTS2, plus custom.
The protocol does not pick a winner; it ensures both sides know which
taxonomy a value belongs to. Attestation issuers take the same shape.

Motivating examples

• Joint Industry Committees (BARB / Médiamétrie / AGF / forthcoming
  JIC US) — concrete, federated-by-construction issuers that sellers in
  those markets will weight heavily. The protocol must be able to carry
  their attestations; it must not require them.
• MRC accreditation — relevant in US measurement contexts where no
  JIC exists.
• First-party signed history — the cold-start fallback for new
  entrants and the steady-state anchor for established agents.

Each market reaches its own equilibrium on which issuers carry weight.
That divergence is the market working, not a bug to harmonize away.

Explicit non-requirements

• Cross-border or cross-market buying MUST NOT require any specific issuer
• A market without a JIC (or equivalent) MUST NOT be locked out of
  participation
• Audit cadence, revocation policy, and issuer governance are out of scope
  for the protocol — those are issuer-side concerns

Composition

• Builds on Mandatory request signing for mutating calls (RFC 9421 HTTP Signatures or JWS) #2307 (RFC 9421 request signing) — signing primitive
• Sibling to 3.1: Trust model for cross-agent claims (seller inventory verification) #2392 (sell-side claim verification) — symmetric trust direction
• Complementary to existing `brand.json` / `adagents.json` principal-of-
  record machinery

Proposed output

1. Schema additions: attestation envelope + issuer enum
2. Doc updates: extend `trust-model.mdx` (or sibling doc) with the buy-side
   half of the story
3. Reference implementation: at least `self` and one third-party issuer
   wired end-to-end in conformance fixtures

Disposition

Target: 3.1.0 alongside the post-#2392 trust-model work.