Abstract
Zero-knowledge proofs (ZKPs) and consent are often portrayed as antagonists: one promises unlinkability, the other demands non-repudiation. In practice, they are complementary. Consent is about binding a decision to a specific event in a specific context, not about doxxing a person forever. ZKPs are about proving the right fact without exposing the rest. When we combine context-bound consent, local verification, and hash-only evidence, we get a system that is private by default yet accountable on demand - with precise auditability and no surveillance creep.
Author’s note: This article reflects work with AesirX and Concordium on privacy-preserving technologies (PETs) for practical regulatory compliance - from consent to ID verification. ‘Consent receipt’ maps conceptually to ISO/IEC 27560 (Consent Record): evidence that a data subject (via a holder key) agreed to a specific policy under a specific context and timestamp - without publishing identity attributes. Predicate proofs are commonly conveyed as W3C Verifiable Credentials or SD-JWT; the model is compatible with either while insisting on local verification and context binding. References to EUDI and mDL are illustrative; the design is wallet-agnostic and vendor-neutral.
TL;DR: Consent proofs should be event-scoped and verified locally. Keep only hash-anchored receipts; open one named event under due process - nothing ambient.
Consent Is an Event, Not an Identity
Most systems confuse the notion of consent with perpetual identification. A privacy-preserving stack treats consent as a decision attached to one concrete interaction, captured as: who controlled the key, what policy was accepted, where the interaction occurred, and when. The “who” is cryptographic control of a holder key. The “what/where/when” are folded into a context that names the relying party, the requested action, the policy in force, and a bounded time window.
This reframing matters. Once consent is event-scoped, the requirement becomes non-repudiation of that event, not lifelong tracking of that person. The subtlety is that non-repudiation attaches to the event and the key, while privacy applies to the person beyond the event.
Proving the Right Thing, Locally
ZKPs shine when the verifier only needs a predicate (e.g., “over 18,” “EU resident,” “same holder as before within this site”). Instead of calling an issuer on every request - or copying raw attributes - the verifier checks a proof locally. There is no routine “phone-home” to the issuer, which eliminates an otherwise constant, correlating exhaust trail.
Local verification moves consent from full disclosure to minimal proof. That is the essence of data minimization and makes the subsequent evidence we keep about consent much smaller and much safer.
Evidence Without Exposure: The Consent Receipt
Non-repudiation doesn’t require identity sprawl; it requires evidence tied to context. The right evidence is a consent (and/or verification) receipt that binds:
- the holder’s key (not their PII),
- the context (relying-party origin scope, action, bounded time window, and policy reference),
- and a timestamp.
The receipt can live off-chain (signed and stored first-party) or be anchored by a hash-only receipt on a ledger. Either way, it proves that this key agreed to this policy under this context at this time - while revealing nothing else. Crucially, receipts are context-scoped, so they don’t create a global identifier or a reusable token.
This aligns with ISO/IEC 27560 Consent Record: evidence of agreement to a specific policy in a specific context, without identity attributes in the record.
“Receipts are context-scoped and hash-only: they prove that a consented, valid event occurred without publishing proofs or personal data.”
Figure 1. AesirX Event-Scoped Consent Pattern (2025) Event-scoped consent with zero-knowledge - Event-scoped consent with zero-knowledge: verify locally, log a first-party receipt, anchor a hash-only, and - under due process - open a single named event via Native or Escrow. No issuer phone-home. No ambient tracing (© AesirX 2025 · aesirx.io).
Operational Unlinkability as a Control Surface
Unlinkability is not a declaration; it’s a discipline. The discipline here is to ensure that each interaction uses fresh, context-derived key material. A private, on-device base is established once; for each event, the device derives a contextual key that depends on:
- the verifier’s normalized origin scope (so “who” you’re interacting with is unambiguous but not over-broad),
- the action (what is being asked),
- and the time window (when it’s valid).
Because the event key is unique to that origin/action/window, the verifier cannot use it to follow the holder elsewhere, and holders cannot be silently correlated across relying parties. At the same time, the verifier gets a stable, short-lived handle (per-event key) to complete the current task and record a verdict + timestamp - nothing more.
Hash-Only Anchors, Never Raw Data
Many systems put too much on a chain - attributes, identifiers, even entire proofs. That is unnecessary and risky. A privacy-preserving design writes only hash-level anchors for auditability:
- a context anchor for the event (a commitment to origin/action/time window and policy),
- and, optionally, a verification receipt that says “a valid check happened here,” again as a small, hash-only record.
These anchors give auditors and courts immutability and ordering without revealing personally identifying information or proofs. They also make it possible to prove existence (“this event happened”) and bind follow-up artifacts (like governed disclosures) to the exact event that was originally agreed.
Due-Process Accountability, Event by Event
The hard question is: what happens if the law later requires us to identify the actor for a specific incident? We answer by making accountability event-scoped and governed, never ambient.
There are two clean lanes:
- Native lane (when the identity provider already has a lawful, auditable map from credential to subject): if a court names a specific event by its context anchor, the provider can open that event only, issue a signed decision receipt, and nothing else leaks.
- Escrow lane (when the provider does not hold a native map): at verification time, a sealed, per-event escrow is created off-chain with just enough origin information to contact the authoritative issuer or reconstruct identity under warrant. The ledger records only a hash of that escrow, bound to the event’s context anchor. Later, a court-named event triggers a threshold, governed decryption of the matching escrow. The hash on the ledger prevents substitution; the quorum prevents unilateral disclosure.
Either lane yields targeted accountability without constructing a shadow identity graph. Routine operation remains silent and unlinkable; only the named event is opened, and only with a formally valid order.
For the Escrow lane, the sealed, per-event escrow contains only what is necessary to contact the authoritative issuer or to reconstruct identity for that event - nothing more - and is retention-bounded by default (e.g., 90 days) unless a legal hold applies. The ledger stores only a hash commitment to prevent substitution.
“Per-event escrow (when used) is minimal and retention-bounded; the ledger holds only a hash commitment that prevents substitution.”
Scenario - Age-gating a social feature
A social platform gates access to 18+ spaces. The page declares the policy; the user’s wallet proves ‘over 18’ locally. The site records a YES decision and anchors a hash-only receipt bound to the context (origin, action, window, policy). Months later, moderation investigates a specific post time: a court names that context anchor, and custodians open that event only under due process. Routine use remained unlinkable; the exception was governed and auditable.
Crossing Domains Without Crossing Privacy Boundaries
Digital life is multi-platform. Relying parties in other systems may want assurance that a particular context was satisfied - without importing identity data. The answer is a short-lived attestation that says “the predicate for this exact context anchor evaluated to yes,” signed by a key whose lifecycle and rotation are visible on a public registry.
Recipients verify the signature, the audience, the expiry, and the binding to the referenced context anchor or receipt. They never receive identity attributes, and they never gain a token that can be replayed across contexts. In short: outcome portability without data portability.
Governance: The Human Layer That Makes It Work
Cryptography enables, but governance legitimizes:
- Context discipline prevents over-broad scopes and keeps receipts meaningful.
- Issuer-silence during routine use removes a primary source of correlation.
- Retention and rotation policies ensure that any per-event escrow, when used, remains minimal, time-bounded, and tamper-evident.
- Decision receipts make due-process actions auditable, linking the human/legal decision to cryptographic evidence.
The model operationalizes necessity and proportionality: routine interactions disclose only the predicate needed to fulfill a purpose, while accountability is reserved for named events. Hash-only anchors provide auditability and ordering without exposing personal data or proofs.
This is where privacy engineering meets compliance. The system is designed so that the legally right thing is also the path of least resistance operationally.
“When lawfully required, only the named event is opened under a governed (due-process) lane using a quorum of custodians; there is no ambient re-identification.”
Threats, Tamed by Design
- Replay & Look-alikes: Single-use, time-bounded contexts tied to a normalized origin scope prevent replays and phishing-by-confusion.
- Silent Correlation: Local verification and context-derived event keys starve trackers; there’s no routine issuer callback and no long-lived handles.
- Evidence Integrity: Hash-only anchors and signed receipts provide tamper-evident trails without exposing payloads.
- Governed Disclosure: Event-scoped, threshold-controlled openings ensure that “exception handling” does not morph into surveillance.
What Good Consent Feels Like
A user visits a relying party that needs an age gate. The page states the policy clearly; the wallet proves the predicate privately on the device; the site logs “yes, at this time, under this policy” - and moves on. No new account, no dossier, no background radiation of issuer pings. Months later, an incident tied to a specific posting time is investigated: the court names the exact context anchor, and the governed lane reveals that event only. The routine remains private; the exception is accountable.
This is the equilibrium the field has sought for a decade: selective disclosure at the moment of use, contextual evidence for consent, and event-scoped accountability when the real world demands it.
Policy Alignment Without Gymnastics
By separating predicate proof from identity exposure, it operationalizes necessity and proportionality. By using context-bound, hash-only receipts, you create stronger evidence than the logs most systems keep today - while holding less personal data. And by structuring accountability as named-event disclosure under governance, you meet legitimate investigative needs without building a surveillance platform.
Conclusion
ZKPs and consent do not cancel each other out; they snap together. The key is to treat consent as event evidence bound to context and key control, and to treat ZK as a way to prove exactly what is necessary - nothing more. With local verification, contextual keys, and hash-only anchoring, privacy becomes the default state. With governed, event-scoped disclosure, accountability remains available when the law requires it. That balance - privacy by default, accountability on demand - isn’t a compromise. It’s how modern cryptography finally makes good on the original promise of the web.
Ronni K. Gothard Christiansen
Technical Privacy Engineer & CEO, AesirX.io
