Summary
The header comment in test-kits/signed-requests-runner.yaml says the signed-requests storyboard grades a verifier against 28 conformance vectors. The vector set is 40 — 12 in positive/ and 28 in negative/.
# static/compliance/source/test-kits/signed-requests-runner.yaml:6-7
# The signed-requests storyboard grades an agent's RFC 9421 verifier against 28
# conformance vectors at /compliance/{version}/test-vectors/request-signing/.28 is exactly the size of negative/ at 3.1.x, so the count appears to omit the positive set.
Scope — comment only
The graded contract is correct and unaffected. universal/signed-requests.yaml states no total: it has separate Positive conformance vectors and Negative conformance vectors steps, and its expected outcome reads "All vectors in positive/ produce 2xx, and all vectors in negative/ produce 401…". A runner reading the storyboard grades all 40. No runner behavior changes.
Why it is still worth fixing
That header is the first prose an implementer reads about the vector set, and it lives in the file the storyboard points at for the stateful-vector contract — so it is reached precisely when someone is planning their conformance run.
Taking it at face value drops the 12 positive vectors, which are the canonicalization edges: default-port stripping, dot-segment paths, percent-encoded path/unreserved/slash handling, query-byte preservation, IPv6 authority, multiple signature labels, ES256. A verifier can pass all 28 negatives and still fail those — the symptom being rejection of validly-signed requests from conformant counterparties, which is the failure the positive set exists to catch. Signing-base construction is the known hard part of RFC 9421 interop, so under-grading exactly there is the costly direction to be wrong in.
Concretely: it caused us to write "28 vectors" into an implementation plan's acceptance criteria, which would have let that task pass while grading only the negative set. We caught it by counting the directories.
Affected versions
The header has said 28 in every published version from 3.0.1 through 3.1.1 (44 versions), and originates in the generator input at static/compliance/source/test-kits/signed-requests-runner.yaml.
Worth noting it was never accurate: at 3.0.x the set was 39 (12 positive + 27 negative), so 28 did not match the total or the negative count there either. Vector 028-unsigned-protocol-method-required was added in 3.1.0, which is what made 28 coincide with len(negative/).
Suggested fix
In the source file, either state the split or drop the number:
# The signed-requests storyboard grades an agent's RFC 9421 verifier against 40
# conformance vectors (12 positive + 28 negative) at
# /compliance/{version}/test-vectors/request-signing/.Dropping the count entirely would also match universal/signed-requests.yaml, which deliberately refers to the directories rather than a number and therefore cannot drift.
Summary
The header comment in
test-kits/signed-requests-runner.yamlsays the signed-requests storyboard grades a verifier against 28 conformance vectors. The vector set is 40 — 12 inpositive/and 28 innegative/.28is exactly the size ofnegative/at 3.1.x, so the count appears to omit the positive set.Scope — comment only
The graded contract is correct and unaffected.
universal/signed-requests.yamlstates no total: it has separatePositive conformance vectorsandNegative conformance vectorssteps, and its expected outcome reads "All vectors in positive/ produce 2xx, and all vectors in negative/ produce 401…". A runner reading the storyboard grades all 40. No runner behavior changes.Why it is still worth fixing
That header is the first prose an implementer reads about the vector set, and it lives in the file the storyboard points at for the stateful-vector contract — so it is reached precisely when someone is planning their conformance run.
Taking it at face value drops the 12 positive vectors, which are the canonicalization edges: default-port stripping, dot-segment paths, percent-encoded path/unreserved/slash handling, query-byte preservation, IPv6 authority, multiple signature labels, ES256. A verifier can pass all 28 negatives and still fail those — the symptom being rejection of validly-signed requests from conformant counterparties, which is the failure the positive set exists to catch. Signing-base construction is the known hard part of RFC 9421 interop, so under-grading exactly there is the costly direction to be wrong in.
Concretely: it caused us to write "28 vectors" into an implementation plan's acceptance criteria, which would have let that task pass while grading only the negative set. We caught it by counting the directories.
Affected versions
The header has said
28in every published version from 3.0.1 through 3.1.1 (44 versions), and originates in the generator input atstatic/compliance/source/test-kits/signed-requests-runner.yaml.Worth noting it was never accurate: at 3.0.x the set was 39 (12 positive + 27 negative), so
28did not match the total or the negative count there either. Vector028-unsigned-protocol-method-requiredwas added in 3.1.0, which is what made28coincide withlen(negative/).Suggested fix
In the source file, either state the split or drop the number:
Dropping the count entirely would also match
universal/signed-requests.yaml, which deliberately refers to the directories rather than a number and therefore cannot drift.