Rox Register, Developers

JWS test vectors

Golden vectors for the RRv1 request-signing scheme, wire them into your test suite before you ship. Each vector carries the key pair, the exact canonical input and the expected signature; the empty-body, unicode and raw-binary cases are the ones that catch implementation bugs. These vectors cover both supported key types, Ed25519 and P-256, for YOUR request-signing key, the key that proves an API call came from you. They are unrelated to how anchors are signed on chain, which is done by the 3-of-5 MPC node fleet and never involves your key.

Canonical signing input (spec §7.3), method uppercased, path verbatim, timestamp unix milliseconds, nonce a uuid; signature is the raw Ed25519 (or P-256 r||s) signature, base64url in X-RR-Signature:

RRv1\n{method}\n{path}\n{sha256_hex(raw body)}\n{X-RR-Timestamp}\n{X-RR-Nonce}

jws-vectors.json6 vectors · Ed25519 + P-256

Ed25519Ed25519 over a plain JSON seal bodyPOST /v1/seal

Ed25519Ed25519 over an EMPTY body (bodyless mutation hashes the empty string)DELETE /v1/vaults/vault_01ARZ3NDEKTSV4RRFFQ69G5FAV/request-keys/corp-key-1

Ed25519Ed25519 over a UNICODE body (Arabic + emoji, hashed as UTF-8 bytes)POST /v1/seal

P-256P-256 (raw r||s) over a plain JSON seal bodyPOST /v1/seal

P-256P-256 over an EMPTY bodyDELETE /v1/vaults/vault_01ARZ3NDEKTSV4RRFFQ69G5FAV/request-keys/corp-key-2

Ed25519Ed25519 over RAW BINARY bytes (multipart-less canonicalization: sha256 of exact wire bytes)POST /v1/seal/stamp

Ed25519 vectors are deterministic, your implementation must reproduce the signatures byte-for-byte. P-256 signatures are randomized: verify them against the vector's public key instead. Regenerated at build by @rox-register/api scripts/gen-jws-vectors.ts.