Consent Receipt JSON: Fields, Hashing, Signatures and Withdrawal

A consent receipt is evidence about one recorded event—not proof by itself that consent was legally valid. The receipt should make the event reconstructable: who or what principal reference acted, which Data Fiduciary and channel were involved, which purpose and notice versions applied, what choice was made, when it became effective, what record it superseded, and how the payload’s integrity and issuer can be checked.

Current-status note (29 August 2026): the DPDP Act’s definitions are in force. Substantive consent, notice and withdrawal provisions and most related Digital Personal Data Protection Rules, 2025 are scheduled for the 18-month commencement tranche, around May 2027. Build evidence controls now, but confirm official notifications before treating duties or timelines as operative. The Act does not mandate ISO/IEC TS 27560, a JSON receipt or a particular hashing/signature scheme.

Keep three artefacts distinct. The consent interface is the notice and choice experience. The internal consent record is the authoritative, versioned state used for decisions. A receipt is a portable snapshot of one event that can be shown to a Data Principal or verifier. Hashes and signatures strengthen integrity and provenance; they do not cure a misleading notice, bundled choice or invalid capture flow.

Use the DPDP Act and commenced Rules as the legal source. ISO/IEC 29184, ISO/IEC TS 27560 and the Kantara receipt model can be useful engineering references, but they are optional standards and must not be described as India’s statutory receipt format. Map their fields to your organisation’s actual notice, purpose, withdrawal and evidence policy.

Global privacy standards provide a useful engineering template for that history. ISO/IEC 29184 describes how online privacy notices and consent journeys should be structured and presented, with a focus on the content of notices and the interaction patterns used to obtain consent.^[1]

ISO/IEC TS 27560 goes deeper on the internal data model, defining an interoperable, open, and extensible information structure for consent records and consent receipts, including requirements for lifecycle management of consent states.^[2]

The Kantara Consent Receipt specification adds a concrete JSON-based receipt format targeted at individuals, covering authority, purposes, data categories, and links to notices and policies so that a consent record can be expressed in a human-readable artefact.^[3]

For organisations that also operate under GDPR or follow EDPB consent guidance, there is comfortable overlap with DPDP: both regimes expect you to prove who consented, to what, when, and on the basis of which information. Indian implementations, however, need to reflect concepts such as Data Fiduciary and Data Principal, the role of consent managers, and domestic rules around purpose and storage limitation. Implementations can also look at work such as the PublicSchema ConsentRecord concept, which aligns fields across ISO/IEC TS 27560, the Kantara Consent Receipt, and other vocabularies to show what a detailed, standards-convergent consent schema can look like.^[5]

Use one canonical model across web, mobile, branch, call-centre and partner channels. Store immutable events plus a derived current-state projection. Version the receipt schema, purpose catalogue, notice, consent record and signing key independently so a verifier can reconstruct what existed at event time without applying today’s definitions retroactively.

Headers and metadata describe the consent record itself, not the person. Typical fields include a stable consent_record_id, a schema_version, created_at and last_updated_at timestamps, the source_system and channel (for example, web, Android, branch_kiosk, contact_centre), the environment (production or test), and an optional correlation_id for grouping related events in a single interaction. For DPDP audits, a clear separation between metadata about the record and the actual consent content helps you reason about lifecycle, retention, and migration without touching personal data.

The parties group identifies who is involved in the processing. At minimum this should include a subject_reference that links to your identity layer, a data_fiduciary_identifier (often a legal-entity identifier rather than a trading name), and zero or more data_processor_identifiers for vendors or group entities that perform processing on your behalf. In Indian B2B2C flows, such as diagnostic networks or marketplace models, there may be multiple Data Fiduciaries and processors in a single business flow; your schema should support structured party roles and clear references to underlying processor agreements rather than embedding free-text descriptions.

The processing group captures what is being done with the data. This is where you model purpose codes, data categories, processing operations, legal bases, and retention expectations. Instead of hard-coding text into the consent record, maintain separate catalogues for purposes and data categories with stable identifiers, machine-readable descriptions, and human-readable labels in the major languages you support. Each consent record then stores references, such as purpose_ids, data_category_ids, a legal_basis code indicating consent versus statutory obligation, and parameters such as geographic scope or cross-border transfer flags. That separation makes it easier to update notice wording or add languages without losing the original semantic intent.

Finally, the consent specifics group captures the Data Principal’s choices and how they change over time. Core elements include the consent_status (such as given, refused, withdrawn, expired), a granularity model that links each status to concrete purposes and channels, conditions such as expiry or review dates, references to notice_id and notice_version that were in force when the choice was made, and evidence_references pointing to logs, screen captures, OTP confirmations, or call recordings. This is also where you store a consent_receipt_identifier or signature if you generate receipts for Data Principals. As long as your internal schema can be projected into these four groups, you can build DPDP-ready receipts and logs even if your underlying database tables use different names or structures.

Store identifiers and decision fields needed for enforcement and audit; pseudonymise principal references and keep high-risk evidence behind a separate access-controlled reference. Hash the exact canonical notice and receipt payload to detect alteration. Sign the canonical payload or its digest with a managed private key to authenticate the issuer. Encrypt sensitive stored or transported evidence separately when the threat model requires confidentiality.

Hashing and signing are not interchangeable. A plain SHA-256 digest says only that bytes match a known digest; anyone who alters an unsigned payload can recompute a new hash. A digital signature lets a verifier check that a holder of the private key signed the canonical payload and that it was not changed. Verification still requires a trusted key id, key status, algorithm policy and certificate or key-distribution process.

Canonicalization is mandatory for deterministic hashes. Define JSON Canonicalization Scheme or another documented byte format, Unicode normalization, timestamp format and array ordering. For each notice event store notice_id, notice_version, language, presented_at, content_sha256 and an immutable content reference. For each receipt store payload_sha256, signature_alg, key_id and signature.

