Proving consent

For Data Protection Officers, counsel and auditors who must judge whether the consent evidence this product keeps would hold up when a consent is questioned.

Summary#

Under section 6(10) of India's DPDP Act, a Data Fiduciary has to prove that notice was given and consent obtained, if it is questioned. PIEDAP Consent records each answer against the exact version of the notice shown. It seals every change into a chain with a key held outside the database. It exports any record as a receipt signed with Ed25519, which anyone can check against a published public key. Once a day it puts each project's sealed events under one signed root and sends that root to you.

If you store those roots, a later change to a past day fails against your copy, whoever makes it. The design has limits: the operator's keys matter, today's events are anchored after the day closes, and the link from a hash to a named person stays with you. The product holds no certification, and no independent penetration test has been carried out.

What has to be proven#

A consent is worth what you can prove about it later. When someone questions a consent, the answer has to cover six things:

• what the person was shown
• what they chose, purpose by purpose
• when they chose it
• where they were, and under which law the notice was served
• that the record is about this person
• that nobody edited the answer afterwards

A row in a database can hold the first five. The sixth is what separates a log from evidence. A row that anyone with database access can rewrite proves only that the row says so today.

The DPDP Act puts the burden on you. As we read section 6(10), where a question arises in a proceeding, the Data Fiduciary has to prove that notice was given and that the person consented. This paper is not legal advice. What a court or the Board accepts as proof is for your counsel to judge.

Whom a reader has to trust#

Three parties could change a consent record after the fact:

• someone who can write to the database, whether an administrator or an intruder
• the operator of the deployment, who holds its keys
• your own organisation, which has an interest in the outcome

The design answers this with four layers of proof.

Read the table from the top. The record alone asks a reader to trust everyone who can write to the database. The chain removes that trust: a writer without the chain key cannot produce a keyed chain that verifies. The receipt lets a reader outside the project check a record. The anchor, once you hold it, removes the operator for every closed day.

The last layer is the only one that does not rely on the operator. It depends on a step that is yours: keeping the anchors.

What the record captures#

There is one record per person per form. Live and test records are kept apart. The record holds the current answer, and every change adds an event to its history.

The wording. Each record names the published form version the person saw, with a SHA-256 of that version's exact definition. A published version is frozen: changes go to the draft, and publishing makes a new version. The database refuses to delete a form, a version or a property that has consent records. The evidence therefore keeps the wording it points at.

The choice. There is one decision per purpose: its key, name, category and legal basis, whether it was allowed, and the time. Where the form lets people choose partners one by one, the decision also carries the partners that were refused. The record also holds what produced the state, such as an accept-all, a saved preference, a withdrawal or a server call.

The place and the law. The record holds the country, the subdivision where needed, and the law the form was served under. It holds the site or app that showed the notice, the channel, the language and the times.

The person. The identifier is stored as an HMAC-SHA256 hash under a secret pepper. The identifier itself is stored only when the project keeps a readable copy, and then encrypted.

A child or a person with a guardian. The record holds the relationship, the method and time of verification, and a keyed hash of the reference. Your systems verify the parent or guardian. The product records your result and does not check it.

Consent taken by your staff or on paper. A write from your server can carry the channel, such as a branch or a call centre, and how the person confirmed. That is a one-time password, a signed declaration, a recorded call, a paper form or a link on their own phone. It holds your reference to that evidence or the SHA-256 of the scan, and keyed hashes of the staff member and the site. It is sealed with that event only.

Consent given earlier. An answer brought in from before keeps the time it was given. It can carry the basis you state, such as consent given before the DPDP Act commenced, and the reference or SHA-256 of the notice the person saw. Both are sealed. An earlier answer never replaces a newer one, a withdrawal or an erasure.

How changes are sealed#

Every change of state adds an event. The event holds the full state at that moment and a seal. The seal is an HMAC-SHA256 over two things: the seal of the event before, and the state written as canonical JSON. The first event is sealed against 64 zeros.

Two properties follow. First, the events form a chain. Changing any past state means recomputing the seal of every later event.

Second, the seal needs a key. The chain key is a secret of the deployment, held outside the database. Someone who can write to the database but does not hold the key cannot produce a keyed chain that verifies.

The chain records the whole life of a consent: the first answer, each change of mind, a withdrawal, an expiry, an erasure, and each identifier linked later. Events are numbered within a record, and the database refuses two events with the same number. Reading does not change evidence. Exporting a receipt writes an event for the audit trail, and that event sits outside the chain.

The seal is keyed, so only the deployment can replay it. A plain hash could be recomputed by anyone, including someone who had edited the row. The cost of a keyed seal is that an outside reader needs another way to check. The receipt and the anchor are that way.

What a receipt gives a third party#

A receipt is the portable form of the proof. It is one JSON document that holds:

