Privacy and erasure

Agreely is built so that proving consent does not require holding the data, and so that erasing consent destroys the readable claim rather than promising to. This page covers two distinct rights that are easy to conflate, and the crypto-shred that backs the erasure of Agreely's own copy.

#Withdrawal is not erasure

Two different rights sit behind "stop using my data," and Agreely keeps them apart on purpose.

• Withdrawal (P-39.1 s. 8, first paragraph, subparagraph 4; A-2.1 s. 65, first paragraph, subparagraph 5) ends a live consent. It flips the enforcement record to revoked, and the very next check denies. Withdrawal deliberately keeps a record: the consentRef, the receipt, and the anchored commitment all survive, because being able to prove that a consent existed and was then withdrawn is what lets the organization account for its consents (P-39.1 s. 3.1, first paragraph; A-2.1 s. 52.2).
• Erasure (P-39.1 s. 23; A-2.1 s. 73) is a request to destroy. It is not a status flip; it crypto-shreds Agreely's own readable copy of the cell and produces a request the company must honor in its own systems. Agreely cannot reach into your database, so erasure is Agreely's part plus your obligation, not a single switch.

When information rests on a declared basis other than consent, erasure withdraws the consent, which can no longer be relied on, but the company keeps the information on that other basis: the erasure request is then recorded as deferred, and the information must be destroyed or anonymized once the purposes are achieved, subject to the time limits provided by law. The person is told so before confirming.

#Crypto-shred erasure

Agreely implements erasure of its own copy per-cell as a crypto-shred. Each consent cell is bound by a commitment:

commitment = keccak256( JCS(claim) || salt32 )

The 32-byte salt is the cell's only secret and the only thing that makes the commitment reversible to the claim. Erasing a cell destroys that salt (and the readable claim rows around it), while keeping the commitment so the surviving cells of the same consent still verify against the Merkle root. The synchronous check default-denies the instant the erase transaction commits.

#The honest boundary

It is tempting to claim erasure is instantaneous and total everywhere. It is not, and Agreely states the boundary plainly rather than overclaiming.

Concretely, the moment the erase transaction commits:

• the salt is gone from the live row, so the retained commitment is a one-way hash that is not reversible to the claim;
• the readable claim row (the plaintext category/purpose) is deleted;
• the synchronous check default-denies and the dashboard no longer lists the cell.

What still exists, until the retention window passes, is an unreadable residual that carries no category or purpose claim: the on-chain commitment is an orphan with its salt destroyed, and the remaining linkage ties a DID to an opaque random consent_ref. The database backups still hold the earlier state: Agreely keeps the full backups of the last 30 nights, with the write-ahead log that goes with them, and full physical destruction completes once the last backup taken before the erasure is discarded.

#Why the residual carries no identity

Erasure keeps a consent_ref-to-DID linkage as a Merkle sibling, without that residual carrying any readable claim: the consent_ref is a fresh, opaque random value, and the enforcement record that tied it to the company's customer reference is deleted at erasure. That is what lets Agreely retain the cryptographic proof of a consent while destroying its readable form. The precise boundary of what the separation of the two sides protects, and what it does not, lives on the Unlinkability page.

#Independent verifiability

The artifacts a person or auditor holds, the receipt, the DID documents, and the on-chain anchor, are enough to verify the signature on a grant without querying Agreely's database. The link between the key and the company's real domain, and the state of the consent, are confirmed online (DID registry, DNS and a chain read). One limit remains: the company's signing key is hosted by Agreely (see honest boundaries, point 7). See the verify recipe.

#Next

• Unlinkability: the full company/citizen non-correlation model.
• Honest boundaries: why "destroyed everywhere at all times" is a claim Agreely refuses to make.