Deterministic One-Way PII Obfuscation with Latent Re-Identification-Attempt Detection

Executive Summary

As part of honoring erasure requests, JIL Sovereign's data-rights mechanism replaces each PII field value with a deterministic one-way hash computed over the original value concatenated with the data subject's identifier - for example, SHA-256(value | member_id). Because the transformation is deterministic rather than randomized, no per-obfuscation salt or nonce is introduced: the same (value, subject) pair always produces the same hash.

That determinism has a specific, deliberate consequence: if an upstream source system later re-imports the same PII value for the same, already-forgotten data subject, re-applying the identical obfuscation function to the newly-imported value reproduces the exact hash already stored for that subject's field, without ever comparing or storing plaintext. This creates a latent capability to detect reintroduction of previously-erased personal data - a capability a conventional salted or randomized scheme would foreclose by design.

Problem Statement

Standard practice for irreversibly obfuscating PII - salted hashing, encryption followed by key destruction, tokenization with randomly generated tokens - is deliberately randomized so the same input never produces the same obfuscated output twice, which is the right choice when the only goal is preventing reversal or correlation of the obfuscated value. But that same randomization also means that if an upstream source system re-imports the same personal data for a data subject who has already exercised an erasure right - a real-world failure mode arising from batch feeds, legacy integrations, or a source-of-truth system never informed of the erasure - there is no way to detect that reintroduction at the obfuscation layer, because the newly-obfuscated value looks unrelated to the previously-obfuscated one even though the underlying plaintext is identical.

Why Randomized Obfuscation Falls Short Here

• Salted/randomized PII hashing (bcrypt, per-record salt): defeats reintroduction detection by design, since equal inputs no longer produce equal outputs.
• Tokenization with randomly generated tokens: same limitation - no way to detect reintroduction of the same underlying value.
• Data masking (format-preserving encryption, static masking): typically reversible by a keyholder, which is inappropriate for records tied to an erasure request.

Technical Architecture

Obfuscation Function

For a PII field value V belonging to data subject M, compute H = SHA-256(V || member_id_M) and store H in place of V; the original plaintext value is not retained.

Reintroduction Detection Logic

Current Activation Status

The comparison logic is enabled by the deterministic design of the obfuscation function, but as of this filing no downstream consumer performs the comparison in production - the capability is designed-in and available to be activated as a monitoring or alerting consumer, rather than presently wired into an active detection pipeline.

Zero-Knowledge-Adjacent Property

The detection mechanism proves value-equality across two obfuscation events without either party - the detection consumer or an auditor - ever needing to see or store the underlying plaintext PII, a property that shares its underlying logic with, but is architecturally distinct from, the commitment-based compliance-proof mechanisms used elsewhere in JIL's attestation stack.

Prior Art Differentiation

Patent Claim