• the record: its id, the subject hash and type, the status, the environment, the jurisdiction and the decisions as they stand
• the subject fingerprint, unless the record is erased
• the form: its id, version, content hash and name, and the banner wording in the form's default language
• the sealed chain: each event's number, type, time and seal
• the result of replaying the chain when the receipt was issued
• for each event whose day is anchored, an inclusion proof and the signed anchor

The deployment signs the receipt with Ed25519. The public key is published as a JWK Set, with no account needed. A reader who saved that key set can check the signature without contacting the deployment at all.

The receipt does not copy everything. The purposes as shown, with their descriptions, data and partners, and the other languages are covered by the content hash. To read them, you compare the hash with that form version in the console.

How anchors take the operator out#

Sealing protects each record. It does not stop the holder of the keys from adding a record, or from sealing a different history. Anchors close that gap for every day that has ended.

At 00:15 UTC the deployment takes each closed day that has sealed events. It builds a Merkle tree over them, in the RFC 6962 construction used by Certificate Transparency. It signs a statement that holds the day, the event count, the root and the hash of the previous anchor. Each anchor names the one before it, so removing or re-issuing a day breaks every later link.

Each new anchor is sent to your webhooks as evidence.anchored. Once you hold a day's root in a system you control, nobody can change that day's events without the proofs failing against your copy. That includes the operator. Without your copy, you are trusting the deployment's own table.

One case needs care. If you run the deployment yourself, you are the operator. Your organisation then holds the keys and the anchors. The anchors are independent only if they are stored where the people who hold the deployment's keys cannot change them.

What survives erasure and retention#

A person can ask to be erased, and the proof has to survive that. Erasing never deletes history. If the consent is still in force, a withdrawal event is added first. An erasure event then seals the erased state.

The removed details were never part of the seal. That is what lets erasure remove them without breaking the proof. After erasure you can still show that a consent existed, what was chosen and when it ended. You can no longer find the record by a linked identifier, and its receipt carries no fingerprint.

Rule 8(3) of the DPDP Rules adds one exception. When a record under the Act is erased less than a year after its last processing, most of the removed details are held until the year is up. A daily job then clears them. Linked identifiers are removed at once.

Retention is a separate matter. When the operator turns enforcement on, a record whose consent has ended is deleted once its retention period is over. Only a hash of each event stays, so the day's anchor and earlier receipts still verify. The record itself is gone. Decide the period with that in mind: it can be 1, 3, 7 or 10 years, and is 7 by default.

How an auditor checks one consent#

A reviewer who wants to test one consent from end to end can follow these steps.

The signature, chain and anchor checks in steps 2, 5, 7 and 8 need no access to the product. The console and the API also run the signature, chain and anchor checks on a pasted receipt. Receipts describes the checks in detail.

What the evidence does not show#

The design is specific about what it proves. A reader should know where it stops.

• The keys matter. Whoever holds both the chain key and the signing key can create new, validly sealed records. Anchors held outside the deployment limit this to days not yet anchored.
• Today is not anchored yet. A day's events are covered by the anchor made after the day closes.
• A receipt alone does not re-run the seals. That needs the chain key. A third party relies on the signed replay result and, for independence, on the anchors.
• A changed signing key. The deployment publishes and checks with its current signing key only. Older receipts and anchors still verify offline against the key you saved. They no longer pass the console or API check.
• The record shows what was reported. A record written by your server or your mobile app holds what your code sent. The channel is sealed with it, so a reader can tell a banner answer from a server call.
• Guardian checks are yours. The record states which method you used. It is not proof that the check was sound.
• Capture methods are reported. The record states the method and reference your system sent. The product does not check the one-time password, the signature, the recording or the document. A record attested only by your staff is marked as such.
• A stated basis is yours. The product seals the basis you state for earlier consent and does not check it.
• Wording is yours. The product does not check that a notice is plain or true.
• Test records are not evidence. They are sealed and anchored like live ones, then deleted 30 days after their last change.
• The audit log is not anchored. Each entry is sealed to the one before it, but there is no daily anchor as there is for consent evidence.

The chain replay, the signatures and the inclusion proofs are covered by unit tests, including tampering cases. That is the extent of the assurance. The product holds no certification, and no independent penetration test has been carried out.

What remains with you#

Questions to settle before you rely on it#

• Who will receive and store the daily anchors, and can the operator reach that store?
• Which identifier will you record consent under, and where is its link to the person kept?
• How long must evidence outlive the consent, and does the operator delete it after that?
• If the operator is replaced, who keeps the public keys and the anchors?
• Does your counsel accept a signed receipt and an anchor as the proof section 6(10) asks for?

The product answers the technical half of these questions. The other half is governance, and it is yours.

Further reading#

• How consent is proven
• Receipts
• Daily anchors
• Verify a receipt
• DPDP readiness