Understanding the Identity-Integrity Gap in Digital Signing

A signature has always been a powerful symbol of agreement. Whether on a paper contract or a digital form, it serves as proof that a specific person reviewed and approved a specific piece of information. But what happens if the document you signed can be subtly changed after you sign it, without technically breaking the signature? This is the crucial problem that modern digital signing in healthcare must solve.

This article explains this challenge, known as the 'identity-integrity gap', and explores the elegant process used to solve it, ensuring that a digital signature in healthcare is an unbreakable link between a person and the exact data they approved.

The Two Critical Questions Every Signature Must Answer

At its core, a digital signing system has two fundamental jobs. While traditional systems focus on the first, high-security environments like healthcare absolutely depend on the second.

• Traditional Signing Asks: "Who signed this?"
• Healthcare Signing MUST Also Ask: "What exactly was signed?"

The space between these two questions is the "identity-integrity gap." While knowing the who is important (identity), that knowledge becomes useless if you can't be certain about the what (integrity). This is because a digital signature is not a snapshot of a document; it is a mathematical proof that a key signed a specific input of data. If that input doesn't perfectly and reliably represent the clinical content, the signature is meaningless.

This gap exists because the type of data used in modern systems is fundamentally different from a simple, static document.

The Challenge:
Signing "Squishy" Data like JSON

Unlike a PDF, which is a fixed visual snapshot, modern clinical data is often exchanged as structured data using formats like JSON, thanks to FHIR. This data is incredibly flexible, but that flexibility makes it "squishy" or mutable, which poses a huge challenge for digital signing.

Here are the key reasons this data is so difficult to sign directly:

• Order Insensitive: In a JSON file, the order of data fields can change without altering the clinical meaning. To a signing algorithm, this is a completely different input, causing verification to fail even though the medical information is identical.
• Easily Transformed: As data moves between systems, from a doctor's tablet to a hospital server to a pharmacy, intermediary gateways and databases can make small, non-meaningful changes, like adding or removing whitespace. These transformations can break a simple signature.
• Regenerated from Databases: The "document" a doctor signs might not be a static file but data pulled from a database. If that same data is pulled a second time for verification, it might not be bit-for-bit identical to what was originally shown, again causing a signature mismatch.

A simple signature is just a mathematical proof based on an input. If the input can change in non-meaningful ways, the proof breaks. This means a perfectly valid signature could fail. Worse, a failure in the signing model could allow two documents that represent different clinical intent to appear valid. To solve this, we can't sign the "squishy" data directly. Instead, we must sign a stable, reliable "fingerprint" of it.

The Solution:
A Three-Step Process for Trust

Canonicalize → Fingerprint → Sign

To provide true cryptographic proof of integrity, the solution cannot be an afterthought; it must be a core design principle. Any system that signs data without first making it stable, or that relies on server logs to prove integrity, is fundamentally broken. The only way to forge a trustworthy, unbreakable link between a signer and their content is through a deliberate, multi-step process.

• Step 1: Canonicalization (Create a Standard Version) This is the process of converting the "squishy," unpredictable JSON data into a single, official, and deterministic format. Think of it as applying a strict set of rules (e.g., "all fields must be alphabetized," "all extra whitespace must be removed") to the data. Crucially, these rules are themselves documented and versioned.

Why it's necessary: Canonicalization guarantees that any two documents with the exact same clinical meaning will always produce the exact same standard version, byte for byte. Versioning the rules ensures that a signature created today can still be correctly verified five years from now, even if the rules evolve.

• Step 2: Fingerprinting (Get a Unique ID) Once the data is in its standard, canonical form, a cryptographic hash algorithm is used to generate a unique, collision-resistant digital fingerprint. This fingerprint is a small, portable string of characters that represents the entire document.

Why it's necessary: A good hash algorithm ensures that changing even a single bit in the standardized content, like changing a medication dosage from "10mg" to "20mg", will produce a completely different fingerprint. This makes tampering instantly detectable.

• Step 3: Signing the Fingerprint (The Act of Approval) Finally, the doctor or healthcare professional performs the signing action. They do not sign the entire clinical document. Instead, they use their private key to cryptographically sign only the small, stable fingerprint. The resulting signature is then packaged as a self-contained proof.

Why it's necessary: This act creates a mathematical proof that binds the signer's identity to that specific fingerprint. The final signature package includes not just the signed fingerprint, but also the "recipe" for verification, the exact canonicalization version and hash algorithm used. This is the key that makes truly independent proof possible.

By signing a stable fingerprint instead of the raw data, we create a signature that can be reliably checked by anyone, anywhere, at any time.

Independent and Long-Term Proof

The primary benefit of this design is that the integrity of the signed document can be proven by anyone, independently, without needing to trust the original signing system. When it's time to verify a signature, perhaps years later during an audit, a verifier does not need to:

• Call the original signing server.
• Trust the logs or databases of the vendor who created the signature.
• Have access to any proprietary systems.

All a verifier needs is the document itself, the attached signature, and the signer's public certificate. Because the signature itself contains the exact 'recipe' used to create the original fingerprint (the canonicalization rules and hash algorithm), the verifier can precisely repeat the process. They re-canonicalize the document, re-compute the fingerprint, and confirm it matches what was signed.

This is the gold standard for healthcare because it replaces weak, "procedural" trust with absolute, cryptographic proof. Relying on a vendor's server logs or database state is unacceptable for long-term audits or legal challenges. A self-contained, independently verifiable signature provides true, cryptographically sound proof of integrity that can stand up to legal and regulatory scrutiny for years to come.

Closing the Gap

Ensuring trust in healthcare data requires more than just knowing who signed a document; it demands absolute certainty about what they signed. By understanding and addressing the unique challenges of modern structured data, we can close the gap between identity and integrity.

The entire process can be distilled into three key takeaways:

• The Problem: Traditional signatures prove who signed, but in healthcare, you must also prove what was signed. This is the identity-integrity gap.
• The Cause: Modern structured data (JSON) is not bit-for-bit stable; its inherent flexibility means that routine system-to-system transmissions can cause non-meaningful changes that incorrectly break a signature's validity.
• The Solution: A process of Canonicalization and Fingerprinting creates a stable representation of the content, allowing a signature to provide true, long-term, and independently verifiable proof of data integrity.

In healthcare, trust must survive system boundaries, time, and vendors.
Formidable eSign ensures that trust is cryptographically preserved.

The Explainer by Notebook LM