@adcp/sdk 15.8.1 → 15.9.1

package/compliance/cache/{3.2.3 → 3.2.4}/specialisms/governance-delivery-monitor/index.yaml

@@ -5,6 +5,9 @@ protocol: governance
 category: governance_delivery_monitor
 summary: "Governance agent monitors delivery, detects budget drift past thresholds, and triggers re-evaluation."
 track: campaign_governance
+requires:
+  - controller
+
 required_tools:
   - check_governance
 

package/compliance/cache/{3.2.3 → 3.2.4}/specialisms/governance-spend-authority/denied.yaml

@@ -4,6 +4,9 @@ title: "Campaign governance — denied"
 category: governance_spend_authority
 summary: "Governance agent denies a media buy that exceeds the agent's spending authority. No human escalation — the buy is blocked."
 track: campaign_governance
+requires:
+  - controller
+
 required_tools:
   - sync_plans
   - check_governance

package/compliance/cache/{3.2.3 → 3.2.4}/specialisms/governance-spend-authority/index.yaml

@@ -5,6 +5,9 @@ protocol: governance
 category: governance_spend_authority
 summary: "Governance agent approves a media buy with conditions. Buyer re-checks after meeting the conditions."
 track: campaign_governance
+requires:
+  - controller
+
 required_tools:
   - sync_plans
   - check_governance

package/compliance/cache/{3.2.3 → 3.2.4}/specialisms/property-lists/index.yaml

@@ -5,6 +5,9 @@ protocol: governance
 category: property_lists
 summary: "Curated property lists for inventory grouping, targeting governance, and delivery compliance — create, query, update, delete, and validate."
 track: governance
+requires:
+  - controller
+
 required_tools:
   - create_property_list
 

package/compliance/cache/{3.2.3 → 3.2.4}/specialisms/sales-broadcast-tv/index.yaml

@@ -5,6 +5,9 @@ protocol: media-buy
 category: sales_broadcast_tv
 summary: "Seller agent for broadcast linear TV inventory — primetime and fringe spots with measurement windows, agency estimate numbers, Ad-ID-based creative sync, and delayed delivery reporting."
 track: media_buy
+requires:
+  - controller
+
 required_tools:
   - get_products
   - create_media_buy

package/compliance/cache/{3.2.3 → 3.2.4}/specialisms/sales-dooh/index.yaml

@@ -5,6 +5,9 @@ protocol: media-buy
 category: sales_dooh
 summary: "DOOH seller for non-guaranteed venue and screen inventory with canonical screen formats and substantive play reporting."
 track: media_buy
+requires:
+  - controller
+
 required_tools:
   - sync_creatives
   - list_products

package/compliance/cache/{3.2.3 → 3.2.4}/specialisms/sales-guaranteed/index.yaml

@@ -5,6 +5,9 @@ protocol: media-buy
 category: sales_guaranteed
 summary: "Seller agent that requires human-in-the-loop IO signing before guaranteed media buys go live."
 track: media_buy
+requires:
+  - controller
+
 required_tools:
   - get_products
   - create_media_buy
@@ -62,7 +65,7 @@ narrative: |
   during the runner's timeout window.
 
   If the production sandbox does not expose the controller, the forced approval
-  phases report a missing_test_controller coverage gap. Their skipped assertions
+  phases report a controller coverage gap (requirement_unmet naming controller, or missing_test_controller for an ungated step). Their skipped assertions
   do not prove the guaranteed approval lifecycle for a Verified (Sandbox) run.
 
   Proposal-driven workflows are part of guaranteed selling: most guaranteed deals start with

package/compliance/cache/{3.2.3 → 3.2.4}/specialisms/sales-non-guaranteed/index.yaml

@@ -5,6 +5,9 @@ protocol: media-buy
 category: sales_non_guaranteed
 summary: "Seller agent for auction-based, non-guaranteed buying where the buyer sets bid prices and budgets."
 track: media_buy
+requires:
+  - controller
+
 required_tools:
   - get_products
   - create_media_buy
@@ -369,8 +372,9 @@ phases:
       The buyer creates a media buy with bid prices per package. Since this is
       non-guaranteed, no IO is required and no human approval is needed. The response
       completes synchronously, without an IO or human-approval task. Because this
-      baseline does not attach creatives, the resulting buy waits in pending_creatives
-      until the separate creative lifecycle supplies them.
+      baseline does not attach creatives, a seller with a creative library reports
+      pending_creatives until valid assets are assigned. A seller without a creative
+      library may activate the buy immediately and report active.
 
     steps:
       - id: create_media_buy
@@ -391,7 +395,8 @@ phases:
         expected: |
           Return the media buy synchronously:
           - media_buy_id: your platform's identifier
-          - media_buy_status: pending_creatives until valid assets are assigned
+          - media_buy_status: pending_creatives when waiting for library creatives, or active
+            when the seller does not require creative assignment
           - confirmed_at: timestamp
           - packages: confirmed line items with bid prices acknowledged
           - valid_actions: include the actions available in the current lifecycle state
@@ -446,8 +451,8 @@ phases:
             description: "Seller assigns package_id — must be echoed in update_media_buy"
           - check: field_value
             path: "media_buy_status"
-            value: "pending_creatives"
-            description: "A synchronously accepted buy without assigned assets waits for creatives"
+            allowed_values: ["pending_creatives", "active"]
+            description: "An accepted buy waits for library creatives or is already active"
           # Anti-façade: a real non-guaranteed buy creates line items / orders /
           # campaigns in the seller's adserver or DSP. An adapter returning a
           # shape-valid response with a fabricated media_buy_id but no upstream
@@ -461,9 +466,10 @@ phases:
   - id: monitor_pacing
     title: "Inspect readiness and pacing"
     narrative: |
-      The buyer reads the accepted non-guaranteed buy. Before creatives are assigned,
-      the seller reports pending_creatives and no auction delivery; once the separate
-      creative lifecycle activates it, the same read surface carries pacing data.
+      The buyer reads the accepted non-guaranteed buy. A seller waiting for library
+      creatives reports pending_creatives and no auction delivery. A seller without
+      a creative library may already report active with pacing data; the separate
+      creative lifecycle also uses this read surface after activation.
 
     steps:
       - id: get_media_buys_pacing
@@ -480,7 +486,8 @@ phases:
         expected: |
           Return the media buy with lifecycle and pacing data:
           - media_buy_id: matches the buy created earlier
