JAdES is live: ETSI-standard seals for JSON

Most of the evidence produced by modern systems is not a PDF. It's JSON: an API response, a model output, an agent's tool-call log, a decision record, a line in a JSONL audit trail. When that JSON needs to be provable — this is exactly what the system said, and it hasn't changed since — it deserves a seal format designed for it, not a workaround.

That format exists. JAdES (ETSI TS 119 182-1) is the ETSI signature standard for JSON, built on JWS — the same family of standards behind PAdES for PDFs and CAdES for arbitrary files. It's now live on sigill.ai: in the API, in the web app, and in both SDKs.

Why JSON needed its own format

You could always seal JSON with a universal (CAdES) seal — it's just bytes, after all. That still works, and for some pipelines it's the right choice. But JAdES is the format a JSON-native ecosystem should converge on, for two reasons.

First, it speaks the ecosystem's language. A JAdES seal is itself a JSON artifact (a detached JWS with a sigD component identifying what was signed). It travels through JSON-oriented systems — APIs, message queues, document stores — without impedance. Your tooling can parse it, log it, and route it like everything else it handles.

Second, it's precise about what "unchanged" means. A JAdES seal covers the exact bytes of the JSON you sealed. Re-serialize the same object — reorder keys, change whitespace, pretty-print it — and the seal breaks. That's not a limitation; it's the design. Evidence is bytes, not semantics, and a seal that survived re-serialization would be a seal that couldn't distinguish your original record from a convenient reconstruction of it.

Built for AI evidence

This is the part we care most about. If you follow this blog, you know the pattern we've been building since the first timestamped agent post: AI systems produce output at machine speed, and organisations increasingly need to prove what those systems did — to auditors, to counterparties, to courts, to their future selves.

That evidence is JSON all the way down. Prompts and completions. Tool calls and their results. AI evidence envelopes. Agent session logs. With JAdES, the seal on that evidence is now the ETSI-standard one:

from sigill_sdk import SigillClient

client = SigillClient(api_key="sigill_...")

log = open("agent-session.jsonl", "rb").read()
jades = client.seal_jades(log, certificate_id=CERT_ID,
                          label="agent-session.jsonl",
                          content_type="application/json")
# store agent-session.jsonl.jades.json alongside the log

result = client.verify_jades(log, jades)
assert result.is_valid

One call in Python (seal_jades), one in .NET (SealJadesAsync). And if you're already sealing AI evidence envelopes, you can put an organisation seal on the envelope itself by sealing its canonical bytes — the envelope's RFC 3161 proof says when, the JAdES seal says who stands behind it.

Privacy: only the hash leaves your systems

Like our CAdES seals, JAdES sealing is hash-only by default. Your system computes the SHA-256 digest locally and sends the digest — the JSON itself never reaches sigill.ai. What comes back is the detached seal artifact, timestamped by an independent timestamp authority. For a compliance log full of customer data or a prompt containing PII, this matters: the seal proves the content without the content ever crossing the wire.

Verification works the same way: digests plus the seal artifact. And as with everything we produce, verification is free and public — no account required, and because JAdES is an open ETSI standard, you're never locked into our tooling to prove your own evidence.

Post-quantum, included

JAdES seals support the same ML-DSA-87 hybrid we shipped for universal seals: pass pqc=True and the seal carries a second, quantum-resistant signature (NIST FIPS 204, encoded per RFC 9964 as an additional JWS signature) alongside the classical one. Two independent signatures over the same bytes, in one artifact.

Why this matters for JSON evidence specifically: AI-related records are exactly the kind of long-lived evidence the "harvest now, decrypt later" threat model targets. A decision log sealed today may need to hold up in fifteen years. The classical signature is the legal instrument today; the ML-DSA signature is the insurance policy for the day classical signatures stop being enough. (Our post-quantum post goes deeper on this.)

Qualified, eIDAS-recognised timestamps are available on JAdES seals too — the same qualified: true flag as everywhere else on the platform.

The complete picture

With JAdES live, the format matrix is simple:

All three are open ETSI/IETF standards. All three support hash-only sealing. All support qualified timestamps, and the two detached formats support the post-quantum hybrid.

JAdES sealing is available now on Business and Scale plans — from the API, the web app, and the v0.3.0 SDKs on PyPI and NuGet.