| Internet-Draft | zkpusecases | December 2025 |
| Johansson | Expires 2 July 2026 | [Page] |
Zero Knowledge Proof technology relies on mathematical constructs that enable a sender to prove to a receiver that a piece of information has a certain agreed property without revealing that information or its source to the sender. An example commonly given is the problem of proving that a subject is older than a certain age without revealing the exact age or any other information to a receiver. This document attempts to catalogue real world usecases for such technology.¶
This note is to be removed before publishing as an RFC.¶
The latest revision of this draft can be found at https://leifj.github.io/draft-johansson-zkp-usecases/draft-johansson-zkp-usecases.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-johansson-zkp-usecases/.¶
Source for this draft and an issue tracker can be found at https://github.com/leifj/draft-johansson-zkp-usecases.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 2 July 2026.¶
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
There are several ways to define the concept of zero knowledge proofs. In this document we will rely on the SPICE architecture document to provide us with the basic terminology and use the following definition: A zero knowledge proof (zkp) is a mechanism by which the holder can prove to the verifier that a statement (S) is true without providing the verifier with any additional information other than the truthfulness of S. A zkp mechanism is usually required to satisfy three properties:¶
completeness: if S is true, then a compliant implementation of the mechanism will accept the proof presented by another compliant implementation.¶
soundness: a non-compliant holder can't make a compliant implementation accept that S is true when it is in fact false.¶
zero knowledge: if S is true, then a verifier is not able to derive any other information than the fact that S is true from the mechanism.¶
Zero knowledge mechanisms fulfil many privacy requirements, for instance:¶
verifier-verifier unlinkability¶
issuer-verifier unlinkability (a.k.a. collusion-resistant unlinkability)¶
These properties come at a cost in terms of implementation complexity. Zero knowledge proofs are both different from conventional cryptography and often hard to implement and understand. Additionally, the fact that zkp ensures unlinkability means that some use-cases that depend on linkability may not translate into architectures that rely on zkp without significant adaptation. Merely deploying zkp is not sufficient to ensure that the overall system preserves privacy, as the information required in the proofs (i.e., the S) may in some cases be enough to fully identify the data subject, in which case the deployment of zkp serves little purpose.¶
This document aims to describe some real-world use cases where the deployment of zkp makes sense from a business and technical perspective.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
We also rely on the terminology from the SPICE architecture document ([I-D.draft-ietf-spice-vdcarch-00]).¶
ZKP mechanisms are fundamentally about proving claims about data subjects with no (zero) auxiliary information leakage. However, ZKP isn't the only method for addressing information leakage in the three-party architecture. Using [RFC9901], also known as selective disclosure JSON Web Tokens (SD-JWT), it is possible to achieve many, but not all, common privacy requirements. Specifically, it is not possible to prevent information leakage that results from collusion between the issuer and verifier.¶
In situations where collusion resistance is required and SD-JWTs (and similar solutions) are ineffective, ZKP becomes a clear alternative. However, even in situations where collusion resistance isn't necessary, ZKP is sometimes a convenient alternative to other selective disclosure solutions for operational reasons. For instance, a common way to deploy SD-JWTs is to use so-called batch issuance. In order to achieve verifier-verifier unlinkability, the issuer provides the holder with a set of identical copies (a batch) of a given SD-JWT, each signed with a unique key. Whenever the holder generates a presentation to the verifier, one of the SD-JWTs is "consumed", making them effectively one-time-use.¶
There are situations where the salted hash approach used in SD-JWTs and mdocs [TK:add ISO reference] provides adequate privacy protection. However, in order to achieve verifier-verifier unlinkability, the issuer creates N copies and N signatures each time an SD-JWT is issued. Since this has to be repeated every time the batch "runs dry" at the holder, the issuer has to perform a large and recurring number of signatures. Depending on how the infrastructure is set up, it may be cheaper from an operational point of view to use a ZKP mechanism, where a single credential can be issued and reused by the holder for as long as it remains valid.¶
In some jurisdictions, legal requirements are being established to ensure enhanced privacy protection for the use of online services. Some legal regimes establish requirements that imply that only the minimal set of information required for each transaction must be transmitted. In such situations, it may be useful (but certainly not always required) to consider deploying ZKP technology. Some legal requirements take this further and outright require ZKP technology. One such example is the [eIDAS] regulation. However, even in the case of eIDAS, the development of zkp schemes has effectively led to a "soft" requirement until development and standardization efforts have caught up with legal requirements.¶
Proof of age means the ability to prove that a subject is above or below a required age. Commonly cited use cases include access to mature or age-limited content (e.g., online gambling). Proof of age is also relevant when the subject needs to prove that he or she is below a certain age limit, for instance, when the subject is accessing an online service intended for, and meant to be a safe space for, children.¶
A proof of age can be produced using a so-called range-proof from a credential that contains an authentic date of birth or an authentic age claim for the subject.¶
Proof of human means the ability to prove that a subject is human. This could be achieved by producing a ZKP proof from a credential that is only given to humans. It is often presumed that a passport or similar travel document, or the Personal Identity Document (PID) credentials envisioned by the eIDAS regulation, will only be provided to humans, but it is by no means certain that all countries and organizations that issue recognized ICAO travel documents would only issue them to persons (humans). ICAO guidelines do not explicitly require that only humans are allowed to obtain a passport or an emergency travel document, but the term "person" suggests that this is the intended meaning [tk: reference to ICAO guidelines].¶
The reason proof of human may be interesting follows from the increased use of semi-autonomous agents that sometimes act independently or on loosely formulated instructions (prompts) from a human. It may be useful to distinguish between actions taken by a human and those taken by an agent as a result of a prompt, as well as those taken independently of any human interaction. Such actions are sometimes, but not always, recorded together with identifiable information, and the use of zkp allows the trust in the "human-ness" to be separated from any trust in the agent holding the authorization for the act itself.¶
In the three-party model, a credential is issued to a digital "wallet" under the control of the subject. Cryptographic controls, also known as holder binding, are used to ensure that a given credential is issued to a specific wallet. Cryptographic binding, however, cannot ensure that the subject is the only one able to control the wallet; it is sometimes necessary to verify that a particular subject is in direct control of the wallet device. This is sometimes referred to as liveness checks and is commonly used when issuing credentials based on travel documents, driver's licenses, and other documents that contain biometric data that can be matched with a subject. Liveness checks are carried out in order to ensure (to some degree) that the subject is physically present instead of (say) having their actions emulated by software.¶
A liveness credential is a representation of a recent liveness check, and the use of ZKP enables a verifier to have confidence that a trusted liveness verification has been done without providing any additional information. It would be possible to combine the liveness check with an identity verification in the holder to prove that the same individual holding a particular form of identity document (such as a PID) was recently present and in control of the holder's device.¶
Many relationships can be represented as membership in a group; a subject is a student if they are a member of the group of students (at a particular institution), a subject is Danish if they are a member of the group of Danish citizens, etc. The tautology aside, proof of membership is a common requirement for various purposes, such as discount systems and eligibility for specific business transactions. Examples include discounts for senior citizens and proof of a valid driver's license before renting a trailer, among others. Many of these cases do not require proof of identity beyond the proof of membership and any additional documentation required for the economic transaction.¶
This document does not specify any protocols or interoperability requirements.¶
This document has no IANA actions.¶
Thanks to Peter Altman and Drummond Reed for their contributions to this document.¶