ANCHORED TOKENIZATION RECEIPTS

Anchored Tokenization Receipts

Records the lifecycle of a pseudonymous data token — issuance, redemption, revocation, and rotation. Provides the cryptographic substrate for GDPR Art. 4(5) pseudonymisation claims that hold up under supervisory scrutiny. Salted commit only — no plaintext PII touches the receipt.

ATokR · Shipped4 wire typesApache-2.0 · CC0 spec
← All familiesVerify a receipt →

WIRE TYPES

ar.tokenization.v1 (token.issued)

Records the issuance of a pseudonymous token. Carries scope-binding — audience, purpose, and validity period. The token_commit is a salted hash; the plaintext PII never leaves the issuer.

ar.tokenization.v1 (token.redeemed)

Records detokenization — the token was resolved back to the underlying identity. Verifier confirms the predecessor is an issued or rotated event on the same token chain.

ar.tokenization.v1 (token.revoked)

Records token revocation. Terminal event — the chain is closed and the predecessor's Status List bit flips to revoked.

ar.tokenization.v1 (token.rotated)

Records a token rotation — the old token is superseded by a new one. The predecessor's Status List bit flips to revoked; the new token starts a fresh chain referencing the rotation.

WHAT IT PROVES

  • — A token was issued, redeemed, revoked, or rotated before a specific UTC date (Merkle inclusion proof).
  • — The tokenization event was signed by a registered issuer key (Ed25519 signature check).
  • — A token's scope constraints — which audiences, purposes, and validity windows apply (body fields).
  • — The complete lifecycle of a token — from issuance through rotation or revocation (chain walk).

WHAT IT DOESN'T PROVE

  • — The tokenization algorithm is secure or irreversible.
  • — All copies of the plaintext PII have been removed after tokenization.
  • — The audience actually respected the scope constraints.
  • — Re-identification is impossible given auxiliary data.

COMPOSES WITH

ATokR receipts reference other family members via body-level composition pointers — verifier-coordinated, not signature-mandated.

ASRAnchored Subject-Rights Receipts

Detokenization or revocation triggered by a subject-rights request may reference the ASR receipt.

ARRAnchored Retention Receipts

Token revocation co-occurring with Art. 17 erasure of underlying plaintext may reference the ARR receipt.

ALRAnchored Lineage Receipts

When the tokenized value flows through a data pipeline, ATokR references the ALR receipt anchoring the lineage.

APuRAnchored Purpose Receipts

Purpose declared in ATokR scope is backed by an APuR purpose binding as the durable record.

Verify any
ATokR receipt.

verify.dekimu.com ↗

Paste any claim ID to verify a receipt, check its anchor, and inspect the issuer signature.

REFERENCES

GDPR Art. 4(5) — Definition of pseudonymisation (EUR-Lex) ↗
ePrivacy Directive 2002/58/EC (EUR-Lex) ↗
ISO/IEC 29101 — Privacy architecture framework ↗

Anchored Tokenization Receipts are cryptographic provenance and privacy-lifecycle protocols. verify.dekimu.com is a reference implementation, not a qualified trust service under Regulation (EU) No 910/2014 (eIDAS) or successor.