Reject-Test Sandbox

Use these negative cases to confirm that your integration fails closed. Each case is designed to return Rejected; your application must never convert these failures into an allow decision.

Common request boundary

POST /v1/hybrid/verify
x-api-key: <project-api-key>
content-type: application/json

{
  "payload": { ...canonical payload... },
  "public_key_hex": "<public-key>",
  "key_version": 1,
  "ml_dsa_65_signature_hex": "<signature>",
  "classical_verified": true
}

Case 1 — one-byte mutation

1. Create and sign canonical payload P.
2. Confirm P verifies as Valid.
3. Copy P to P'.
4. Change exactly one byte in P' without generating a new signature.
5. Submit P' with the original signature.
Expected result: Rejected.

Required evidence: [TO BE FILLED: published sample payload, signature, mutated byte offset, API response and local independent-verification result].

Case 2 — unregistered key

1. Generate a separate ML-DSA-65 keypair that is not registered for the target project/subject.
2. Sign the canonical payload with that private key.
3. Submit its public key and signature to the HybridRequired endpoint.
Expected result: Rejected.

Required evidence: [TO BE FILLED: sample request/response and expected machine-readable error code from the deployed API].

Case 3 — HybridRequired policy miss

1. Build otherwise valid registered-key ML-DSA-65 evidence.
2. Set classical_verified to false.
3. Submit the request under HybridRequired.
Expected result: Rejected.

Required evidence: [TO BE FILLED: sample request/response and expected machine-readable policy rejection code from the deployed API].

Integration rule

Timeout, malformed response, invalid signature, unregistered key, replay or policy rejection must not be treated as Valid. Your backend retains the final allow/deny decision.