The limits of zero-knowledge for age-verification

This blogpost describes ongoing academic research from Sofía Celi, Kyle Den Hartog, and Hamed Haddadi at Brave Research.

Age verification is increasingly positioned as a prerequisite for accessing online services, driven by regulatory policies and the expanding scope of content moderation. Zero-knowledge proofs (ZKPs) are often advanced as a technical remedy, promising privacy-preserving attestations of age or eligibility. Yet their deployment in practice exposes both conceptual and practical limits. Credential-based systems anchored in centralized authorities risk exclusion, create new control points, and threaten user privacy. At the same time, many ZKP proposals remain fragile, raising concerns about soundness, composability, and long-term sustainability. Beyond cryptographic guarantees, persistent challenges of content categorization, revocation, and interoperability illustrate that ZKPs alone cannot resolve the broader socio-technical problems of age verification or ID verification.

Here, we examine these limits by highlighting failures in existing systems, unintended consequences of centralized credential frameworks, and risks arising from misapplied proofs. Our aim is not to dismiss ZKPs as a valuable tool, but rather to situate them within a broader architectural context: one that genuinely prioritizes user privacy, autonomy, and the open character of the web.

The setting

Recent proposals from major technology platforms emphasize digitally verifiable credentials, often augmented with ZKPs, as the foundation for, for example, online age checks and access control. These frameworks envision users obtaining cryptographically signed attestations (e.g., of age, residency, or citizenship) from designated issuers, and then presenting them to services to prove eligibility. Similar cryptographic models are also being investigated in academic and industry contexts, particularly within blockchain-based identity systems. In particular, there are proposals for:

• zk-TLS: systems, such as TLSNotary, DiStefano, Janus, Town crier, DECO (and others) which allow a user to commit to a TLS session transcript and later prove facts about their interaction with an unmodified web service (e.g., account balances), enabling the construction of web-based oracles for smart contracts. 

• zk-Authorization: tools like zkLogin and zkCreds, which allow users to prove properties about a JSON Web Tokens (JWTs) from an OAuth or OpenID provider, without revealing the token itself. 

• zk-Compilation: proofs that an executable or bytecode (e.g., ELF, WASM) corresponds to a known source and compiler toolchain, supporting provenance and auditability. 

• zk-Optimization: systems such as Otti allow proving that a private optimization process (e.g., university admissions) was computed according to committed policies and inputs, without revealing the inputs.

• zk-Middleboxes: given a commitment to network protocol streams (e.g., DNS), a sender can prove that traffic satisfies policies without revealing its content.

Despite these advances, credential-based systems (even with ZKPs) remain limited in both theory and deployment. In the following sections, we examine these limitations, focusing on risks of exclusion and centralization, some fragility of current ZKP constructions, and the unresolved socio-technical challenges of categorization, revocation, and interoperability.

The limits

As noted, despite the advances, credential-based systems remain limited in both theory and deployment. Their shortcomings are not confined to implementation details but reflect deeper tensions between cryptographic, security and privacy guarantees, and the socio-technical realities of identity and access control. To understand these challenges, it is useful to distinguish between several categories of limitations:

Security fragility: The use of ZKPs in deployed systems remains fragile. Many protocols described as “zero-knowledge” in the literature fail to meet rigorous formal definitions: they may not actually provide zero-knowledge (and thus fail to preserve privacy), or they may lack soundness (and thus be forgeable). Even when definitions are met, composability guarantees are often absent, raising risks in complex system deployments. More research is needed to ensure that ZKPs used in production achieve their claimed properties, both through rigorously verified security proofs and through formal verification techniques. Implementation is also non-trivial: subtle vulnerabilities have been discovered even in well-audited systems, and optimizations can silently undermine core guarantees if they are not themselves carefully analyzed.

Insufficient privacy guarantees: ZKPs do not guarantee meaningful privacy unless applied carefully and correctly. For example, a proof that a user’s age lies in the range 20–21 may inadvertently disclose that the user is indeed 21. Similarly, the use of broader “tiers” (e.g., 20–25, 25–30, 30–40) may still enable linkage of content to constrained age ranges, undermining the intended privacy guarantees. In practice, even semantically “private” range proofs may leak significant information based on how they are constructed or interpreted.

This in turn creates new risks: when proofs are combined with other contextual signals such as the site where the credential is used, the identity of the credential issuer (e.g., a specific government) or the user’s location, the resulting tuple (credential origin, age range, geographic metadata) can uniquely identify individuals. In practice, this may provide more identifying information than the web currently exposes, enabling pervasive profiling and cross-site correlation under the guise of privacy-preserving verification.

Moreover, privacy loss can compound over time when multiple proofs are issued across a temporal sequence. For instance, a user who first proves their age is between 20 and 22, and then two months later proves they are over 21, has effectively disclosed a narrow interval for their exact date of birth. This temporal leakage highlights the need for systems to manage privacy through change, not just in isolated proofs, but across repeated interactions. Providing users with transparency about the cumulative privacy loss from sequences of attribute-based disclosures, and establishing baseline guarantees of unlinkability across sessions, will be essential to the safe deployment of such systems. 

Furthermore, if not applied with appropriate scoping constraints, ZKP systems can devolve into a form of client-side scanning, where arbitrary attestations are made about the contents of data such as TLS transcripts, JWT tokens, or digital credentials. Such attestations may break the security or privacy guarantees of the underlying protocol or data structure. It must therefore be verifiable, and externally auditable, that the statement being proved does not enable indirect deanonymization or policy circumvention.

