Revert covers_content_digest default to spec-mandated 'either'

[bokelley]

Summary

Pre-existing spec divergence in src/adcp/signing/verifier.py:95: VerifierCapability.covers_content_digest defaults to \"required\" but the AdCP 3.0 schema explicitly sets \"default\": \"either\" (schemas/cache/protocol/get-adcp-capabilities-response.json:912-921) with the rationale: "'required' is recommended for spend-committing operations in production; 4.0 recommends 'required' for those operations."

The 3.0 spec position: default is \"either\", \"required\" is opt-in for spend-committing ops, and 4.0 will recommend it broadly.

Background

Surfaced during the v6.0 DecisioningPlatform foundation audit (PR #297 expert review). PR #297's first commit included a regression test pinning the divergent default — that test was dropped in the scope-down per protocol-expert finding.

Proposed change

• Flip VerifierCapability.covers_content_digest default from \"required\" to \"either\".
• Promote spend-committing operations (create_media_buy, update_media_buy) to \"required\" via required_for=frozenset({...}).
• Webhook profile (adcp.signing.webhook_verifier) keeps its hard-coded \"required\" (correct, distinct from the request-signing default).

Risk

Any existing adopter relying on \"required\" by default will need to set it explicitly when constructing VerifierCapability(covers_content_digest=\"required\"). Document in CHANGELOG.

References

• Surfaced by ad-tech-protocol-expert review on PR feat(signing): close 4 SSRF gaps and add opt-in port hardening (foundation audit) #297
• Schema: schemas/cache/protocol/get-adcp-capabilities-response.json:912-921
• Code: src/adcp/signing/verifier.py:84-95

[bokelley]

Triage

Classification: Bug (spec divergence)
Bucket(s): signing
Status: ready-for-human

What the experts said:

• ad-tech-protocol-expert: Flag — AdCP 3.0 schema does mandate "either" as the protocol-level default, so the spec alignment goal is correct. However, the SDK's "required" default is an intentional opinionated-secure divergence (explicitly documented in the VerifierCapability docstring). Two additional blockers: (a) the proposed required_for=frozenset({"create_media_buy", "update_media_buy"}) does not tighten the digest policy per-op — covers_content_digest is a single global policy, so spend-committing ops remain at "either" unless the caller also sets covers_content_digest="required" explicitly; (b) existing tests (test_verifier_behaviors.py:349-351) pin the "required" default, confirming adopters rely on it — flipping silently breaks anyone not explicitly constructing VerifierCapability(covers_content_digest="required"). Needs semver minor bump and migration note at minimum.

My take: This requires a deliberate call on whether the SDK should mirror the spec's permissive default or maintain the stricter opinionated posture — both are internally consistent. The required_for design also needs rework before this is executable. Flagging for @bokelley.

---

Triaged by Claude Code. Session: https://claude.ai/code/${CLAUDE_CODE_REMOTE_SESSION_ID}

---

Generated by Claude Code

[bokelley]

Triage

Classification: Bug (spec divergence)
Bucket(s): signing (label absent — flagged in run summary)
Status: ready-for-human

What the experts said:

• ad-tech-protocol-expert: Spec confirmed accurate; blocker — required_for gates signature presence (step 0), not digest coverage (step 6); orthogonal axes, so the proposed class-level required_for default does not restore body-integrity enforcement for spend-committing ops.
• security-reviewer: Three blockers — required_for set is incomplete vs. _idempotency.py spend/rights ops (acquire_rights, update_rights, activate_signal, etc.); default flip silently downgrades all VerifierCapability() call sites; SDK-to-SDK tests won't catch the gap (buyer signer voluntarily covers digest under "either").
• code-reviewer: Two blockers — conformance test test_verifier_capability_defaults_to_required_digest fails on flip; PgReplayStore docstring example silently accepts body-unbound signatures post-change.

My take: The spec alignment direction is correct (AdCP 3.0 mandates "either" as default), but the proposed required_for mitigation is the wrong mechanism and covers an incomplete set of ops. Revised proposal should drop required_for from the class default, add a deprecation path, update all affected call sites and examples, and enumerate all spend-committing ops in the migration guide.

---

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

---

Generated by Claude Code

[bokelley]

Triage

Classification: Bug (spec divergence)
Bucket(s): signing
Status: ready-for-human

What the experts said:

• ad-tech-protocol-expert: Spec divergence confirmed — AdCP 3.0 schema sets "either" as the default for covers_content_digest; however required_for is orthogonal to covers_content_digest (they share no code path — _precheck_presence vs. _check_components), so the spend-op enforcement proposal is structurally a no-op; the correct fix needs a new per-op digest policy field (e.g. required_digest_for: frozenset[str]).
• security-reviewer: Block as proposed — flipping the enforcement default to "either" opens a body-substitution path on spend-committing ops that required_for cannot close; most operators will silently inherit the weaker posture, as the docstring warning is invisible to callers who copy examples.
• code-reviewer: Two blockers — the required_for/covers_content_digest mix-up produces a no-op for spend ops (body integrity not enforced regardless), and the conformance test at tests/conformance/signing/test_verifier_behaviors.py:349-351 breaks on the default flip.

My take: The spec divergence is real and eventually needs fixing, but the proposal conflates two orthogonal fields: required_for gates whether a signature must be present; covers_content_digest gates whether the body bytes must be covered by that signature. A safe fix needs a new required_digest_for: frozenset[str] field (or a per-op policy map) before the default can safely relax from "required" without silently removing body-integrity guarantees on create_media_buy / update_media_buy. Flagging for @bokelley to decide: (a) introduce the per-op field alongside the default flip, or (b) keep the enforcement default at "required" and only change what the SDK advertises in get_adcp_capabilities responses.

---

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

---

Generated by Claude Code