GDPR Compliance & Right to be Forgotten

Under GDPR Article 17 (Right to be Forgotten), organizations must permanently delete or irreversibly anonymize customer personal data (PII) upon request.

In a Zero-Knowledge, cryptographically chained ledger like Volidator, deleting raw database entries presents a unique challenge: completely removing a database row breaks the integrity chain (chainHash), triggering data tampering alerts. Volidator solves this through Cryptographic Tombstoning and Blind Index Receipts.

---

1. Cryptographic Tombstoning

Rather than deleting entire database records, Volidator performs a secure Tombstone operation:

1. Payload Erasure: The client-encrypted payload (encryptedPayload) is overwritten with a static placeholder: {"status": "GDPR_PURGED"}.
2. Claim Check Purge: Any large text files stored externally in Cloudflare R2 object storage (using the Claim Check pattern) are permanently deleted.
3. Context Cleanup: The reasoning contexts (agentContext) and WebAuthn biometric proofs (attestationProof) are cleared.
4. Ledger Integrity Maintained: The record id, logicalClock, and sequence chainHash remain intact. Subsequent logs do not experience hash-link gaps, ensuring ledger integrity checks continue to pass successfully.

---

2. Programmatic Deletion via SDK

B2B users can trigger a deletion programmatically from their backend application by passing the customer’s raw identifier to the SDK:

import { VolidatorClient } from "@volidator/node";

const client = new VolidatorClient({
  projectId: "prj_live_123",
  apiKey: "val_live_abc",
  encryptionKey: "your-symmetric-decryption-key-here"
});

// Purges all logs where this customer was the primary actor
const { deletedCount } = await client.purgeActorLogs("usr_alice");
console.log(`Successfully tombstoned ${deletedCount} logs.`);

SDK Blind Indexing Behavior

To ensure Zero-Knowledge privacy, the SDK does not transmit the string "usr_alice" to the Volidator edge nodes. Instead, it:

1. Hashes the raw customer ID locally in your server memory using the symmetric decryption key to derive the deterministic actorBlindIndex.
2. Initiates an authenticated DELETE request to /v1/projects/:projectId/actors/:actorBlindIndex.
3. The raw identifier never leaves your environment.

---

3. Visual Deletion via the Dashboard

Compliance administrators can also trigger purges manually:

1. Navigate to Dashboard > Project Detail Settings.
2. Scroll to the GDPR & Data Privacy (Right to be Forgotten) section.
3. Enter your Symmetric Encryption Key (DEK) and the Customer / Actor ID.
4. Click Purge Actor Logs.

Like the SDK, the Dashboard computes the blind index in-browser using window.crypto.subtle. The symmetric decryption key is never transmitted to Volidator workers.

---

4. Platform Audit Recording

To reconcile the GDPR deletion with compliance requirements, Volidator generates an immutable log entry in the platform’s internal audit trail (platform_audit_logs) whenever a purge is completed.

Resolving the Logging Irony

To prove a user’s data was deleted without keeping a record of their identity (which would violate GDPR), Volidator records the blind index receipt in the platform logs:

Action:   GDPR_PURGE
Details:  Programmatic purge executed for actor blind index: 8a7c2f01d4... (Tombstoned: 14 events)

This receipt allows you to confirm deletion to auditors at any time:

1. The auditor requests proof of deletion for usr_alice.
2. You generate the index of usr_alice locally in your browser (8a7c2f01d4...).
3. You search the platform log for that index to show the signed confirmation event.

---

5. Edge Worker Security Verification Gates

To prevent unauthorized, rogue, or malicious deletions, the Volidator Edge routing logic enforces three atomic verification gates before any databases are mutated:

A. Credential Classification Gate

The edge worker instantly rejects DELETE requests authenticated with a machine credential prefix (val_agent_) unless it is accompanied by:

• An active Agent Session Token (sessionToken: "ast_xxxx")
• A valid WebAuthn hardware signature payload (challenge, signature, clientDataJSON, authenticatorData, and credentialId).

This ensures that autonomous agents can never trigger data deletions on their own standalone authority without verified human oversight.

B. Payload Canonicalization Sync

To verify the WebAuthn signature, both the client SDK (or dashboard browser) and the Edge Verification worker must use the exact same deterministic JSON serialization algorithm. Volidator canonicalizes the action parameters (action: "GDPR_PURGE", the target actorBlindIndex, and the maxCreatedAt ceiling timestamp) by sorting keys alphabetically before hashing via SHA-256. This ensures signature checks align precisely.

C. Nonce Invalidation

Every biometric WebAuthn verification challenge is generated by the server and registered as a single-use entry in the D1 database. Upon processing the DELETE request, the edge worker deletes the challenge entry atomically: db.delete(activeChallenges).where(eq(activeChallenges.challenge, challenge)).returning().get() This invalidates the challenge nonce before executing any cryptographic signature matching checks, neutralizing replay attacks.