Centralization and inclusion risks: Many digital credential systems depend on a small set of recognized issuers, such as governments, telecom providers, or identity verification companies. Government-issued credentials (e.g., driver’s licenses, identity cards, passports) are often considered “high assurance” and come with built-in revocation mechanisms. However, these revocation features can introduce a “phone home” problem: every time a credential is verified, the issuer may be contacted, allowing them to track where and how often the credential is being used. Even if a relying party is free to trust any issuer, in practice they usually only accept a narrow set of “high assurance” credentials. This gives one or two issuers visibility into, and metadata about, every credential presentation. For example, if a site requests a fresh credential at every visit, even without storing it, the issuer may still learn how often the user returns through the verification checks.

Exclusion is another major concern. If a relying party only accepts a limited set of credentials, such as formal IDs, residence permits, or institutional affiliations, people without them are locked out of services. Today, an estimated 850 million people worldwide lack formal identification. In such systems, reliance on a small pool of high-assurance credentials risks reinforcing the digital divide. Moreover, if access to services or publishing rights online depends on the real-time validity of a credential, a handful of issuers effectively gain gatekeeping power. Revocation could occur for benign reasons (e.g., an unpaid fine leading to a suspended driver’s license) or for more concerning ones (e.g., censorship, where an issuer disagrees with the credential holder’s published content). Current regulations mandating digital credential use often fail to address these centralization and exclusion risks. Without safeguards, credential issuers could become powerful control points over who can participate in key aspects of the digital ecosystem.

Parsing and semantic mismatch: A central, and often overlooked, limitation of current ZKP-based systems is the semantic gap between low-level data (e.g., raw byte streams) and the structured data over which the proof is supposed to operate. Most systems implicitly assume that inputs are already well-formed, for instance, that a JSON object respects its grammar or that a credential conforms to a standard syntax.

Without formal guarantees of correct parsing, however, this assumption can be exploited. Malformed or adversarially crafted inputs may be interpreted differently by the prover and the verifier, undermining soundness. For example, if a system assumes that JSON keys cannot contain escape characters, an attacker who violates this assumption may break the proof system’s security.

Some approaches attempt to mitigate this by revealing portions of the data for direct inspection. But this weakens the privacy guarantees that ZKPs are meant to provide. The challenge goes beyond checking whether a value (e.g., an age) appears in the data: it must also ensure that the data conforms to a grammar (is valid JSON, for instance) and that the value is located in the correct position within the document structure. A sound proof must establish, for example, that the age value is indeed bound to a top-level “age” field, and not hidden in a nested field or introduced through structural ambiguity.

Additional ecosystem limitations. Several further challenges exist:

1. Lack of protocol standardization: no widely adopted ZKP protocol stack exists across jurisdictions or vendors, hampering interoperability.
2. Interoperability concerns: even compatible schemes vary in encoding, supported predicates, and proof formats, fragmenting the ecosystem. 
3. Revocation challenges: privacy-preserving revocation mechanisms are underdeveloped and hard to integrate with unlinkability guarantees. 
4. Trust ambiguity: even with ZKPs, the verifier must know whether to trust the issuer, reintroducing central trust dependencies. 
5. Poor user experience: asking users to configure selective disclosure or predicate proofs creates cognitive and UX burdens.

The above concerns are not meant to dismiss the value of zero-knowledge proofs, which remain a powerful and essential tool in privacy-preserving system design. Rather, they highlight the risks of deploying ZKPs “out-of-the-box,” without rigorous formal verification, comprehensive security analysis, user-centered interface design, and thoughtful integration into the broader system architecture and society.

An idea

Beyond the technical limitations above, there is real potential in giving people more control and visibility over how a zero-knowledge proof (ZKP) is created. Instead of a system silently generating a proof in the background, users could be allowed to see, and even adjust, the statement that is being proved.

For example, rather than passively approving “show my age” from a digital ID, a user could check exactly what is being revealed and confirm or edit it before the proof is made. More advanced systems could let the user decide which specific data fields get included. If any changes are made, the system can generate an additional proof showing that the modified data still matches the original information in a way that preserves the intended meaning.

In practice, this means that if a credential says someone is 27, the user could choose to reveal only that they are “over 25.” The system then proves, without revealing the actual number, that this claim is consistent with the real data.

This model promotes both privacy and user autonomy. People gain a clearer view of what is being proved, and they can filter or sanitize information before it is shared. Trust in the process can also be strengthened by relying on independent tools, verified software, or third-party checks to ensure the transformations are done correctly.

In short…

Zero-knowledge proofs offer an important step toward privacy-preserving digital identity and age verification, but they are far from a silver bullet. As our analysis shows, current proposals face persistent limitations: fragility of cryptographic definitions and implementations, insufficient privacy guarantees in practice, risks of exclusion and centralization in credential frameworks, semantic ambiguities in parsing, and unresolved challenges of interoperability, revocation, and usability.

These limitations underscore that ZKPs cannot simply be “dropped in” to solve the socio-technical problems of online trust and access control. Instead, they must be embedded in broader architectures that explicitly safeguard user autonomy, minimize central points of control, and account for the lived realities of exclusion, censorship, and profiling. Achieving this will require not only advances in cryptographic research, but also careful systems design, inclusive policy frameworks, and transparent user interfaces.

In short, ZKPs should be seen not as a complete solution, but as one component within a larger ecosystem of privacy-preserving technologies. Only when combined with rigorous verification, accountable governance, and meaningful user control can they deliver on their promise to strengthen trust online without sacrificing the openness of the web.