feat(compliance): resolve and verify seller acceptance-policy catalogs

[bokelley]

Summary

Add the JavaScript SDK buyer resolver and compliance-runner support for the seller acceptance-policy discovery contract in adcontextprotocol/adcp#6749 and adcontextprotocol/adcp#6794.

The protocol repository now publishes and exercises an in-band capability plus a real digest-matched reference catalog. The remaining SDK responsibility is safely resolving the advertised HTTPS catalog and turning its profiles into useful buyer guidance.

Buyer SDK behavior

• Fetch media_buy.acceptance_policy_discovery.catalog_url under the protocol's remote-resolution rules: HTTPS only, no URL credentials, public-address/DNS pinning, no redirects, bounded response bytes and wall time.
• Verify catalog_digest against the exact response bytes before parsing.
• Validate the parsed document against acceptance-policy-catalog.json.
• Resolve seller default and product acceptance_policy_profile_ids with cross-list uniqueness and exact policy/profile version and digest checks.
• Compose applicable rules restrictively; preserve unknown for partial coverage, omitted rules, undisclosed seller policy, or unavailable external content.
• Accept structured acceptance_context and explain likely allowed, prohibited, requires_disclosure, requires_setup, and requires_review outcomes without treating discovery as runtime authorization.
• Cache only within the advertised capability lifetime and invalidate on capabilities changes.

Compliance runner

Make media_buy_seller/acceptance_policy_discovery fully executable by having the runner:

1. fetch the advertised catalog;
2. compare exact bytes with catalog_digest;
3. schema-validate the document;
4. resolve every advertised default and product profile;
5. verify all pinned policy/profile digests; and
6. fail with distinct unsafe-URL, fetch, digest, schema, and unresolved-reference diagnostics.

Tests

• valid reference-seller catalog;
• digest mismatch and byte-preserving/canonicalization edge cases;
• redirect, URL credential, private-address, DNS-rebinding, timeout, and oversized-body rejection;
• duplicate local/registry profile IDs and unresolved policy pins;
• complete vs. partial coverage and restrictive default/product composition;
• cache invalidation after a capabilities change.

Acceptance criteria

• Buyers can ask the SDK what the seller is likely to accept without implementing catalog joins or mistaking advisory discovery for authority.
• The acceptance-policy storyboard verifies fetched bytes and references, rather than only checking capability pointers.
• Resolver results have parity requirements documented for the Python SDK.

Upstream: adcontextprotocol/adcp#6749
Implementation: adcontextprotocol/adcp#6794

[bokelley]

Triage

Classification: Feature request
Bucket(s): library, conformance
Status: ready-for-human

What the experts said:

• ad-tech-protocol-expert: Approve — advisory-not-authoritative framing correct, unknown-preserving restrictive composition is the right fail-closed pattern, fully non-breaking. Caveat: live-network catalog fetches in the compliance runner need fixture-pinning for CI determinism.
• code-reviewer: Needs clarification — acceptance-policy-catalog.json not found in repo schemas cache; cache invalidation trigger underspecified (full capabilities change vs. catalog_digest mismatch vs. TTL); URL credential stripping (parsed.username/parsed.password) not enforced in ssrfSafeFetch; default 64 KiB maxBodyBytes may be too small for catalogs.
• security-reviewer: Flag — trustedFetchFn escape hatch (src/lib/net/ssrf-fetch.ts:144) silently drops all SSRF guarantees if used here; parsed.username/parsed.password rejection missing; catalog content must not appear in log lines or error strings; "advisory" framing needs an explicit SDK hard-gate contract on digest failure (missing or bad digest = hard gate, not soft warning).

My take: Protocol design is solid and the feature is purely additive, but three security design questions need resolution before implementation: (1) explicitly prohibit trustedFetchFn at the catalog fetch call site; (2) add credential rejection to ssrfSafeFetch or enforce at the call site; (3) define whether digest failure blocks the buyer flow as a hard gate. @bokelley — please also confirm acceptance-policy-catalog.json is available in schemas/cache/latest/ from adcp#6794.

---

Triaged by Claude Code. Session: https://claude.ai/code/session_01G43PuJy2pTFCYm41H4ur7e

---

Generated by Claude Code