Digital signatures are often treated as a solved problem. In practice, most systems solve identity, not integrity, and the distinction becomes critical once signatures are applied to structured data rather than static documents.
Healthcare is a good example, but the issue is not healthcare-specific. Any system that signs structured, interoperable data eventually runs into the same failure mode.
This post explains why that happens and what a correct signing architecture looks like.
A real-world failure scenario
Consider a common workflow:
- A system generates a prescription encoded as structured data (for example, JSON).
- A clinician signs it.
- The data is transmitted to another system.
- The receiving system re-serializes the payload:
- Fields are reordered
- Optional fields are omitted
- Formatting and whitespace change
- Signature verification fails.
No semantic meaning changed.
No malicious modification occurred.
Yet cryptographically, the document is no longer identical.
This is not a bug. It is the expected outcome of signing non-canonical structured data.
Identity is not integrity
Any serious signing system must answer two different questions:
- Who signed this?
- Exactly what did they sign?
Most e-signature systems focus heavily on the first question:
- Authentication
- Identity proofing
- Audit logs
They often answer the second question implicitly by signing a particular file representation, assuming that representation is stable over time.
That assumption holds for PDFs.
It fails for structured data.
Cryptographic signatures are binary-exact.
Structured data is not.
Why structured data breaks naive signing models
Structured data is routinely:
- Stored in databases rather than files
- Regenerated on demand
- Transformed across APIs
- Normalized or enriched downstream
Two semantically identical objects can have multiple valid binary representations. A signature over one representation will not verify against another.
Without additional guarantees, signing structured data amounts to signing a transient serialization artifact rather than the underlying meaning.
That is not a durable proof.
Interoperability makes integrity unavoidable
As interoperability increases (for example, through FHIR in healthcare), systems exchange meaningful data, not frozen documents.
In this environment:
- Data crosses organizational boundaries
- Content is transformed and re-emitted
- Long-term verification matters
Connectivity without cryptographic integrity guarantees creates a false sense of trust. Systems can exchange data, but they cannot reliably prove that the data they consume is the data that was approved.
A signing architecture that preserves integrity
Closing this gap requires making the signed object deterministic.
A robust architecture consists of three explicit steps.
1. Canonicalization
Convert flexible structured data into a deterministic representation:
- Stable field ordering
- Normalized data types
- Removal of non-semantic noise
- Versioned canonicalization rules
Semantically identical data must produce identical bytes.
2. Fingerprinting
Hash the canonical representation using a collision-resistant algorithm.
This produces a fixed-length fingerprint that uniquely represents the content and changes completely if the meaning changes.
At this point, integrity is mathematically defined.
3. Signature
Sign the fingerprint, not the raw document.
This binds a signer’s identity to a precise, reproducible representation of the data. Anyone with the public key, the canonicalization rules, and the data can independently verify the signature.
No vendor trust required.
Why document-centric models fall short
Document-based signing works by freezing content into a visual artifact. Structured data systems do the opposite: they keep data queryable, transformable, and alive.
Applying document-centric integrity models to structured data is a category error.
The correct abstraction is not “sign the file.”
It is “sign the meaning.”
TLDR;
Digital signature systems were largely designed for documents, not interoperable data.
As systems become more connected, this mismatch surfaces as:
- Failed signature verification
- Fragile audit trails
- Legal ambiguity
- Compliance theater
Closing the gap does not require exotic cryptography. It requires discipline: canonicalization, fingerprinting, and explicit binding between identity and meaning.
If a signature cannot survive serialization, transport, and regeneration, it does not prove what it claims to prove.
Disclosure
I work at Formidable Care, where we are building Israel’s national digital prescription infrastructure. As interoperability increases, integrity becomes a collective responsibility, not a vendor-specific detail.
Top comments (0)