feat(server): webhook supervisor signing + capabilities response invariant for reporting webhooks

[bokelley]

Context

protocol/get-adcp-capabilities-response.json line 996 expresses an invariant: when a seller declares reporting webhooks in its capabilities, outbound webhook delivery MUST sign requests per RFC 9421. The framework already provides PgWebhookDeliverySupervisor (#360), but the actual signing wiring is currently the adopter's responsibility, and there is no boot-time check that the capabilities declaration matches the supervisor configuration.

Refs:

• protocol/get-adcp-capabilities-response.json:996
• src/adcp/decisioning/pg/ (PgWebhookDeliverySupervisor)
• examples/v3_reference_seller/src/app.py

Acceptance Criteria

• Document the RFC 9421 signing wiring in v3 ref seller (key material loading, key id, algorithm selection)
• Wire signing into the v3 ref seller's webhook supervisor instance
• Boot-time validator: if the platform's capabilities response declares any reporting webhook, fail boot unless the supervisor is configured with a signing key
• Test: verify outbound webhook bodies actually carry the RFC 9421 Signature and Signature-Input headers
• Test: verify boot fails when capabilities declare webhooks but supervisor has no key configured

[bokelley]

Triage

Classification: Feature request
Bucket(s): signing, examples (no matching repo labels — gap noted in run summary)
Status: ready-for-human

What the experts said:

• security-reviewer: Security-positive; boot-time is the right enforcement point. The gap is real — a seller advertising webhook_signing.supported=true in capabilities but omitting a signing key causes silent delivery blackout for buyers enforcing RFC 9421. Implementation note: key material in the v3 ref seller should load via file path from an env var, not inline a raw JWK scalar (would surface in os.environ dumps).
• ad-tech-protocol-expert: AC3's trigger field is wrong. reporting_delivery_methods: ["webhook"] (delivery topology) and webhook_signing.supported: true (auth posture) are deliberately separate in the schema. The spec permits "webhook" in delivery methods without RFC 9421 signing through 3.x (legacy_hmac_fallback exists precisely for this; deprecated only in 4.0). Keying the boot guard on the former breaks conformant sellers using HMAC/Bearer-only delivery. The correct trigger is webhook_signing.supported: true — a self-consistency check the spec supports today.

My take: The concept is sound and the validate_webhook_sender_for_platform precedent supports it, but AC3 as written uses the wrong schema field. Before this can be executed: @bokelley, please confirm — is AC3 a self-consistency check (key on webhook_signing.supported: true; shippable in 3.x as-is), or mandatory signing for all reporting-webhook sellers (4.0 scope, needs a spec RFC)? AC1, AC2, AC4, and AC5 are non-blocking and can draft in parallel once AC3's trigger is confirmed. Signing is also security-sensitive, so human review is required regardless.

---

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

---

Generated by Claude Code