Timestamp separate facts separately: notice presented, choice captured, event accepted by the ledger, receipt issued, effective from, expiry if any, withdrawal requested, withdrawal effective and downstream enforcement completed. Use UTC RFC 3339 values and record a trusted clock source or tolerance policy where timing is disputed.

Version and withdraw through new events. A grant receipt has consent_version N. A later correction, renewal or withdrawal creates version N+1 with previous_receipt_id or supersedes_receipt_id and an event_type such as WITHDRAWN. Keep the old receipt immutable, update the current-state projection atomically, and issue a withdrawal receipt that the Data Principal or downstream service can retain.

Minimise evidence. Store pseudonymous subject_ref values, not raw mobile numbers or email addresses, in the portable receipt. Keep OTP logs, recordings, IP addresses or device details in a protected evidence store and reference them by URI and digest. Document retention and access separately; hashing personal data does not automatically make it anonymous.

Validation should: reject unknown schema versions and algorithms; canonicalize the payload; recompute and compare its digest; verify the signature and key validity at issued_at; validate required ids, enum values and timestamps; follow previous/supersedes links; confirm purpose and notice versions; check for duplicate or forked versions; and compare against the authoritative current ledger before authorizing processing.

The early JSON example and field dictionary are illustrative and deliberately explicit. Tailor identifiers, evidence references, algorithms, key management and retention to your system and threat model; do not treat the sample as a regulator-approved schema.

Use an append-only event ledger plus a derived current-state projection. Commands such as grant, refuse, renew and withdraw validate the expected previous version, append one immutable event, update the projection atomically and issue a receipt from the committed event. Event ids and idempotency keys prevent retries from creating duplicate versions.

Grant flow: resolve the principal reference; fetch the active purpose and notice versions from server-side catalogues; capture the Data Principal’s choices; append a GIVEN or REFUSED event; calculate canonical payload and evidence digests; sign the committed receipt; return the receipt id; and publish a versioned event to downstream systems. The UI must not invent purpose or notice versions.

Offline, assisted and guardian flows should call the same service and schema. Record channel, operator or device reference, guardian_ref and guardian authority/verification evidence only when applicable. If connectivity is unavailable, queue a signed capture envelope with a unique idempotency key and distinguish captured_at from accepted_at; do not backdate ledger order silently.

Withdrawal flow: accept a request through an equally accessible channel; authenticate the requester as policy requires; append a WITHDRAWN event at version N+1; issue a signed withdrawal receipt that references the earlier receipt; update the current projection; publish the revocation event; invalidate caches and future refreshes; and record withdrawal_effective_at plus downstream_enforced_at per system. Processing decisions after effective withdrawal should be queryable as exceptions.

Retention applies separately to current state, portable receipts and supporting evidence. An append-only ledger is not permission to retain linked personal data forever. Use explicit retention rules, pseudonymise or tombstone principal links when evidence no longer needs identity, retain cryptographic and version-chain metadata only where justified, and log deletion or archival jobs.

Continuously validate both receipt integrity and consent-state correctness. Parse against the declared schema version, verify canonicalization, digest, signature and key status, confirm a single monotonic version chain, and reconcile portable receipts with the authoritative event and current-state projection.

Run exception queries for: grants without a notice version or presented_at; invalid payload digests or signatures; unknown or revoked key ids; duplicate event ids; forked or skipped consent versions; orphan previous_receipt_id links; withdrawals without a withdrawal receipt; current projections that disagree with the latest event; and downstream ALLOW decisions recorded after withdrawal_effective_at.

Monitor capture and withdrawal API errors, signature failures, event-bus lag, cache age, projection-rebuild drift, receipt-generation latency and time from withdrawal_effective_at to downstream enforcement. Sample complete chains regularly and alert on missing fields rather than waiting for a complaint.

Even with a solid schema and validation matrix, production systems will occasionally surface consent anomalies. Treat these as structured troubleshooting exercises that trace symptoms back to specific breaks in the consent pipeline or record model.

Digital Anumati - Service positions itself as a DPDP-focused consent management and governance platform, externalising many of the consent record and receipt patterns described here. It is built around a central consent ledger, real-time consent tracking, event-driven propagation of consent state, multi-language consent capture, and audit-ready artefacts aligned with India’s Data Fiduciary and Data Principal concepts. In documented healthcare deployments, it has been used to digitise consent capture at the point of care, link consents to specific processor agreements, generate hashed consent receipts alongside clinical outputs, and ensure that withdrawals move data from active systems into encrypted retention stores instead of leaving them in operational flows.^[6]

For technical evaluators deciding whether to build or buy, the key question is which parts of the consent lifecycle you want to own directly and which you are comfortable delegating to a DPDP-native platform. Digital Anumati - Service can provide the consent ledger, receipt generation, and much of the integration scaffolding, while your engineering team focuses on embedding consent checks into business workflows and data pipelines. If you want to benchmark your in-house design against a production-tested DPDP consent architecture, you can review the platform details and technical documentation on the Digital Anumati - Service site.

Once the basic consent record and pipeline are defined, most engineering teams run into a recurring set of edge cases: how far to go in issuing Data Principal-facing receipts, how to structure multi-language notices, what to do about offline and assisted consent capture, how to handle children’s data, and how long to retain the resulting logs. These questions often do not have single right answers, because they depend on your risk appetite and the sectors you operate in, but there are engineering patterns that narrow the options.

The answers that follow focus on the implementation perspective: how to adjust your schema and event flows so that, whatever policy choices your legal and compliance colleagues make, your systems can enforce them consistently and produce defensible evidence if the DPDP Board or a Data Principal asks you to prove what happened.