-          - status: pending_creatives before assets are assigned
+          - status: pending_creatives while waiting for library creatives, or active
+            when creative assignment is not required
           - packages: line items with current delivery and pacing fields
           - valid_actions: actions valid for the reported lifecycle state
 
@@ -504,8 +511,8 @@ phases:
             description: "Media buy has a status"
           - check: field_value
             path: "media_buys[0].status"
-            value: "pending_creatives"
-            description: "The unassigned buy remains pending creatives"
+            allowed_values: ["pending_creatives", "active"]
+            description: "The accepted buy is waiting for library creatives or already active"
 
           - check: field_present
             path: "context"
@@ -518,7 +525,8 @@ phases:
     title: "Adjust bids and budget"
     narrative: |
       The buyer can adjust bids or budgets before activation or in-flight. Here it
-      raises each bid and reallocates package budgets while the buy awaits creatives.
+      raises each bid and reallocates package budgets while the buy awaits library
+      creatives or is already active on a seller that does not require assignment.
 
     steps:
       - id: update_media_buy
@@ -537,7 +545,7 @@ phases:
           Apply the updates and return the modified media buy state:
           - media_buy_id: matches the existing buy
           - affected_packages: full post-update package objects reflecting new bids and budgets
-          - media_buy_status: pending_creatives if lifecycle state is emitted
+          - media_buy_status: retain pending_creatives or active if lifecycle state is emitted
           - Changes are retained for subsequent auction participation
 
         sample_request:

package/compliance/cache/{3.2.3 → 3.2.4}/specialisms/signal-marketplace/index.yaml

@@ -5,6 +5,9 @@ protocol: signals
 category: signal_marketplace
 summary: "Signal agent that resells third-party data provider signals with verifiable provider-published provenance."
 track: signals
+requires:
+  - controller
+
 required_tools:
   - get_signals
   - activate_signal

package/compliance/cache/{3.2.3 → 3.2.4}/specialisms/signal-owned/index.yaml

@@ -5,6 +5,9 @@ protocol: signals
 category: signal_owned
 summary: "Signal agent serving first-party or proprietary audience data for discovery without external catalog verification."
 track: signals
+requires:
+  - controller
+
 required_tools:
   - get_signals
 

package/compliance/cache/{3.2.3 → 3.2.4}/test-vectors/request-signing/README.md

@@ -45,12 +45,15 @@ test-vectors/request-signing/
 │   ├── 023-multi-valued-content-digest.json → request_signature_header_malformed (step 1; RFC 9530 dict duplicate algorithm)
 │   ├── 024-unquoted-string-param.json     → request_signature_header_malformed (step 1; RFC 8941 §3.3 string values must be quoted)
 │   ├── 025-jwk-alg-crv-mismatch.json      → request_signature_key_purpose_invalid (step 8; alg=EdDSA with crv=P-256 is impossible per RFC 8037)
-│   ├── 026-non-ascii-host.json            → request_signature_header_malformed (step 1; raw IDN U-label on wire; MUST be A-label)
+│   ├── 026-non-ascii-host.json            → request_target_uri_malformed (step 10; raw IDN U-label on wire; MUST be A-label; real signature over the A-label base)
 │   ├── 027-webhook-registration-authentication-unsigned.json → request_signature_required (webhook-reg with push_notification_config.authentication over bearer on a seller supporting signing; operation NOT in required_for)
