Integrity Model

json‑seal provides a lightweight, explicit integrity and authenticity layer for any JSON‑serializable value. It produces a signed, tamper‑evident envelope containing:

Canonicalization

Before signing, the value is transformed into a stable, deterministic representation using a full implementation of the RFC 8785 JSON Canonicalization Scheme (JCS). This ensures that semantically identical values always produce the same canonical form and therefore the same signature. json‑seal canonicalizes JavaScript values, not raw JSON text.

Canonicalization is required because JSON is not deterministic across platforms; without a stable representation, signatures would not verify reliably between different runtimes.

Digest

The canonical form is signed using RSA‑PSS with SHA‑256. Internally, the canonical bytes are hashed with SHA‑256 as part of the signature operation. The digest is not stored in the envelope; it is recomputed implicitly during verification.

Digital Signature

json‑seal signs the canonicalized payload using RSA‑PSS with SHA‑256. Hashing is performed internally by the signature algorithm. The signature proves that the sealed document was created by whoever holds the corresponding private key. The public key is embedded directly in the envelope, making verification portable and self‑contained.

Verification

Verification re‑canonicalizes the payload and validates the RSA‑PSS signature using the embedded public key. If the signature is valid, the document is authentic and unmodified.

What is guaranteed

What is not guaranteed

json‑seal is intentionally small. It avoids ceremony and avoids over‑promising. Its goal is clarity, portability, and long‑term trust.

← Back