-│   └── 028-unsigned-protocol-method-required.json → request_signature_required (unsigned `tasks/cancel` JSON-RPC POST; method is in `protocol_methods_required_for`)
+│   ├── 028-unsigned-protocol-method-required.json → request_signature_required (unsigned `tasks/cancel` JSON-RPC POST; method is in `protocol_methods_required_for`)
+│   ├── 029-duplicate-signature-label.json → request_signature_header_malformed (step 1; RFC 9421 §4.2 / RFC 8941 §3.2 duplicate key on the `Signature` header)
+│   ├── 030-content-digest-key-case.json   → request_signature_header_malformed (step 1; RFC 8941 §3.1.2 keys are lowercase only — `SHA-256` is not a synonym of `sha-256`)
+│   └── 031-malformed-host-authority.json  → request_target_uri_malformed (step 10; unbracketed IPv6 literal in the `Host` header, URL clean, real signature)
 ├── a2a/                                  A2A operation-resolution vectors (adcp#7820, 33 vectors): `required_for` over A2A; see "A2A operation-resolution vectors" below
 ├── profile-3.2/                          3.2 vectors: RFC 8941 Base64 sf-binary, content-digest covered, covers_content_digest 'required'
-│   ├── positive/                         counterparts keep the root vector's number and slug; gaps = not mirrored
+│   ├── positive/                         counterparts keep the root vector's number and slug; the absence of `positive/001-basic-post` and `positive/002-post-with-content-digest` is by design (both map to `001-post-with-content-digest`)
 │   │   ├── 001-post-with-content-digest.json                  RFC 8941 Base64 + required body binding (3.2 counterpart of root 001 and 002)
 │   │   ├── 003-es256-post.json                                 ES256
 │   │   ├── 004-multiple-signature-labels.json                  verifier processes sig1 only
@@ -61,9 +64,13 @@ test-vectors/request-signing/
 │   │   ├── 009-percent-encoded-unreserved-decoded.json
 │   │   ├── 010-percent-encoded-slash-preserved.json
 │   │   ├── 011-ipv6-authority.json
-│   │   └── 012-ipv6-authority-default-port-stripped.json
+│   │   ├── 012-ipv6-authority-default-port-stripped.json
+│   │   ├── 013-two-signature-labels-distinct.json              guard for negative/029
+│   │   ├── 014-content-digest-two-algorithms.json              guard for negative/030
+│   │   └── 015-bracketed-ipv6-host-with-port.json              guard for negative/031
 │   └── negative/
 │       ├── 001-base64url-sf-binary.json       → request_signature_header_malformed (3.2-only; legacy alphabet)
+│       ├── 001-no-signature-header.json       → request_signature_required (pre-check; unsigned, Content-Digest sent)
 │       ├── 002-multiple-trailing-dots.json    → request_target_uri_malformed (3.2-only; empty DNS label)
 │       ├── 002-wrong-tag.json                 → request_signature_tag_invalid (step 3)
 │       ├── 003-expired-signature.json         → request_signature_window_invalid (step 5)
@@ -74,14 +81,26 @@ test-vectors/request-signing/
 │       ├── 008-unknown-keyid.json             → request_signature_key_unknown (step 7)
 │       ├── 009-key-ops-missing-verify.json    → request_signature_key_purpose_invalid (step 8)
 │       ├── 010-content-digest-mismatch.json   → request_signature_digest_mismatch (step 11)
+│       ├── 011-malformed-header.json          → request_signature_header_malformed (step 1; unparseable Signature-Input, placeholder Signature)
 │       ├── 012-missing-expires-param.json     → request_signature_params_incomplete (step 2)
 │       ├── 013-expires-le-created.json        → request_signature_window_invalid (step 5)
 │       ├── 014-missing-nonce-param.json       → request_signature_params_incomplete (step 2)
 │       ├── 015-signature-invalid.json         → request_signature_invalid (step 10)
 │       ├── 016-replayed-nonce.json            → request_signature_replayed (step 12; requires test_harness_state preload)
 │       ├── 017-key-revoked.json               → request_signature_key_revoked (step 9; requires test_harness_state preload)
+│       ├── 019-signature-without-signature-input.json → request_signature_header_malformed (pre-check; real Signature, Signature-Input stripped, operation outside required_for)
 │       ├── 020-rate-abuse.json                → request_signature_rate_abuse (step 9a; requires test_harness_state preload)
-│       └── 025-jwk-alg-crv-mismatch.json      → request_signature_key_purpose_invalid (step 8; jwks_override)
+│       ├── 021-duplicate-signature-input-label.json → request_signature_header_malformed (step 1; real Signature)
+│       ├── 022-multi-valued-content-type.json → request_signature_header_malformed (step 1; real Signature)
+│       ├── 023-multi-valued-content-digest.json → request_signature_header_malformed (step 1; real Signature)
+│       ├── 024-unquoted-string-param.json     → request_signature_header_malformed (step 1; real Signature)
+│       ├── 025-jwk-alg-crv-mismatch.json      → request_signature_key_purpose_invalid (step 8; jwks_override)
+│       ├── 026-non-ascii-host.json            → request_target_uri_malformed (step 10; raw U-label on the wire, real Signature over the A-label base)
+│       ├── 027-webhook-registration-authentication-unsigned.json → request_signature_required (pre-check; unsigned)
+│       ├── 028-unsigned-protocol-method-required.json → request_signature_required (pre-check; unsigned)
+│       ├── 029-duplicate-signature-label.json → request_signature_header_malformed (step 1; real Signature repeated under `sig1`)
+│       ├── 030-content-digest-key-case.json   → request_signature_header_malformed (step 1; `SHA-256` and `sha-256`, real Signature)
+│       └── 031-malformed-host-authority.json  → request_target_uri_malformed (step 10; unbracketed IPv6 `Host`, URL clean, real Signature)
 └── positive/                             vectors that MUST verify successfully
     ├── 001-basic-post.json                   Ed25519, no content-digest
     ├── 002-post-with-content-digest.json     Ed25519, content-digest covered
@@ -94,7 +113,10 @@ test-vectors/request-signing/
     ├── 009-percent-encoded-unreserved-decoded.json  Path has %7E/%2D/%5F/%2E; canonical decodes unreserved per RFC 3986 §6.2.2.2
     ├── 010-percent-encoded-slash-preserved.json     Path has %2F (reserved); stays percent-encoded, not treated as segment separator
     ├── 011-ipv6-authority.json                       IPv6 literal host; brackets preserved in @target-uri and @authority
-    └── 012-ipv6-authority-default-port-stripped.json IPv6 literal with :443; port stripped, brackets preserved
+    ├── 012-ipv6-authority-default-port-stripped.json IPv6 literal with :443; port stripped, brackets preserved
+    ├── 013-two-signature-labels-distinct.json        sig1 and sig2 on both Signature-Input and Signature; guard for negative/029
+    ├── 014-content-digest-two-algorithms.json       Content-Digest with sha-256 and sha-512, both correct; guard for negative/030
+    └── 015-bracketed-ipv6-host-with-port.json        Host: [2001:db8::1]:8443 matches the URL authority; guard for negative/031
 ```
 
 ## Canonicalization vectors (`canonicalization.json`)
@@ -244,18 +266,22 @@ The shipped signatures were generated from those base strings using the correspo
 
 ## Profile 3.2 vectors
 
-A 3.2 signing peer MUST advertise `covers_content_digest: "required"`, and every accepted signature on a body-bearing request covers `content-digest`. Most root vectors sign without `content-digest`, so a `required` verifier cannot grade them. `profile-3.2/` restores that coverage: each root positive vector and each root negative for checklist steps 2–12 has a 3.2 counterpart **with the same number and slug** (for example, `profile-3.2/negative/003-expired-signature.json` is the 3.2 version of `negative/003-expired-signature.json`). Root vectors that are not mirrored leave gaps in the numbering. Root `positive/001` (basic POST) and `positive/002` (POST with content-digest) are the same request in 3.2, so both map to `profile-3.2/positive/001-post-with-content-digest.json`. `profile-3.2/negative/001` and `002-multiple-trailing-dots` are 3.2-only wire-format vectors that predate this scheme; `002-multiple-trailing-dots` shares its number with the `002-wrong-tag` counterpart, and file names stay unique.
+A 3.2 signing peer MUST advertise `covers_content_digest: "required"`, and every accepted signature on a body-bearing request covers `content-digest`. Most root vectors sign without `content-digest`, so a `required` verifier cannot grade them. `profile-3.2/` restores that coverage: each root positive vector and each root negative has a 3.2 counterpart **with the same number and slug** (for example, `profile-3.2/negative/003-expired-signature.json` is the 3.2 version of `negative/003-expired-signature.json`), except the vectors for postures 3.2 forbids. Root vectors that are not mirrored leave gaps in the numbering. Root `positive/001` (basic POST) and `positive/002` (POST with content-digest) are the same request in 3.2, so both map to `profile-3.2/positive/001-post-with-content-digest.json`. `profile-3.2/negative/001` and `002-multiple-trailing-dots` are 3.2-only wire-format vectors that predate this scheme; `002-multiple-trailing-dots` shares its number with the `002-wrong-tag` counterpart, and file names stay unique.
 
 Each counterpart keeps its original's request shape but:
 
-- covers `content-digest` (except `profile-3.2/negative/007-missing-content-digest`, whose whole point is that it is missing; it still sends a correct `Content-Digest` header, so verifiers must check the covered-components list rather than header presence);
+- covers `content-digest` wherever a parseable `Signature-Input` exists. The exceptions are `profile-3.2/negative/007-missing-content-digest`, whose whole point is that it is missing (it still sends a correct `Content-Digest` header, so verifiers must check the covered-components list rather than header presence), and `011`, whose `Signature-Input` is unparseable;
 - encodes `Signature` and `Content-Digest` as RFC 8941 `sf-binary` (standard Base64, padded);
 - advertises `covers_content_digest: "required"`;
 - re-keys the body's `idempotency_key`, so the counterpart is a distinct request.
 
 As in the root corpus, pre-crypto negatives (steps 2–9a) carry a 64-zero-byte placeholder `Signature`. That makes them step-ordering canaries: a verifier that verifies the signature before the targeted check returns `request_signature_invalid`. The post-crypto negatives (`profile-3.2/negative/010` and `016`) carry real signatures, so only the targeted check fails.
 
-Root negatives without a 3.2 counterpart: the unsigned pre-check vectors (`001`, `027`, `028`); the step-1 parse vectors (`011`, `019`, `021`–`024`, `026`), which reject before covered components are considered; and `018`, because `forbidden` is a legacy-only posture a 3.2 verifier cannot advertise.
+The step-0 and step-1 vectors are mirrored with `content-digest` covered, so that the step-0/1 fault is the vector's only fault. Without that, a `required` verifier would also find a step-6 fault (a body-bound signature that does not cover `content-digest`) in `021`, `022`, `024`, `026`, `029` and `031`, and the vector would grade the verifier's evaluation order rather than the step-1 rule. The unsigned vectors (`001`, `027`, `028`) stay unsigned and carry only a correct `Content-Digest`. Where the fault does not depend on the signature bytes (`021`–`024`, `026`, `029`–`031`), the `Signature` is real rather than a placeholder, so a signature the verifier can validate is not a second fault; `021`, `023`, `029` and `030` repeat the same member or value so that keeping either one finds no second fault. `029` and `030` carry real signatures where the root vectors use placeholders, and the root's false-positive guards `positive/013`–`015` are mirrored as well. `031` is a real signature over the base for the clean URL authority, so the malformed `Host` header is the only fault; its `Host` header is carried over unchanged. `019` is a real signature whose `Signature-Input` was stripped, on an operation outside `required_for` so that only the header-pair rule applies; `026` signs the base for the A-label form of the host, so only the raw U-label on the wire is wrong. `011` keeps the placeholder because its `Signature-Input` is unparseable and no signature base exists.
+
+The pre-crypto negatives for steps 2–9a keep their placeholder `Signature`, which predates the single-fault rule below. Whether the step order those canaries grade is normative is the open question in adcp#7577, so they are not rewritten here.
+
+The only root negative without a 3.2 counterpart is one for a posture 3.2 forbids: `018`, because `forbidden` is a legacy-only posture a 3.2 verifier cannot advertise.
 
 ## Running vectors against an implementation
 
@@ -274,12 +300,12 @@ A reference harness is in progress at https://github.com/adcontextprotocol/adcp-
 
 Run vectors in this order when validating a new implementation — it isolates failure categories so a bug surfaces cleanly instead of as a pile of unrelated red tests. The numbers below refer to the root 3.1 corpus; a 3.2 verifier applies the same order to the `profile-3.2/` counterparts (see the mapping in [File layout](#file-layout)):
 
-1. **Positive vectors first** (`positive/001`, `/002`, `/003`). These exercise the happy path. If `001` fails, your signer or verifier's canonicalization, key loading, or crypto is wrong — fix before touching anything else. The `expected_signature_base` field in each positive vector lets you diff YOUR canonical base against the spec's, independent of whether your crypto works.
-2. **Parse-level negatives next** (`001`, `002`, `011`, `012`, `014`, `019`). These fail at the pre-check or early checklist steps without invoking crypto. Passing these means your header parsing and presence checks are correct.
+1. **Positive vectors first** (`positive/001`, `/002`, `/003`, then the false-positive guards `positive/013`, `/014`, `/015` before the negatives they pair with: `negative/029`, `/030`, `/031`). These exercise the happy path. If `001` fails, your signer or verifier's canonicalization, key loading, or crypto is wrong — fix before touching anything else. The `expected_signature_base` field in each positive vector lets you diff YOUR canonical base against the spec's, independent of whether your crypto works.
+2. **Parse-level negatives next** (`001`, `002`, `011`, `012`, `014`, `019`, `021`, `023`, `029`, `030`). These fail at the pre-check or early checklist steps without invoking crypto. Passing these means your header parsing and presence checks are correct.
 3. **Semantic negatives** (`003`, `004`, `005`, `006`, `007`, `013`, `018`). These exercise specific rules (window, alg allowlist, covered components, content-digest policy) without requiring valid signatures.
 4. **Key-path negatives** (`008`, `009`). JWKS resolution + `adcp_use` enforcement.
 5. **Stateful pre-crypto negatives** (`017`, `020`). These require preloaded harness state and reject before crypto verify — `017` on revocation (step 9), `020` on the per-keyid cap (step 9a). The committed `Signature` on these vectors is a placeholder and is NOT expected to verify cryptographically; the rejection MUST land on the pre-crypto cheap check.
-6. **Crypto / stateful-post negatives last** (`015`, `010`, `016`). These require the verifier to have run most of the checklist before reaching the failure point. `015` specifically catches canonicalization bugs where your implementation computes a different signature base than the spec — if you pass `positive/001` but fail `015`, your canonicalization is still off somewhere and `015` is picking it up.
+6. **Crypto / stateful-post negatives last** (`015`, `010`, `016`, `031`). These require the verifier to have run most of the checklist before reaching the failure point. `031` is a real-signature negative: the signature verifies over the URL authority, so only a verifier that also judges the `Host` header rejects it with `request_target_uri_malformed`. `015` specifically catches canonicalization bugs where your implementation computes a different signature base than the spec — if you pass `positive/001` but fail `015`, your canonicalization is still off somewhere and `015` is picking it up.
 
 ## Adding vectors
 
@@ -290,3 +316,4 @@ Every new vector MUST:
 3. Use only keypairs from `keys.json`, OR supply a documented `jwks_override` explaining why a non-canonical key shape is required.
 4. Include `expected_signature_base` for positive vectors and for step-10 `request_signature_invalid` catchers.
 5. Include `test_harness_state` for any vector that requires preloaded verifier state.
+6. Carry exactly one fault (adcp#7577). A request MUST NOT contain a second fault that a verifier could detect through a different evaluation order, because multi-fault vectors implicitly grade verifier step ordering. Build the request so that every other check passes: cover `content-digest`, send a correct `Content-Digest`, and sign the base the verifier would otherwise verify. Keep a placeholder `Signature` only where no signature base can exist.

package/compliance/cache/{3.2.3 → 3.2.4}/test-vectors/request-signing/canonicalization.json

@@ -165,6 +165,38 @@
       "expected_target_uri": "https://seller.example.com/?x=1",
       "expected_authority": "seller.example.com"
     },
+    {
+      "name": "empty-path-no-query-becomes-slash",
+      "rule": "step 5: empty path with authority → / (no query present)",
+      "input_url": "https://seller.example.com",
+      "expected_target_uri": "https://seller.example.com/",
+      "expected_authority": "seller.example.com",
+      "$comment": "Step 5's condition is the path and the authority; the query is not part of it. The queried spelling above is step 5's illustrative example, not its trigger, and an implementation that reads it as the trigger passes that case while leaving this one unslashed. Keep both."
+    },
+    {
+      "name": "empty-path-no-query-non-default-port-becomes-slash",
+      "rule": "step 5: empty path with authority → / (port preserved from step 4)",
+      "input_url": "https://seller.example.com:8443",
+      "expected_target_uri": "https://seller.example.com:8443/",
+      "expected_authority": "seller.example.com:8443",
+      "$comment": "The slash lands after the port, not between host and port. A fix applied to the host rather than the path emits seller.example.com/:8443."
+    },
+    {
+      "name": "empty-path-no-query-ipv6-becomes-slash",
+      "rule": "step 5: empty path with authority → / (IPv6 literal)",
+      "input_url": "https://[2001:db8::1]",
+      "expected_target_uri": "https://[2001:db8::1]/",
+      "expected_authority": "[2001:db8::1]",
+      "$comment": "Brackets are preserved per step 2 and the slash goes outside them."
+    },
+    {
+      "name": "empty-path-empty-query-becomes-slash",
+      "rule": "steps 5 + 7: empty path → /, and the trailing ? is still preserved",
+      "input_url": "https://seller.example.com?",
+      "expected_target_uri": "https://seller.example.com/?",
+      "expected_authority": "seller.example.com",
+      "$comment": "The two rules compose rather than compete. This is also where a query-gated reading of step 5 fails on its own terms: the raw URL does carry a ?, but the parsed query is the empty string, so a condition written against the query reads false and emits a path-less https://seller.example.com? -- a form no RFC 3986 normalizer produces."
+    },
     {
       "name": "percent-encoded-hex-uppercased",
       "rule": "step 6: uppercase %xx hex digits",

package/compliance/cache/{3.2.3 → 3.2.4}/test-vectors/request-signing/negative/026-non-ascii-host.json

@@ -1,6 +1,6 @@
 {
   "name": "URL authority contains raw IDN U-label (non-ASCII bytes in host)",
-  "spec_reference": "#adcp-rfc-9421-profile (@target-uri canonicalization: hosts MUST be ASCII A-labels; RFC 5891 §4.4)",
+  "spec_reference": "#adcp-rfc-9421-profile (@target-uri canonicalization: hosts MUST be ASCII A-labels; RFC 5891 §4.4); security.mdx error table: raw non-ASCII host → request_target_uri_malformed",
   "signing_profile_version": "3.1",
   "reference_now": 1776520800,
   "request": {
@@ -9,7 +9,7 @@
     "headers": {
       "Content-Type": "application/json",
       "Signature-Input": "sig1=(\"@method\" \"@target-uri\" \"@authority\" \"content-type\");created=1776520800;expires=1776521100;nonce=\"KXYnfEfJ0PBRZXQyVXfVQA\";keyid=\"test-ed25519-2026\";alg=\"ed25519\";tag=\"adcp/request-signing/v1\"",
-      "Signature": "sig1=:AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA:"
+      "Signature": "sig1=:fYwfZG_HXkIxr0bNLUGRpwl0gSO3-birWx-20-GY9868cMWxtU_gSKOSFWzI6T9q_CII_UQOA0ogwyV3gyp_CA:"
     },
     "body": "{\"idempotency_key\":\"vector-negative-026-non-ascii-host\",\"account\":{\"brand\":{\"domain\":\"acmeoutdoor.example\"},\"operator\":\"pinnacle-agency.example\",\"sandbox\":false},\"packages\":[{\"product_id\":\"prod-1\",\"budget\":5000.0,\"pricing_option_id\":\"cpm_usd_fixed\",\"paused\":false}],\"brand\":{\"domain\":\"brand.example\"},\"start_time\":\"2027-01-04T00:00:00Z\",\"end_time\":\"2027-02-01T00:00:00Z\",\"paused\":false,\"plan_id\":\"plan_001\"}"
   },
@@ -25,8 +25,9 @@
   ],
   "expected_outcome": {
     "success": false,
-    "error_code": "request_signature_header_malformed",
-    "failed_step": 1
+    "error_code": "request_target_uri_malformed",
+    "failed_step": 10
   },
-  "$comment": "Host label 'bücher' is a Unicode U-label; the AdCP @target-uri algorithm requires A-label (Punycode, 'xn--bcher-kva') form. Accepting a raw U-label on the wire risks a canonicalization-differential: UTS-46 Nontransitional processing produces one A-label, naive lowercase + Punycode produces another (see canonicalization.json case 'idn-mixed-case-to-punycode'), and non-ASCII-aware libraries may round-trip the bytes unchanged. Verifier MUST reject at parse rather than guess. Companion canonicalization.json cases 'idn-to-punycode' and 'idn-mixed-case-to-punycode' exercise the SIGNER side (expect A-label output from U-label input after explicit UTS-46 processing); this vector exercises the VERIFIER side (reject U-label bytes received on the wire inside a signed request)."
+  "$comment": "Host label 'bücher' is a Unicode U-label; the AdCP @target-uri algorithm requires A-label (Punycode, 'xn--bcher-kva') form. Accepting a raw U-label on the wire risks a canonicalization-differential: UTS-46 Nontransitional processing produces one A-label, naive lowercase + Punycode produces another (see canonicalization.json case 'idn-mixed-case-to-punycode'), and non-ASCII-aware libraries may round-trip the bytes unchanged. Verifier MUST reject rather than guess, with request_target_uri_malformed (the security.mdx error table lists 'raw non-ASCII host' under that code; the 3.1 corpus originally graded this as request_signature_header_malformed, corrected in the 3.2.4 maintenance corpus). The Signature is a real Ed25519 signature by test-ed25519-2026 over expected_signature_base, which uses the A-label form 'xn--bcher-kva.example.com': a verifier that silently applies ToASCII to the raw U-label verifies successfully and wrongly accepts, so the host is the only fault. Companion canonicalization.json cases 'idn-to-punycode' and 'idn-mixed-case-to-punycode' exercise the SIGNER side (expect A-label output from U-label input after explicit UTS-46 processing); this vector exercises the VERIFIER side (reject U-label bytes received on the wire inside a signed request).",
+  "expected_signature_base": "\"@method\": POST\n\"@target-uri\": https://xn--bcher-kva.example.com/adcp/create_media_buy\n\"@authority\": xn--bcher-kva.example.com\n\"content-type\": application/json\n\"@signature-params\": (\"@method\" \"@target-uri\" \"@authority\" \"content-type\");created=1776520800;expires=1776521100;nonce=\"KXYnfEfJ0PBRZXQyVXfVQA\";keyid=\"test-ed25519-2026\";alg=\"ed25519\";tag=\"adcp/request-signing/v1\""
 }

package/compliance/cache/3.2.4/test-vectors/request-signing/negative/029-duplicate-signature-label.json

@@ -0,0 +1,32 @@
+{
+  "name": "Signature header declares label 'sig1' twice (malformed structured dictionary)",
+  "spec_reference": "#verifier-checklist-requests step 1 (RFC 9421 §4.2 Signature is a Dictionary; RFC 8941 §3.2 keys are unique; AdCP rejects duplicate labels rather than retaining the last)",
+  "signing_profile_version": "3.1",
+  "reference_now": 1776520800,
+  "request": {
+    "method": "POST",
+    "url": "https://seller.example.com/adcp/create_media_buy",
+    "headers": {
+      "Content-Type": "application/json",
+      "Signature-Input": "sig1=(\"@method\" \"@target-uri\" \"@authority\" \"content-type\");created=1776520800;expires=1776521100;nonce=\"KXYnfEfJ0PBRZXQyVXfVQA\";keyid=\"test-ed25519-2026\";alg=\"ed25519\";tag=\"adcp/request-signing/v1\"",
+      "Signature": "sig1=:AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA:, sig1=:BAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA:"
+    },
+    "body": "{\"idempotency_key\":\"vector-negative-029-duplicate-signature-label\",\"account\":{\"brand\":{\"domain\":\"acmeoutdoor.example\"},\"operator\":\"pinnacle-agency.example\",\"sandbox\":false},\"packages\":[{\"product_id\":\"prod-1\",\"budget\":5000.0,\"pricing_option_id\":\"cpm_usd_fixed\",\"paused\":false}],\"brand\":{\"domain\":\"brand.example\"},\"start_time\":\"2027-01-04T00:00:00Z\",\"end_time\":\"2027-02-01T00:00:00Z\",\"paused\":false,\"plan_id\":\"plan_001\"}"
+  },
+  "verifier_capability": {
+    "supported": true,
+    "covers_content_digest": "either",
+    "required_for": [
+      "create_media_buy"
+    ]
+  },
+  "jwks_ref": [
+    "test-ed25519-2026"
+  ],
+  "expected_outcome": {
+    "success": false,
+    "error_code": "request_signature_header_malformed",
+    "failed_step": 1
+  },
+  "$comment": "RFC 9421 §4.2 defines the Signature field as a Dictionary, and RFC 8941 §3.2 makes dictionary keys unique, and a standard parser (RFC 8941 §4.2.2) resolves a duplicate by silently overwriting with the last value. That overwrite is the ambiguity: AdCP step 1 therefore treats a repeated label as malformed, the same downgrade-protection posture as 021, and verifiers MUST reject rather than retain the last value. Signature-Input carries sig1 exactly once and is well formed; only the Signature header repeats the label. Accepting it lets two parties disagree on which signature bytes belong to sig1 — one verifies the first, another reads the last — over a Signature-Input both agree on. Same rule as 021-duplicate-signature-input-label, applied to the other signature header. Both values are well-formed 64-byte sf-binary placeholders, so a verifier that rejects only on an unparseable signature will not reject here."
+}

package/compliance/cache/3.2.4/test-vectors/request-signing/negative/030-content-digest-key-case.json

@@ -0,0 +1,33 @@
+{
+  "name": "Content-Digest carries SHA-256 and sha-256 (uppercase dictionary key is not a case-insensitive synonym)",
+  "spec_reference": "#verifier-checklist-requests step 1 (RFC 9530 §2 Content-Digest is an RFC 8941 Dictionary; RFC 8941 §3.1.2 keys are lowercase only)",
+  "signing_profile_version": "3.1",
+  "reference_now": 1776520800,
+  "request": {
+    "method": "POST",
+    "url": "https://seller.example.com/adcp/create_media_buy",
+    "headers": {
+      "Content-Type": "application/json",
+      "Content-Digest": "SHA-256=:qgPvy3VlFK_BtENbAvUhJn_MsgGdHhxlZHKt2itYaxc:, sha-256=:qgPvy3VlFK_BtENbAvUhJn_MsgGdHhxlZHKt2itYaxc:",
+      "Signature-Input": "sig1=(\"@method\" \"@target-uri\" \"@authority\" \"content-type\" \"content-digest\");created=1776520800;expires=1776521100;nonce=\"KXYnfEfJ0PBRZXQyVXfVQA\";keyid=\"test-ed25519-2026\";alg=\"ed25519\";tag=\"adcp/request-signing/v1\"",
+      "Signature": "sig1=:AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA:"
+    },
+    "body": "{\"idempotency_key\":\"vector-negative-030-content-digest-key-case\",\"account\":{\"brand\":{\"domain\":\"acmeoutdoor.example\"},\"operator\":\"pinnacle-agency.example\",\"sandbox\":false},\"packages\":[{\"product_id\":\"prod-1\",\"budget\":5000.0,\"pricing_option_id\":\"cpm_usd_fixed\",\"paused\":false}],\"brand\":{\"domain\":\"brand.example\"},\"start_time\":\"2027-01-04T00:00:00Z\",\"end_time\":\"2027-02-01T00:00:00Z\",\"paused\":false,\"plan_id\":\"plan_001\"}"
+  },
+  "verifier_capability": {
+    "supported": true,
+    "covers_content_digest": "required",
+    "required_for": [
+      "create_media_buy"
+    ]
+  },
+  "jwks_ref": [
+    "test-ed25519-2026"
+  ],
+  "expected_outcome": {
+    "success": false,
+    "error_code": "request_signature_header_malformed",
+    "failed_step": 1
+  },
+  "$comment": "RFC 9530 §2 Content-Digest is an RFC 8941 Dictionary, and the RFC 8941 §3.1.2 key production admits lowercase characters only (a-z, 0-9, '_', '-', '.', '*'; first character a-z or '*'). 'SHA-256' is therefore a parse-invalid key (RFC 8941 §4.2.3.3: parsing fails when the first character is not lcalpha or '*'), not a case-insensitive synonym of 'sha-256' and not a second spelling of the same algorithm. Verifiers MUST NOT fold case to reconcile the two members. Grading is on the error code, so a folding verifier that reports a duplicate algorithm still returns the expected code; this vector catches verifiers that ignore the unknown key or compare keys as written and accept the header, after which a signer and verifier may disagree on which value entered the signature base. Verifier MUST reject at step 1. Both members carry the correct sha-256 of the body so the digest value itself is not the fault; sibling of 023-multi-valued-content-digest (same algorithm twice, same spelling)."
+}

package/compliance/cache/3.2.4/test-vectors/request-signing/negative/031-malformed-host-authority.json

@@ -0,0 +1,34 @@
+{
+  "name": "Host header carries an unbracketed IPv6 literal (malformed authority) while the URL is clean",
+  "spec_reference": "#adcp-rfc-9421-profile (@authority derived from the as-received Host header and canonicalized by the URL canonicalization algorithm; malformed authority → request_target_uri_malformed)",
+  "signing_profile_version": "3.1",
+  "reference_now": 1776520800,
+  "request": {
+    "method": "POST",
+    "url": "https://[::1]/adcp/create_media_buy",
+    "headers": {
+      "Host": "::1",
+      "Content-Type": "application/json",
+      "Signature-Input": "sig1=(\"@method\" \"@target-uri\" \"@authority\" \"content-type\");created=1776520800;expires=1776521100;nonce=\"KXYnfEfJ0PBRZXQyVXfVQA\";keyid=\"test-ed25519-2026\";alg=\"ed25519\";tag=\"adcp/request-signing/v1\"",
+      "Signature": "sig1=:54AboGWe1BvlA-epah2osf0Zqsvj_9e5SMO-AUxjIHHAmc-gm8qKMKjSPDzw3TJwsHYHgzc5pqJ_4X-xFmydDA:"
+    },
+    "body": "{\"idempotency_key\":\"vector-negative-031-malformed-host-authority\",\"account\":{\"brand\":{\"domain\":\"acmeoutdoor.example\"},\"operator\":\"pinnacle-agency.example\",\"sandbox\":false},\"packages\":[{\"product_id\":\"prod-1\",\"budget\":5000.0,\"pricing_option_id\":\"cpm_usd_fixed\",\"paused\":false}],\"brand\":{\"domain\":\"brand.example\"},\"start_time\":\"2027-01-04T00:00:00Z\",\"end_time\":\"2027-02-01T00:00:00Z\",\"paused\":false,\"plan_id\":\"plan_001\"}"
+  },
+  "verifier_capability": {
+    "supported": true,
+    "covers_content_digest": "either",
+    "required_for": [
+      "create_media_buy"
+    ]
+  },
+  "jwks_ref": [
+    "test-ed25519-2026"
+  ],
+  "expected_signature_base": "\"@method\": POST\n\"@target-uri\": https://[::1]/adcp/create_media_buy\n\"@authority\": [::1]\n\"content-type\": application/json\n\"@signature-params\": (\"@method\" \"@target-uri\" \"@authority\" \"content-type\");created=1776520800;expires=1776521100;nonce=\"KXYnfEfJ0PBRZXQyVXfVQA\";keyid=\"test-ed25519-2026\";alg=\"ed25519\";tag=\"adcp/request-signing/v1\"",
+  "expected_outcome": {
+    "success": false,
+    "error_code": "request_target_uri_malformed",
+    "failed_step": 10
+  },
+  "$comment": "The URL is the valid bracketed form https://[::1]/..., and the Signature is a real Ed25519 signature by test-ed25519-2026 over the base computed from the URL authority '[::1]', so the Host header is the only fault. The profile derives @authority from the as-received Host header and canonicalizes it by the same algorithm as @target-uri; an IPv6 literal outside brackets ('::1') is ambiguous with a port and is malformed (canonicalization.json case malformed-bare-ipv6), so the verifier MUST reject with request_target_uri_malformed at step 10. A verifier that derives @authority from the URL alone never judges the header, computes the signed base, verifies the signature, and wrongly accepts. failed_step is informational: step 10 is where @authority derivation happens; grading is on the error code."
+}

package/compliance/cache/3.2.4/test-vectors/request-signing/positive/013-two-signature-labels-distinct.json

@@ -0,0 +1,32 @@
+{
+  "name": "Two distinct signature labels on both Signature-Input and Signature — verifier processes sig1 and does not reject the dictionaries",
+  "spec_reference": "#adcp-rfc-9421-profile (One signature per request); #verifier-checklist-requests step 1 (duplicate-key rejection applies to repeated labels, not to distinct ones)",
+  "signing_profile_version": "3.1",
+  "reference_now": 1776520800,
+  "request": {
+    "method": "POST",
+    "url": "https://seller.example.com/adcp/create_media_buy",
+    "headers": {
+      "Content-Type": "application/json",
+      "Signature-Input": "sig1=(\"@method\" \"@target-uri\" \"@authority\" \"content-type\");created=1776520800;expires=1776521100;nonce=\"KXYnfEfJ0PBRZXQyVXfVQA\";keyid=\"test-ed25519-2026\";alg=\"ed25519\";tag=\"adcp/request-signing/v1\", sig2=(\"@method\" \"@target-uri\" \"@authority\");created=1776520800;expires=1776521100;nonce=\"m4Fq2xYt9ZbCwLJd7sVn8g\";keyid=\"test-ed25519-2026\";alg=\"ed25519\";tag=\"adcp/request-signing/v1\"",
+      "Signature": "sig1=:U51PJzU9nMJxMAH_u-UDpSecT5SQX1-deSnWE3XpFo-BLT2_2h5FgMltntNCW05chhmFnjZEzkRmaYKeU0UUBw:, sig2=:AwoRGB8mLTQ7QklQV15lbHN6gYiPlp2kq7K5wMfO1dzj6vH4_wYNFBsiKTA3PkVMU1phaG92fYSLkpmgp661vA:"
+    },
+    "body": "{\"idempotency_key\":\"vector-positive-013-two-signature-labels-distinct\",\"account\":{\"brand\":{\"domain\":\"acmeoutdoor.example\"},\"operator\":\"pinnacle-agency.example\",\"sandbox\":false},\"packages\":[{\"product_id\":\"prod-1\",\"budget\":5000.0,\"pricing_option_id\":\"cpm_usd_fixed\",\"paused\":false}],\"brand\":{\"domain\":\"brand.example\"},\"start_time\":\"2027-01-04T00:00:00Z\",\"end_time\":\"2027-02-01T00:00:00Z\",\"paused\":false,\"plan_id\":\"plan_001\"}"
+  },
+  "verifier_capability": {
+    "supported": true,
+    "covers_content_digest": "either",
+    "required_for": [
+      "create_media_buy"
+    ]
+  },
+  "jwks_ref": [
+    "test-ed25519-2026"
+  ],
+  "expected_signature_base": "\"@method\": POST\n\"@target-uri\": https://seller.example.com/adcp/create_media_buy\n\"@authority\": seller.example.com\n\"content-type\": application/json\n\"@signature-params\": (\"@method\" \"@target-uri\" \"@authority\" \"content-type\");created=1776520800;expires=1776521100;nonce=\"KXYnfEfJ0PBRZXQyVXfVQA\";keyid=\"test-ed25519-2026\";alg=\"ed25519\";tag=\"adcp/request-signing/v1\"",
+  "expected_outcome": {
+    "success": true,
+    "verified_label": "sig1"
+  },
+  "$comment": "False-positive guard for negative/029 and 021: Signature-Input and Signature each carry two DISTINCT labels (sig1, sig2), which is legal. sig1 is a real Ed25519 signature over expected_signature_base; sig2 has a different covered-components set, a different nonce, and a well-formed 64-byte value that does not verify. Verifiers MUST process exactly one label (conventionally sig1) and ignore the rest; attempting sig2 and rejecting is non-conformant. Differs from 004-multiple-signature-labels only in sig2's signature bytes: 004 uses a run of 'A' (decodes to a 66-byte zero value, not a 64-byte signature), so a verifier that shape-validates every Signature member could pass 004 by luck; here the extra member is a correctly sized 64-byte signature. Signature generated with the test-ed25519-2026 private key from expected_signature_base."
+}

package/compliance/cache/3.2.4/test-vectors/request-signing/positive/014-content-digest-two-algorithms.json

@@ -0,0 +1,32 @@
+{
+  "name": "Content-Digest carries sha-256 and sha-512, both correct — distinct algorithm keys are legal",
+  "spec_reference": "#verifier-checklist-requests steps 1 and 11 (RFC 9530 §2: Content-Digest is a Dictionary keyed by lowercase algorithm name; RFC 8941 §3.1.2)",
+  "signing_profile_version": "3.1",
+  "reference_now": 1776520800,
+  "request": {
+    "method": "POST",
+    "url": "https://seller.example.com/adcp/create_media_buy",
+    "headers": {
+      "Content-Type": "application/json",
+      "Content-Digest": "sha-256=:vyR23LVTR1W-_gnNrZDaxId_kmAB7lQ34b1NNNhX9a0:, sha-512=:qORTgRshnU8ahelPs1uOk75o3XC2L6LDEWoAlnFrNXrfjMk0Cil1vkqbjFwE9KHRsTNDyAsPD1_-eW8kBnFQOA:",
+      "Signature-Input": "sig1=(\"@method\" \"@target-uri\" \"@authority\" \"content-type\" \"content-digest\");created=1776520800;expires=1776521100;nonce=\"KXYnfEfJ0PBRZXQyVXfVQA\";keyid=\"test-ed25519-2026\";alg=\"ed25519\";tag=\"adcp/request-signing/v1\"",
+      "Signature": "sig1=:ULMYyZqThGeyjciOwuH8Zp8-1MnrMTYQj2vbmN4QjGe9xDRU9gR9UnR_utuy5Ja7YZc3jgDgOYuyCC95mEeZCA:"
+    },
+    "body": "{\"idempotency_key\":\"vector-positive-014-content-digest-two-algorithms\",\"account\":{\"brand\":{\"domain\":\"acmeoutdoor.example\"},\"operator\":\"pinnacle-agency.example\",\"sandbox\":false},\"packages\":[{\"product_id\":\"prod-1\",\"budget\":5000.0,\"pricing_option_id\":\"cpm_usd_fixed\",\"paused\":false}],\"brand\":{\"domain\":\"brand.example\"},\"start_time\":\"2027-01-04T00:00:00Z\",\"end_time\":\"2027-02-01T00:00:00Z\",\"paused\":false,\"plan_id\":\"plan_001\"}"
+  },
+  "verifier_capability": {
+    "supported": true,
+    "covers_content_digest": "required",
+    "required_for": [
+      "create_media_buy"
+    ]
+  },
+  "jwks_ref": [
+    "test-ed25519-2026"
+  ],
+  "expected_signature_base": "\"@method\": POST\n\"@target-uri\": https://seller.example.com/adcp/create_media_buy\n\"@authority\": seller.example.com\n\"content-type\": application/json\n\"content-digest\": sha-256=:vyR23LVTR1W-_gnNrZDaxId_kmAB7lQ34b1NNNhX9a0:, sha-512=:qORTgRshnU8ahelPs1uOk75o3XC2L6LDEWoAlnFrNXrfjMk0Cil1vkqbjFwE9KHRsTNDyAsPD1_-eW8kBnFQOA:\n\"@signature-params\": (\"@method\" \"@target-uri\" \"@authority\" \"content-type\" \"content-digest\");created=1776520800;expires=1776521100;nonce=\"KXYnfEfJ0PBRZXQyVXfVQA\";keyid=\"test-ed25519-2026\";alg=\"ed25519\";tag=\"adcp/request-signing/v1\"",
+  "expected_outcome": {
+    "success": true
+  },
+  "$comment": "False-positive guard for negative/023 and 030. Content-Digest carries two members with distinct lowercase algorithm keys, sha-256 and sha-512, each the correct digest of the body (unpadded Base64URL, as in the rest of the 3.1 root corpus). A verifier that rejects every multi-member Content-Digest, or every comma in it, fails here; a verifier that checks only one algorithm still passes because both are correct. content-digest is covered and the Signature is a real Ed25519 signature by test-ed25519-2026 over expected_signature_base, which includes the Content-Digest value verbatim."
+}