ISO/IEC 27565:2026
(Main)Information security, cybersecurity and privacy protection — Guidelines on privacy preservation based on zero-knowledge proofs
Information security, cybersecurity and privacy protection — Guidelines on privacy preservation based on zero-knowledge proofs
This document provides guidelines on using zero-knowledge proofs (ZKP) to improve privacy by reducing the risks associated with the sharing or transmission of personal data between organizations and users by minimizing unnecessary information disclosure. It includes several ZKP functional requirements relevant to a range of different business use cases, then describes how different ZKP models can be used to meet those functional requirements securely.
Sécurité de l'information, cybersécurité et protection de la vie privée — Lignes directrices relatives à la préservation de la vie privée basée sur des preuves à divulgation nulle de connaissance
General Information
- Status
- Published
- Publication Date
- 09-Feb-2026
- Current Stage
- 6060 - International Standard published
- Start Date
- 10-Feb-2026
- Due Date
- 03-Dec-2025
- Completion Date
- 10-Feb-2026
Overview
ISO/IEC FDIS 27565:2025 - "Information security, cybersecurity and privacy protection - Guidelines on privacy preservation based on zero-knowledge proofs" provides practical guidance on using zero-knowledge proofs (ZKP) to minimize personal data exposure when attributes or credentials are shared. The standard explains how different ZKP models and architectures can meet privacy and security objectives across business and technical use cases, reducing risk from data transmission and storage while supporting selective disclosure.
Key topics and technical requirements
- Introduction to ZKPs: descriptions of interactive vs non‑interactive ZKPs, system components (setup, prover, verifier) and core characteristics.
- ZKP performance considerations: guidance on efficiency, latency and scalability relevant to deployments.
- Attribute verification: design considerations for attribute providers, replay-attack protections, collusion prevention and binding to authoritative documents or trusted authorities.
- Use-case-driven functional requirements: ZKP functional requirements that support collection limitation, data minimization, selective disclosure, purpose legitimacy, anonymity of issuers, non-disclosure of verifier identities, retention limits, accuracy, transparency and accountability.
- Privacy and security controls: privacy risk assessment, unlinkability, information security measures and selection criteria for ZKP models.
- Functional and business examples: specific examples including age verification, fraud prevention, auctions, disability proof, distributed ledger technologies/blockchains and central bank digital currencies (CBDC).
- Informative annexes: practical examples such as consistency checks, selective-disclosure implementations, secure numeric comparisons and implementing digital credentials with ZKP.
Applications and practical value
- Enables implementations that prove attributes (e.g., "over 18", "owns an asset") without revealing underlying personal data.
- Supports privacy-preserving digital credentials and identity systems used by banks, government services, healthcare, gaming/age-gated services and CBDC pilots.
- Helps architects and developers choose appropriate ZKP models and design controls for real-world constraints (performance, threat models, user experience).
- Provides privacy officers and compliance teams with functional requirements to align ZKP deployments with data minimization and accountability principles.
Who should use this standard
- Security architects and cryptographic engineers designing identity and credential systems.
- Privacy officers and data protection teams evaluating technical controls for reduced data exposure.
- Solution providers building blockchain, CBDC, or digital credential platforms.
- Regulators and auditors assessing privacy-preserving authentication and attribute verification.
Related standards
- Published under ISO/IEC JTC 1/SC 27 (information security, cybersecurity and privacy protection). Refer to other JTC 1/SC 27 documents for complementary guidance on information security and privacy management.
Keywords: ISO/IEC 27565, zero-knowledge proofs, ZKP, privacy preservation, data minimization, selective disclosure, attribute verification, digital credentials, blockchain, CBDC.
ISO/IEC 27565:2026 - Information security, cybersecurity and privacy protection — Guidelines on privacy preservation based on zero-knowledge proofs Released:2/10/2026
ISO/IEC FDIS 27565 - Information security, cybersecurity and privacy protection — Guidelines on privacy preservation based on zero-knowledge proofs Released:21. 10. 2025
REDLINE ISO/IEC FDIS 27565 - Information security, cybersecurity and privacy protection — Guidelines on privacy preservation based on zero-knowledge proofs Released:21. 10. 2025
Get Certified
Connect with accredited certification bodies for this standard

BSI Group
BSI (British Standards Institution) is the business standards company that helps organizations make excellence a habit.

Bureau Veritas
Bureau Veritas is a world leader in laboratory testing, inspection and certification services.

DNV
DNV is an independent assurance and risk management provider.
Sponsored listings
Frequently Asked Questions
ISO/IEC 27565:2026 is a standard published by the International Organization for Standardization (ISO). Its full title is "Information security, cybersecurity and privacy protection — Guidelines on privacy preservation based on zero-knowledge proofs". This standard covers: This document provides guidelines on using zero-knowledge proofs (ZKP) to improve privacy by reducing the risks associated with the sharing or transmission of personal data between organizations and users by minimizing unnecessary information disclosure. It includes several ZKP functional requirements relevant to a range of different business use cases, then describes how different ZKP models can be used to meet those functional requirements securely.
This document provides guidelines on using zero-knowledge proofs (ZKP) to improve privacy by reducing the risks associated with the sharing or transmission of personal data between organizations and users by minimizing unnecessary information disclosure. It includes several ZKP functional requirements relevant to a range of different business use cases, then describes how different ZKP models can be used to meet those functional requirements securely.
ISO/IEC 27565:2026 is classified under the following ICS (International Classification for Standards) categories: 35.030 - IT Security. The ICS classification helps identify the subject area and facilitates finding related standards.
ISO/IEC 27565:2026 is available in PDF format for immediate download after purchase. The document can be added to your cart and obtained through the secure checkout process. Digital delivery ensures instant access to the complete standard document.
Standards Content (Sample)
International
Standard
ISO/IEC 27565
First edition
Information security, cybersecurity
2026-02
and privacy protection —
Guidelines on privacy preservation
based on zero-knowledge proofs
Sécurité de l'information, cybersécurité et protection de la vie
privée — Lignes directrices relatives à la préservation de la vie
privée basée sur des preuves à divulgation nulle de connaissance
Reference number
© ISO/IEC 2026
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on
the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address below
or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: +41 22 749 01 11
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
© ISO/IEC 2026 – All rights reserved
ii
Contents Page
Foreword .v
Introduction .vi
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Abbreviated terms . 4
5 Introduction to zero-knowledge proofs . . 4
5.1 General .4
5.2 Interactive and Non-interactive ZKP .5
5.2.1 General .5
5.2.2 Interactive zero-knowledge proofs .5
5.2.3 Non-interactive zero-knowledge proofs .6
5.3 Components of a ZKP system.7
5.3.1 General .7
5.3.2 Setup module .7
5.3.3 Prover module .9
5.3.4 Verifier module .9
5.4 Characteristics of ZKPs .10
5.5 ZKP performance .11
6 Considerations of implementing ZKPs for attribute verification .11
6.1 Attribute providers .11
6.2 Replay attack detection or protection .11
6.3 Prevention of collusions between users . 12
6.4 Use of an authoritative document or of a trusted authority . 12
7 Use cases of ZKPs .12
7.1 Proving some properties of a hidden attribute . 12
7.2 Proving the contents in an authoritative document . 13
7.3 Proving the contents across several authoritative documents .14
7.4 Selective disclosure of attributes.14
7.4.1 General .14
7.4.2 Pre-generation of digital credentials .14
7.4.3 On-demand generation of digital credentials . 15
8 Privacy preservation using zero-knowledge proofs .15
8.1 Privacy principles in the context of ZKP . 15
8.2 Privacy risk assessment . 15
8.3 Privacy functional requirements for ZKP .16
8.3.1 General .16
8.3.2 Collection limitation . .16
8.3.3 Data minimization .16
8.3.4 Options and choice .17
8.3.5 Selective disclosure .17
8.3.6 Purpose legitimacy and specification .17
8.3.7 Anonymity of the authority that has issued the attestation .17
8.3.8 Non-disclosure of the identity of the verifiers to the attribute issuer .17
8.3.9 Use, retention and disclosure limitation .17
8.3.10 Accuracy and quality .17
8.3.11 Openness, transparency and notice .17
8.3.12 Individual participation and access .17
8.3.13 Accountability .17
8.3.14 Information security . . .18
8.3.15 Unlinkability .18
8.4 Security considerations .18
© ISO/IEC 2026 – All rights reserved
iii
9 Functional use cases .18
9.1 Functional use examples .18
9.2 Selection of ZKP models .19
10 Business use examples .20
10.1 Age verification . 20
10.2 Fraud prevention . 20
10.3 Auction . 20
10.4 Disability proof . 20
10.5 Distributed ledger technologies and blockchains .21
10.6 Central bank digital currencies .21
Annex A (informative) Factors facilitating or hindering ZKP developments .22
Annex B (informative) Subject binding .23
Annex C (informative) Example of a consistency check between two documents .24
Annex D (informative) Example of ZKP for selective disclosure .26
Annex E (informative) Examples of selective disclosure without using ZKPs .28
Annex F (informative) Example of secure comparison of two numbers .29
Annex G (informative) Implementing digital credentials with ZKP .31
Bibliography .36
© ISO/IEC 2026 – All rights reserved
iv
Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that are
members of ISO or IEC participate in the development of International Standards through technical
committees established by the respective organization to deal with particular fields of technical activity.
ISO and IEC technical committees collaborate in fields of mutual interest. Other international organizations,
governmental and non-governmental, in liaison with ISO and IEC, also take part in the work.
The procedures used to develop this document and those intended for its further maintenance are described
in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the different types
of document should be noted. This document was drafted in accordance with the editorial rules of the ISO/
IEC Directives, Part 2 (see www.iso.org/directives or www.iec.ch/members_experts/refdocs).
ISO and IEC draw attention to the possibility that the implementation of this document may involve the
use of (a) patent(s). ISO and IEC take no position concerning the evidence, validity or applicability of any
claimed patent rights in respect thereof. As of the date of publication of this document, ISO and IEC had not
received notice of (a) patent(s) which may be required to implement this document. However, implementers
are cautioned that this may not represent the latest information, which may be obtained from the patent
database available at www.iso.org/patents and https://patents.iec.ch. ISO and IEC shall not be held
responsible for identifying any or all such patent rights.
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and expressions
related to conformity assessment, as well as information about ISO's adherence to the World Trade
Organization (WTO) principles in the Technical Barriers to Trade (TBT) see www.iso.org/iso/foreword.html.
In the IEC, see www.iec.ch/understanding-standards.
This document was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology,
Subcommittee SC 27, Information security, cybersecurity and privacy protection.
Any feedback or questions on this document should be directed to the user’s national standards
body. A complete listing of these bodies can be found at www.iso.org/members.html and
www.iec.ch/national-committees.
© ISO/IEC 2026 – All rights reserved
v
Introduction
The world is witnessing unprecedented data-driven innovation and growth in digital technologies that
include use of big data, AI and blockchain. These technologies are providing societal and economic benefits,
as well as improving efficiency, user experience and convenience. At the same time, there is a corresponding
increase in privacy risks that requires stronger privacy preserving measures to minimize such risks when
designing and implementing solutions. Legislators are introducing new data privacy laws and regulations,
and strengthening existing ones, to make organizations accountable and compliant with data privacy
protection requirements. They also require support for investigation and regulatory enforcement, where
privacy protections are being misused to harm society.
A number of new technologies enable organizations to operate and do business in new ways that are
compliant with many regulations, while still protecting privacy. These privacy-enhancing technologies
(PETs) apply data protection principles intended to minimize the exposure and use of personal data.
Zero-knowledge proof (ZKP) technology is one such PET, which preserves privacy by eliminating the need
to expose or share personal information and personally identifying information (PII), while achieving its
desired function. ZKP is a privacy-enhancing technology that can be used to adhere to the principles of
collection limitation, user consent and choice and disclosure limitation as mentioned in ISO/IEC 29100.
ZKP allows the validation of data held by an authoritative or an authentic source if it is known to both
the prover and the verifier. This results in greater compliance with the data minimization principle of
ISO/IEC 29100, since only necessary data are disclosed.
This document begins with an explanation of ZKP and its features. It then describes the privacy and
functional requirements that ZKP can address and provides guidelines for using ZKP in a way that is most
useful for privacy practitioners.
© ISO/IEC 2026 – All rights reserved
vi
International Standard ISO/IEC 27565:2026(en)
Information security, cybersecurity and privacy protection —
Guidelines on privacy preservation based on zero-knowledge
proofs
1 Scope
This document provides guidelines on using zero-knowledge proofs (ZKP) to improve privacy by reducing
the risks associated with the sharing or transmission of personal data between organizations and users by
minimizing unnecessary information disclosure. It includes several ZKP functional requirements relevant to
a range of different business use cases, then describes how different ZKP models can be used to meet those
functional requirements securely.
2 Normative references
There are no normative references in this document.
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
ISO and IEC maintain terminology databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https:// www .iso .org/ obp
— IEC Electropedia: available at https:// www .electropedia .org/
3.1
application
software component that issues commands and receives responses to the commands within a system
[SOURCE: ISO/IEC 15961-1:2021, 3.1.1]
3.2
application attestation
confirmation to a server that it is communicating with an instance of its genuine application (3.1) that has
specific characteristics and is running in a trusted environment
3.3
attribute
characteristic or property of an entity
EXAMPLE An entity type, address information, telephone number, a privilege, a MAC address, a domain name are
possible attributes.
[SOURCE: ISO/IEC 24760-1:2025, 3.1.3]
3.4
attribute provider
authority trusted by one or more users and one or more relying parties to issue or verify attributes (3.3)
related to an entity
[SOURCE: ISO/IEC 27551:2021, 3.2]
© ISO/IEC 2026 – All rights reserved
3.5
authoritative document
document known to be reliable because its authority or authenticity is widely recognized or it bears a
signature or seal attesting its validity
3.6
completeness
property where a trusted verifier can be convinced by a trusted prover that a statement is true with
overwhelming probability
3.7
computed attribute
attribute (3.3) that is computed from one or more attributes and public information
3.8
digital credential
set of identity attributes and associated data about an individual, cryptographically signed in advance by a
credential issuer which includes key information that allows to demonstrate the possession of it
3.9
digital credential issuer
authoritative source that registers subscribers and subsequently issues digital credentials to its subscribers
3.10
digital wallet
application (3.1) that stores and manages digital credentials and keys and can use them upon request
3.11
domain
environment where an entity can use a set of attributes (3.3) for identification and other purposes
[SOURCE: ISO/IEC 24760-1:2025, 3.2.3, modified — notes to entry and example have been removed.]
3.12
distinguishing identifier
information which unambiguously distinguishes an entity within a given context
[SOURCE: ISO/IEC 11770-7:2021, 3.5, modified —“within a given context” has been added.]
3.13
identifying attribute
attribute (3.2) that contributes to uniquely identifying a subject within a context
[SOURCE: ISO/IEC TS 29003:2018, 3.8]
3.14
linkability
property for a dataset that it is possible to associate (by linking) a record concerning a data principal with a
record concerning the same data principal in a separate dataset
[SOURCE: ISO/IEC 20889:2018, 3.20]
3.15
online
normal state of the data link layer where both application and network management communication are
possible
[SOURCE: ISO 17356-1:2005, 2.80]
© ISO/IEC 2026 – All rights reserved
3.16
personal data
information relating to an identified or identifiable natural person
[SOURCE: ISO 17573-2:2025, 3.142]
3.17
proof verification
process where a verifier checks that a proof is valid
Note 1 to entry: Checks can include the cryptography and digital signature.
3.18
prover
entity that presents a proof to a verifier
Note 1 to entry: The prover may be an authoritative source or a trusted intermediary.
3.19
public coin interactive zero-knowledge proof
public coin interactive ZKP
interactive zero-knowledge proof (ZKP) (3.26) where the verifier’s messages are uniformly random and
independent of the prover’s messages
3.20
record
set of attributes concerning a single data principal
3.21
soundness
property where a malicious prover, if the statement is false, has only a negligible chance in convincing a
verifier that the statement is true
3.22
subject binding
property that assures that a claim is associated with the correct natural person
3.23
trusted execution environment
TEE
aspect of the mobile device comprising either hardware or software, or both, which provides security
services to the mobile device computing environment, protects data against general software attacks and
isolates hardware and software security resources from the operating system
[SOURCE: ISO 12812-1:2017, 3.60]
3.24
unlinkability
property that ensures that an individual may make multiple uses of resources or services without others
being able to link these uses together
Note 1 to entry: There is a distinction between the following two cases: (i) multiple uses of the same services, and (ii)
the uses of multiple different services.
[SOURCE: ISO/IEC TR 27550:2019, 3.25, modified — note 1 to entry has been added.]
3.25
verifier
entity relying on a verified proof to prove that a statement is true
Note 1 to entry: The verifier is often the relying party seeking proof that a claimed attribute or statement made by an
individual is true.
© ISO/IEC 2026 – All rights reserved
3.26
zero-knowledge proof
ZKP
method involving one or more exchanges between a prover and a verifier where the prover is able to
convince the verifier that a statement is true, without revealing to the verifier any additional information
beyond that knowledge
3.27
zero-knowledge proof functional requirement
ZKP functional requirement
functional requirements of a system to be fulfilled using zero-knowledge proof (ZKP) (3.26)
4 Abbreviated terms
anti-money laundering AML
central bank digital currency CBDC
certification revocation list CRL
common reference string CRS
counter terrorist financing CTF
distributed ledger technology DLT
multi-party computation MPC
national institute of standards and technology NIST
non-interactive zero-knowledge proof NIZKP
online certificate status protocol OCSP
personally identifiable information PII
public key certificate PKC
trusted third party TTP
5 Introduction to zero-knowledge proofs
5.1 General
In the digital world, not collecting or exposing personal information is the best possible way to preserve the
privacy of an individual. However, this is not always practically possible due to the need to use or validate
personal information for various business and legal purposes during the course of a business process or
the provision of a public service. For instance, it can be necessary for individuals to validate a claimed
bank statement to determine eligibility for a loan; or to verify the age of a visitor to a nightclub to ensure
compliance to legal requirements.
Sometimes, it is possible to avoid the overcollection of personal information using ZKP techniques since
the knowledge of some property about it can be sufficient. Instead of oversharing confidential personal
information to satisfy a factual criterion, it is possible to use ZKP to convince the verifier that a certain
statement or a set of statements is true. During the proof, only very limited personal information is
revealed to the verifier, thereby eliminating the potential harm that can be caused by exposing the personal
information.
© ISO/IEC 2026 – All rights reserved
When making a PII-based decision, personal information (attributes) should be associated with the correct
subject. Using ZKPs, the prover can prove that the relevant attributes satisfy certain criteria and those
attributes are associated with the correct subject in a privacy-preserving manner.
ZKP is an important privacy-enhancing tool based on cryptography. Every ZKP system involves at least a
prover and a verifier. A ZKP system is a protocol specification for how a prover and verifier(s) can interact
so that the prover can convince the verifier(s) that a given statement or a set of statements is true. ZKPs
were initially developed by the academic community in the 1980s and have seen tremendous improvements
since then. They are now of practical feasibility in multiple domains of interest across different industries
and to a large community of developers and researchers. ZKPs can have a positive impact in industries and
agencies, and for personal use, by allowing privacy-preserving applications, where permitted, to learn some
properties or characteristics of or about private data, despite not disclosing their values.
A ZKP makes it possible to prove that a statement or a set of statements is true while preserving confidentiality
of secret information. This makes sense when the veracity of the statement or a set of statements is not
obvious on its own, but the prover knows relevant secret information that enables a proof to be made.
A ZKP protocol usually supports the following three properties:
a) completeness: if the prover's statement is true, then the verifier accepts it with overwhelming
probability;
b) soundness: if the prover's statement is false, then no matter how the prover behaves, the verifier rejects
it with overwhelming probability;
c) zero-knowledge: if the statement is true, no verifier learns any information other than the fact that the
statement is true.
In addition to the three well-known properties applicable to ZKP protocols, a non-interactive zero-knowledge
proof (NIZKP) protocol usually supports the following two additional properties:
d) replay detection/protection against the same verifier: If a user saves a previously sent NIZKP exchange
and replays it to the same verifier, that verifier rejects it with high probability.
This can be resolved by including a challenge sent by the verifier or a date and time in the ZKP.
e) replay detection/protection against a different verifier: If a user saves a previously sent NIZKP exchange
and replays it to a different verifier, that verifier rejects it with high probability.
This can be resolved by including an identifier of the designated verifier in the ZKP.
5.2 Interactive and Non-interactive ZKP
5.2.1 General
ZKP can be divided into two categories:
a) interactive ZKP;
b) non-interactive ZKP.
An interactive ZKP requires several rounds of interaction between the prover and the verifier before a
decision can be made. Whereas, for a non-interactive ZKP, the prover can just send one-message proof to the
verifier. In practice, it is possible that the verifier was not online when the proof was produced.
5.2.2 Interactive zero-knowledge proofs
To establish such proofs, both the verifier and the prover should be online at same time. In order to prove the
same statement again to another verifier, the prover should interact with another verifier again.
© ISO/IEC 2026 – All rights reserved
During an interactive ZKP protocol, three or more messages are exchanged between the prover and the
verifier. If the verifier’s messages are uniformly random and independent of the prover’s messages, this ZKP
is a public coin protocol.
A special type of public coin interactive ZKP is the Sigma protocol, which involves the exchange of three
values:
1) During the commitment phase, a first message is sent from the prover to the verifier that contains an
element a ,
2) During the challenge phase, a second message (fresh random value) is sent from the verifier to the
prover that contains a challenge c , and
3) During the response phase, a final message z is computed by the prover and sent from the prover to the
verifier.
At the end of the interaction, the verifier makes a decision whether a statement x is true or false based on
the values of ac,,z .
In general, more than three messages can be exchanged during the ZKP. Some ZKP requires multiple rounds
to achieve a satisfying soundness probability.
NOTE For some systems, before the exchanges can take place, it can be necessary for some parameters, (both
public and private) to be securely distributed to the prover and the verifier.
5.2.3 Non-interactive zero-knowledge proofs
5.2.3.1 General
When the ZKP is non-interactive, the interaction between the prover and the verifier to build the proof
consists of a single message sent by the prover to the verifier.
Public-coin interactive ZKP protocols can be transformed to non-interactive ZKP by replacing the verifier's
challenge message(s) by pseudorandom values. There are various ways to generate these messages; three
different approaches are specified in 5.2.3.2 to 5.2.3.4.
5.2.3.2 Using a cryptographic hash function to simulate the behaviour of the verifier
A cryptographic hash function can be used to simulate the public coin challenge message sent by the verifier.
This technique is known as the Fiat–Shamir heuristic. For example, consider a Sigma protocol where the
prover wants to convince the verifier a statement x is true. The prover generates the first message, a . Then,
it hashes cH xa, and computes the correct response, z for the challenge c . It then sends az, as
proof. To validate the proof, the verifier executes the hash function on xa, to calculate c and verifies that
ac,, z is a valid Sigma protocol transcript. In this way, the challenge is not freely chosen by the prover,
and it is unpredictable until the first message, a , is determined. Such technique has been generalized by
using a common random string that is no more defined for producing a single proof but to produce an
unlimited number of proofs. See 5.2.3.4.
See ISO/IEC 10118-1, ISO/IEC 10118-2, ISO/IEC 10118-3, and ISO/IEC 10118-4 for more details on
cryptographic hash function.
5.2.3.3 Using trusted public source of random values to simulate the behaviour of the verifier
The goal is to use public random sources which are periodically renewed and where it can be verified that
they were not created before a specific time. This characteristic can be met by using a public utility that
provides trusted random values that can be used to simulate the public coin challenge messages that are
normally generated and sent by the verifier. For example, such public utilities are available in the form of
public beacons from the United States of America, Brazil and Chile.
© ISO/IEC 2026 – All rights reserved
5.2.3.4 Using a structured Common Reference String
The Common Reference String (CRS) can be used to embed the challenges that the prover should answer
during the generation of the proof. The manner of the embedding is such, that the prover does not learn the
challenge, but the verifier is able to check that the response is correct.
Depending on the protocol, such CRS may be generated by the verifier (in which case we have the designated
verifier setup), or it should be generated by a trusted source.
5.3 Components of a ZKP system
5.3.1 General
All ZKP systems have two fundamental components (also known as modules):
a) prover module; and
b) verifier module.
Some ZKP systems additionally require a trusted setup module.
5.3.2 Setup module
The setup module takes some specification as input, and it outputs a CRS. The CRS may include system
parameters, such as the group specification and common reference elements.
Figure 1 depicts three suggested deployment scenarios for the trusted setup module, where S1, S2 and S3
are three servers.
1) Scenario one: The setup module is executed by a single trusted and auditable entity. This entity should
erase its memory after the execution to prevent potential leakage of secret information that can be used
to violate the security guarantees.
2) Scenario two: The setup module is executed inside a trusted execution environment (TEE) of an
untrusted entity. After the execution, the TEE would output the reference strings and erase all the
internal state.
3) Scenario three: The setup module is executed in a collaboration of multiple entities using a secure
multiparty computation (MPC) protocol, where privacy and correctness are ensured even when a
certain proportion of entities are malicious. No information leaves any of the entities.
NOTE 1 See ISO/IEC 4922-1 and ISO/IEC 4922-2 for more details on MPC.
© ISO/IEC 2026 – All rights reserved
Key
S1 server 1
S2 server 2
S3 server 3
Figure 1 — Setup module
There are several variations of the setup and the level of trust placed in it, including the following:
NOTE 2 See ISO/IEC 9798-5 for more details.
a) No setup or trustless setup: This is when no trust is needed, for example because the setup is just a copy
of a security parameter, or because everyone can directly verify the setup.
b) Uniform random string: All parties have access to a uniform random string (URS) from a trusted
common source of randomness e.g. sunspot activity.
c) Common reference string: The URS model is a special case of the CRS model. However, in the CRS model,
it is also possible that the common setup is sampled with a non-uniform distribution, which can exclude
easy access to a trusted common source. A distinction can be made as to whether the CRS has a verifiable
structure, i.e. it is easy to verify that the CRS is well-formed.
d) Designated verifier setup: A setup, where the verifier receives some extra private information (in
addition to the public CRS received by all parties) so that it can verify the proof. This depends on the
setup algorithm being trusted.
e) Random oracle model: The common setup describes a cryptographic hash function, e.g. SHA256 (see
ISO/IEC 10118-3 for more details). In the random oracle model, the hash function is heuristically
assumed to act like a random oracle that returns a random value whenever it is queried on an input not
seen before. There are theoretical examples where the random oracle model fails, exploiting the fact
that in real life the hash function is a deterministic function, but in practice the heuristic gives good
efficiency and currently no weaknesses are known in practice.
f) Updatable CRS: In some ZKP systems, the CRS can be updated after its initial setup. Updating a CRS
nullifies the trapdoor associated with the old CRS, which makes the system more trustworthy.
© ISO/IEC 2026 – All rights reserved
NOTE 3 Auditors can be either authorities or any renowned trusted third party.
5.3.3 Prover module
The prover module takes the statement and the witness as input. It may also optionally take the common
reference string (CRS) generated by the setup module as extra input. It interacts with the verifier module
according to the ZKP protocol description, aiming to convince the verifier that the statement is true.
The prover module can be executed by a single entity or among multiple entities. Figure 2 depicts two
suggested deployment scenarios for the prover module, where P1, P2, and P3 are three provers.
1) Scenario one: The prover module is executed by a single entity. It takes the prover reference string,
relevant public information, private information as input, and it interacts with the verifier module via
some medium.
2) Scenario two: The prover module is executed among multiple entities forming MPC. The prover reference
string, relevant public information and private information can be input to those entities either in the
clear form or in the protected form, such as secret sharing.
NOTE See ISO/IEC 4922-1 and ISO/IEC 4922-2 for more details on MPC.
Key
P1 prover 1
P2 prover 2
P3 prover 3
Figure 2 — Prover module
5.3.4 Verifier module
The verifier module takes the statement as input. It may also optionally take the CRS generated by the setup
module as extra input. It interacts with the prover module according to the ZKP protocol description and
outputs a decision on whether it accepts the proof at the end of the interaction.
The verifier module can be executed by a single entity or among multiple entities. Figure 3 depicts two
suggested deployment scenarios for the verifier module, where V1, V2, and V3 are three verifiers.
1) Scenario one: The verifier module is executed by a single entity. It takes the verifier reference string and
relevant public information as inputs, and it interacts with the prover module via some medium.
© ISO/IEC 2026 – All rights reserved
2) Scenario two: The verifier module is executed among multiple entities forming MPC. The verifier
reference string and relevant public information may be input into those entities either in the clear
form or in the protected form, such as secret sharing. After the execution, all the entities should reach a
consensus on whether the proof was accepted or rejected.
NOTE See ISO/IEC 4922-1 and ISO/IEC 4922-2 for more details on MPC.
Figure 3 — Verifier module
5.4 Characteristics of ZKPs
Originally, ZKP was introduced using examples of a dialogue between two parties where some computations
were performed on numbers belonging to certain algebraic structures (e.g. finite fields), or on other kinds of
structured data (e.g. graphs). Later, these computations were transposed into real world situations.
The composite statement of a ZKP usually consists of ANDs, ORs and function compositions of a mix of
algebraic and arithmetic operations (expressed by a set of additions and multiplications).
An OR-composition is a set of statements, where the prover wants to show in zero-knowledge that at least
one of these statements is true, but without revealing which one.
The sequential composition of two or more ZKP protocols is still a ZKP protocol.
Sigma protocols are efficient for algebraic statements while much slower for non-algebraic ones. So, an
appropriate (and possibly different) ZKP protocol should be used for each individual statement which is part
of a composite statement.
Some useful ZKP protocols include the following:
a) zero-knowledge range protocols that allow determination of whether a value fits within some range of
values; and
b) zero-knowledge set membership protocols that allow determination of whether a value belongs to a set
of valid values.
Some of these protocols may be based on the use of one-way cryptographic accumulators, in particular
Merkle hash trees and RSA accumulators.
A zero-knowledge range protocol is a special case of a zero-knowledge set membership protocol, because
any numeric interval is also a set of values. Therefore, if a zero-knowledge set membership protocol can be
© ISO/IEC 2026 – All rights reserved
more efficient in solving a given problem than a zero-knowledge range protocol, then the zero-knowledge
set membership protocol can replace zero-knowledge range protocol to increase the performance.
Depending upon the number of values in the set, different zero-knowledge set membership protocols can be
used. An inappropriate mechanism, while working, may exhibit bad performance, e.g. one mechanism may
be efficient if the size of the set of members is lower than one hundred, while another one may be efficient if
the set is larger than several thousands.
5.5 ZKP performance
Key considerations for ZKP performance are:
a) Computation time: If there is a setup phase, the computation time for the setup should be considered.
In all cases, computation time for generation of proof and for its verification should be considered.
b) Size of the messages exchanged: Size of the messages can also be several Kilobytes long.
c) Number of communication rounds: This is especially true for interactive (IZKP) based mechanisms.
There are always trade-offs between the proof size, the prover cost, and CRS size/generation cost.
As an example, there can be fewer computations for the prover at the cost of increasing the size of the proof.
See Annex A for factors facilitating or hindering ZKP developments.
6 Considerations of implementing ZKPs for attribute verification
6.1 Attribute providers
Attributes related to the prover are typically held by some trusted third parties, e.g. a bank. They can
disclose a subset of the attributes or can generate computed attributes
...
FINAL DRAFT
International
Standard
ISO/IEC FDIS
ISO/IEC JTC 1/SC 27
Information security, cybersecurity
Secretariat: DIN
and privacy protection —
Voting begins on:
Guidelines on privacy preservation
2025-11-04
based on zero-knowledge proofs
Voting terminates on:
2025-12-30
RECIPIENTS OF THIS DRAFT ARE INVITED TO SUBMIT,
WITH THEIR COMMENTS, NOTIFICATION OF ANY
RELEVANT PATENT RIGHTS OF WHICH THEY ARE AWARE
AND TO PROVIDE SUPPOR TING DOCUMENTATION.
IN ADDITION TO THEIR EVALUATION AS
BEING ACCEPTABLE FOR INDUSTRIAL, TECHNO
LOGICAL, COMMERCIAL AND USER PURPOSES, DRAFT
INTERNATIONAL STANDARDS MAY ON OCCASION HAVE
TO BE CONSIDERED IN THE LIGHT OF THEIR POTENTIAL
TO BECOME STAN DARDS TO WHICH REFERENCE MAY BE
MADE IN NATIONAL REGULATIONS.
Reference number
ISO/IEC FDIS 27565:2025(en) © ISO/IEC 2025
FINAL DRAFT
ISO/IEC FDIS 27565:2025(en)
International
Standard
ISO/IEC FDIS
ISO/IEC JTC 1/SC 27
Information security, cybersecurity
Secretariat: DIN
and privacy protection —
Voting begins on:
Guidelines on privacy preservation
based on zero-knowledge proofs
Voting terminates on:
RECIPIENTS OF THIS DRAFT ARE INVITED TO SUBMIT,
WITH THEIR COMMENTS, NOTIFICATION OF ANY
RELEVANT PATENT RIGHTS OF WHICH THEY ARE AWARE
AND TO PROVIDE SUPPOR TING DOCUMENTATION.
© ISO/IEC 2025
IN ADDITION TO THEIR EVALUATION AS
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
BEING ACCEPTABLE FOR INDUSTRIAL, TECHNO
LOGICAL, COMMERCIAL AND USER PURPOSES, DRAFT
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on
INTERNATIONAL STANDARDS MAY ON OCCASION HAVE
the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address below
TO BE CONSIDERED IN THE LIGHT OF THEIR POTENTIAL
or ISO’s member body in the country of the requester.
TO BECOME STAN DARDS TO WHICH REFERENCE MAY BE
MADE IN NATIONAL REGULATIONS.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: +41 22 749 01 11
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland Reference number
ISO/IEC FDIS 27565:2025(en) © ISO/IEC 2025
© ISO/IEC 2025 – All rights reserved
ii
ISO/IEC FDIS 27565:2025(en)
Contents Page
Foreword .v
Introduction .vi
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Abbreviated terms . 4
5 Introduction to zero-knowledge proofs . . 4
5.1 General .4
5.2 Interactive and Non-interactive ZKP .5
5.2.1 General .5
5.2.2 Interactive zero-knowledge proofs .5
5.2.3 Non-interactive zero-knowledge proofs .6
5.3 Components of a ZKP system.7
5.3.1 General .7
5.3.2 Setup module .7
5.3.3 Prover module .9
5.3.4 Verifier module .9
5.4 Characteristics of ZKPs .10
5.5 ZKP performance .11
6 Considerations of implementing ZKPs for attribute verification .11
6.1 Attribute providers .11
6.2 Replay attack detection or protection .11
6.3 Prevention of collusions between users . 12
6.4 Use of an authoritative document or of a trusted authority . 12
7 Use cases of ZKPs .12
7.1 Proving some properties of a hidden attribute . 12
7.2 Proving the contents in an authoritative document . 13
7.3 Proving the contents across several authoritative documents .14
7.4 Selective disclosure of attributes.14
7.4.1 General .14
7.4.2 Pre-generation of digital credentials .14
7.4.3 On-demand generation of digital credentials . 15
8 Privacy preservation using zero-knowledge proofs .15
8.1 Privacy principles in the context of ZKP . 15
8.2 Privacy risk assessment . 15
8.3 Privacy functional requirements for ZKP .16
8.3.1 General .16
8.3.2 Collection limitation . .16
8.3.3 Data minimization .16
8.3.4 Options and choice .17
8.3.5 Selective disclosure .17
8.3.6 Purpose legitimacy and specification .17
8.3.7 Anonymity of the authority that has issued the attestation .17
8.3.8 Non-disclosure of the identity of the verifiers to the attribute issuer .17
8.3.9 Use, retention and disclosure limitation .17
8.3.10 Accuracy and quality .17
8.3.11 Openness, transparency and notice .17
8.3.12 Individual participation and access .17
8.3.13 Accountability .17
8.3.14 Information security . . .18
8.3.15 Unlinkability .18
8.4 Security considerations .18
© ISO/IEC 2025 – All rights reserved
iii
ISO/IEC FDIS 27565:2025(en)
9 Functional use cases .18
9.1 Functional use examples .18
9.2 Selection of ZKP models .19
10 Business use examples .20
10.1 Age verification . 20
10.2 Fraud prevention . 20
10.3 Auction . 20
10.4 Disability proof . 20
10.5 Distributed ledger technologies and blockchains .21
10.6 Central bank digital currencies .21
Annex A (informative) Factors facilitating or hindering ZKP developments .22
Annex B (informative) Subject binding .23
Annex C (informative) Example of a consistency check between two documents .24
Annex D (informative) Example of ZKP for selective disclosure .26
Annex E (informative) Examples of selective disclosure without using ZKPs .28
Annex F (informative) Example of secure comparison of two numbers .29
Annex G (informative) Implementing digital credentials with ZKP .31
Bibliography .36
© ISO/IEC 2025 – All rights reserved
iv
ISO/IEC FDIS 27565:2025(en)
Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that are
members of ISO or IEC participate in the development of International Standards through technical
committees established by the respective organization to deal with particular fields of technical activity.
ISO and IEC technical committees collaborate in fields of mutual interest. Other international organizations,
governmental and non-governmental, in liaison with ISO and IEC, also take part in the work.
The procedures used to develop this document and those intended for its further maintenance are described
in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the different types
of document should be noted. This document was drafted in accordance with the editorial rules of the ISO/
IEC Directives, Part 2 (see www.iso.org/directives or www.iec.ch/members_experts/refdocs).
ISO and IEC draw attention to the possibility that the implementation of this document may involve the
use of (a) patent(s). ISO and IEC take no position concerning the evidence, validity or applicability of any
claimed patent rights in respect thereof. As of the date of publication of this document, ISO and IEC had not
received notice of (a) patent(s) which may be required to implement this document. However, implementers
are cautioned that this may not represent the latest information, which may be obtained from the patent
database available at www.iso.org/patents and https://patents.iec.ch. ISO and IEC shall not be held
responsible for identifying any or all such patent rights.
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and expressions
related to conformity assessment, as well as information about ISO's adherence to the World Trade
Organization (WTO) principles in the Technical Barriers to Trade (TBT) see www.iso.org/iso/foreword.html.
In the IEC, see www.iec.ch/understanding-standards.
This document was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology,
Subcommittee SC 27, Information security, cybersecurity and privacy protection.
Any feedback or questions on this document should be directed to the user’s national standards
body. A complete listing of these bodies can be found at www.iso.org/members.html and
www.iec.ch/national-committees.
© ISO/IEC 2025 – All rights reserved
v
ISO/IEC FDIS 27565:2025(en)
Introduction
The world is witnessing unprecedented data-driven innovation and growth in digital technologies that
include use of big data, AI and blockchain. These technologies are providing societal and economic benefits,
as well as improving efficiency, user experience and convenience. At the same time, there is a corresponding
increase in privacy risks that requires stronger privacy preserving measures to minimize such risks when
designing and implementing solutions. Legislators are introducing new data privacy laws and regulations,
and strengthening existing ones, to make organizations accountable and compliant with data privacy
protection requirements. They also require support for investigation and regulatory enforcement, where
privacy protections are being misused to harm society.
A number of new technologies enable organizations to operate and do business in new ways that are
compliant with many regulations, while still protecting privacy. These privacy-enhancing technologies
(PETs) apply data protection principles intended to minimize the exposure and use of personal data.
Zero-knowledge proof (ZKP) technology is one such PET, which preserves privacy by eliminating the need
to expose or share personal information and personally identifying information (PII), while achieving its
desired function. ZKP is a privacy-enhancing technology that can be used to adhere to the principles of
collection limitation, user consent and choice and disclosure limitation as mentioned in ISO/IEC 29100.
ZKP allows the validation of data held by an authoritative or an authentic source if it is known to both
the prover and the verifier. This results in greater compliance with the data minimization principle of
ISO/IEC 29100, since only necessary data are disclosed.
This document begins with an explanation of ZKP and its features. It then describes the privacy and
functional requirements that ZKP can address and provides guidelines for using ZKP in a way that is most
useful for privacy practitioners.
© ISO/IEC 2025 – All rights reserved
vi
FINAL DRAFT International Standard ISO/IEC FDIS 27565:2025(en)
Information security, cybersecurity and privacy
protection — Guidelines on privacy preservation based on
zero-knowledge proofs
1 Scope
This document provides guidelines on using zero-knowledge proofs (ZKP) to improve privacy by reducing
the risks associated with the sharing or transmission of personal data between organizations and users by
minimizing unnecessary information disclosure. It includes several ZKP functional requirements relevant to
a range of different business use cases, then describes how different ZKP models can be used to meet those
functional requirements securely.
2 Normative references
There are no normative references in this document.
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
ISO and IEC maintain terminology databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https:// www .iso .org/ obp
— IEC Electropedia: available at https:// www .electropedia .org/
3.1
application
software component that issues commands and receives responses to the commands within a system
[SOURCE: ISO/IEC 15961-1:2021, 3.1.1]
3.2
application attestation
confirmation to a server that it is communicating with an instance of its genuine application (3.1) that has
specific characteristics and is running in a trusted environment
3.3
attribute
characteristic or property of an entity
EXAMPLE An entity type, address information, telephone number, a privilege, a MAC address, a domain name are
possible attributes.
[SOURCE: ISO/IEC 24760-1:2025, 3.1.3]
3.4
attribute provider
authority trusted by one or more users and one or more relying parties to issue or verify attributes (3.3)
related to an entity
[SOURCE: ISO/IEC 27551:2021, 3.2]
© ISO/IEC 2025 – All rights reserved
ISO/IEC FDIS 27565:2025(en)
3.5
authoritative document
document known to be reliable because its authority or authenticity is widely recognized or it bears a
signature or seal attesting its validity
3.6
completeness
property where a trusted verifier can be convinced by a trusted prover that a statement is true with
overwhelming probability
3.7
computed attribute
attribute (3.3) that is computed from one or more attributes and public information
3.8
digital credential
set of identity attributes and associated data about an individual, cryptographically signed in advance by a
credential issuer which includes key information that allows to demonstrate the possession of it
3.9
digital credential issuer
authoritative source that registers subscribers and subsequently issues digital credentials to its subscribers
3.10
digital wallet
application (3.1) that stores and manages digital credentials and keys and can use them upon request
3.11
domain
environment where an entity can use a set of attributes (3.3) for identification and other purposes
[SOURCE: ISO/IEC 24760-1:2025, 3.2.3, modified — notes to entry and example have been removed.]
3.12
distinguishing identifier
information which unambiguously distinguishes an entity within a given context
[SOURCE: ISO/IEC 11770-7:2021, 3.5, modified —“within a given context” has been added.]
3.13
identifying attribute
attribute (3.2) that contributes to uniquely identifying a subject within a context
[SOURCE: ISO/IEC TS 29003:2018, 3.8]
3.14
linkability
property for a dataset that it is possible to associate (by linking) a record concerning a data principal with a
record concerning the same data principal in a separate dataset
[SOURCE: ISO/IEC 20889:2018, 3.20]
3.15
online
normal state of the data link layer where both application and network management communication are
possible
[SOURCE: ISO 17356-1:2005, 2.80]
© ISO/IEC 2025 – All rights reserved
ISO/IEC FDIS 27565:2025(en)
3.16
personal data
information relating to an identified or identifiable natural person
[SOURCE: ISO/TS 17573-2:2020, 3.136]
3.17
proof verification
process where a verifier checks that a proof is valid
Note 1 to entry: Checks can include the cryptography and digital signature.
3.18
prover
entity that presents a proof to a verifier
Note 1 to entry: The prover may be an authoritative source or a trusted intermediary.
3.19
public coin interactive zero-knowledge proof
public coin interactive ZKP
interactive zero-knowledge proof (ZKP) (3.26) where the verifier’s messages are uniformly random and
independent of the prover’s messages
3.20
record
set of attributes concerning a single data principal
3.21
soundness
property where a malicious prover, if the statement is false, has only a negligible chance in convincing a
verifier that the statement is true
3.22
subject binding
property that assures that a claim is associated with the correct natural person
3.23
trusted execution environment
TEE
aspect of the mobile device comprising either hardware or software, or both, which provides security
services to the mobile device computing environment, protects data against general software attacks and
isolates hardware and software security resources from the operating system
[SOURCE: ISO 12812-1:2017, 3.60]
3.24
unlinkability
property that ensures that an individual may make multiple uses of resources or services without others
being able to link these uses together
Note 1 to entry: There is a distinction between the following two cases: (i) multiple uses of the same services, and (ii)
the uses of multiple different services.
[SOURCE: ISO/IEC TR 27550:2019, 3.25, modified — note 1 to entry has been added.]
3.25
verifier
entity relying on a verified proof to prove that a statement is true
Note 1 to entry: The verifier is often the relying party seeking proof that a claimed attribute or statement made by an
individual is true.
© ISO/IEC 2025 – All rights reserved
ISO/IEC FDIS 27565:2025(en)
3.26
zero-knowledge proof
ZKP
method involving one or more exchanges between a prover and a verifier where the prover is able to
convince the verifier that a statement is true, without revealing to the verifier any additional information
beyond that knowledge
3.27
zero-knowledge proof functional requirement
ZKP functional requirement
functional requirements of a system to be fulfilled using zero-knowledge proof (ZKP) (3.26)
4 Abbreviated terms
anti-money laundering AML
central bank digital currency CBDC
certification revocation list CRL
common reference string CRS
counter terrorist financing CTF
distributed ledger technology DLT
multi-party computation MPC
national institute of standards and technology NIST
non-interactive zero-knowledge proof NIZKP
online certificate status protocol OCSP
personally identifiable information PII
public key certificate PKC
trusted third party TTP
5 Introduction to zero-knowledge proofs
5.1 General
In the digital world, not collecting or exposing personal information is the best possible way to preserve the
privacy of an individual. However, this is not always practically possible due to the need to use or validate
personal information for various business and legal purposes during the course of a business process or
the provision of a public service. For instance, it can be necessary for individuals to validate a claimed
bank statement to determine eligibility for a loan; or to verify the age of a visitor to a nightclub to ensure
compliance to legal requirements.
Sometimes, it is possible to avoid the overcollection of personal information using ZKP techniques since
the knowledge of some property about it can be sufficient. Instead of oversharing confidential personal
information to satisfy a factual criterion, it is possible to use ZKP to convince the verifier that a certain
statement or a set of statements is true. During the proof, only very limited personal information is
revealed to the verifier, thereby eliminating the potential harm that can be caused by exposing the personal
information.
© ISO/IEC 2025 – All rights reserved
ISO/IEC FDIS 27565:2025(en)
When making a PII-based decision, personal information (attributes) should be associated with the correct
subject. Using ZKPs, the prover can prove that the relevant attributes satisfy certain criteria and those
attributes are associated with the correct subject in a privacy-preserving manner.
ZKP is an important privacy-enhancing tool based on cryptography. Every ZKP system involves at least a
prover and a verifier. A ZKP system is a protocol specification for how a prover and verifier(s) can interact
so that the prover can convince the verifier(s) that a given statement or a set of statements is true. ZKPs
were initially developed by the academic community in the 1980s and have seen tremendous improvements
since then. They are now of practical feasibility in multiple domains of interest across different industries
and to a large community of developers and researchers. ZKPs can have a positive impact in industries and
agencies, and for personal use, by allowing privacy-preserving applications, where permitted, to learn some
properties or characteristics of or about private data, despite not disclosing their values.
A ZKP makes it possible to prove that a statement or a set of statements is true while preserving confidentiality
of secret information. This makes sense when the veracity of the statement or a set of statements is not
obvious on its own, but the prover knows relevant secret information that enables a proof to be made.
A ZKP protocol usually supports the following three properties:
a) completeness: if the prover's statement is true, then the verifier accepts it with overwhelming
probability;
b) soundness: if the prover's statement is false, then no matter how the prover behaves, the verifier rejects
it with overwhelming probability;
c) zero-knowledge: if the statement is true, no verifier learns any information other than the fact that the
statement is true.
In addition to the three well-known properties applicable to ZKP protocols, a non-interactive zero-knowledge
proof (NIZKP) protocol usually supports the following two additional properties:
d) replay detection/protection against the same verifier: If a user saves a previously sent NIZKP exchange
and replays it to the same verifier, that verifier rejects it with high probability.
This can be resolved by including a challenge sent by the verifier or a date and time in the ZKP.
e) replay detection/protection against a different verifier: If a user saves a previously sent NIZKP exchange
and replays it to a different verifier, that verifier rejects it with high probability.
This can be resolved by including an identifier of the designated verifier in the ZKP.
5.2 Interactive and Non-interactive ZKP
5.2.1 General
ZKP can be divided into two categories:
a) interactive ZKP;
b) non-interactive ZKP.
An interactive ZKP requires several rounds of interaction between the prover and the verifier before a
decision can be made. Whereas, for a non-interactive ZKP, the prover can just send one-message proof to the
verifier. In practice, it is possible that the verifier was not online when the proof was produced.
5.2.2 Interactive zero-knowledge proofs
To establish such proofs, both the verifier and the prover should be online at same time. In order to prove the
same statement again to another verifier, the prover should interact with another verifier again.
© ISO/IEC 2025 – All rights reserved
ISO/IEC FDIS 27565:2025(en)
During an interactive ZKP protocol, three or more messages are exchanged between the prover and the
verifier. If the verifier’s messages are uniformly random and independent of the prover’s messages, this ZKP
is a public coin protocol.
A special type of public coin interactive ZKP is the Sigma protocol, which involves the exchange of three values:
1) During the commitment phase, a first message is sent from the prover to the verifier that contains an
element a ,
2) During the challenge phase, a second message (fresh random value) is sent from the verifier to the
prover that contains a challenge c , and
3) During the response phase, a final message z is computed by the prover and sent from the prover to the
verifier.
At the end of the interaction, the verifier makes a decision whether a statement x is true or false based on
the values of ()ac,,z .
In general, more than three messages can be exchanged during the ZKP. Some ZKP requires multiple rounds
to achieve a satisfying soundness probability.
NOTE For some systems, before the exchanges can take place, it can be necessary for some parameters, (both
public and private) to be securely distributed to the prover and the verifier.
5.2.3 Non-interactive zero-knowledge proofs
5.2.3.1 General
When the ZKP is non-interactive, the interaction between the prover and the verifier to build the proof
consists of a single message sent by the prover to the verifier.
Public-coin interactive ZKP protocols can be transformed to non-interactive ZKP by replacing the verifier's
challenge message(s) by pseudorandom values. There are various ways to generate these messages; three
different approaches are specified in 5.2.3.2 to 5.2.3.4.
5.2.3.2 Using a cryptographic hash function to simulate the behaviour of the verifier
A cryptographic hash function can be used to simulate the public coin challenge message sent by the verifier.
This technique is known as the Fiat–Shamir heuristic. For example, consider a Sigma protocol where the
prover wants to convince the verifier a statement x is true. The prover generates the first message, a . Then,
it hashes cH = ()xa, and computes the correct response, z for the challenge c . It then sends π = ()az, as
proof. To validate the proof, the verifier executes the hash function on ()xa, to calculate c and verifies that
()ac,, z is a valid Sigma protocol transcript. In this way, the challenge is not freely chosen by the prover,
and it is unpredictable until the first message, a , is determined. Such technique has been generalized by
using a common random string that is no more defined for producing a single proof but to produce an
unlimited number of proofs. See 5.2.3.4.
See ISO/IEC 10118-1, ISO/IEC 10118-2, ISO/IEC 10118-3, and ISO/IEC 10118-4 for more details on
cryptographic hash function.
5.2.3.3 Using trusted public source of random values to simulate the behaviour of the verifier
The goal is to use public random sources which are periodically renewed and where it can be verified that
they were not created before a specific time. This characteristic can be met by using a public utility that
provides trusted random values that can be used to simulate the public coin challenge messages that are
normally generated and sent by the verifier. For example, such public utilities are available in the form of
public beacons from the United States of America, Brazil and Chile.
© ISO/IEC 2025 – All rights reserved
ISO/IEC FDIS 27565:2025(en)
5.2.3.4 Using a structured Common Reference String
The Common Reference String (CRS) can be used to embed the challenges that the prover should answer
during the generation of the proof. The manner of the embedding is such, that the prover does not learn the
challenge, but the verifier is able to check that the response is correct.
Depending on the protocol, such CRS may be generated by the verifier (in which case we have the designated
verifier setup), or it should be generated by a trusted source.
5.3 Components of a ZKP system
5.3.1 General
All ZKP systems have two fundamental components (also known as modules):
a) prover module; and
b) verifier module.
Some ZKP systems additionally require a trusted setup module.
5.3.2 Setup module
The setup module takes some specification as input, and it outputs a CRS. The CRS may include system
parameters, such as the group specification and common reference elements.
Figure 1 depicts three suggested deployment scenarios for the trusted setup module, where S1, S2 and S3
are three servers.
1) Scenario one: The setup module is executed by a single trusted and auditable entity. This entity should
erase its memory after the execution to prevent potential leakage of secret information that can be used
to violate the security guarantees.
2) Scenario two: The setup module is executed inside a trusted execution environment (TEE) of an
untrusted entity. After the execution, the TEE would output the reference strings and erase all the
internal state.
3) Scenario three: The setup module is executed in a collaboration of multiple entities using a secure
multiparty computation (MPC) protocol, where privacy and correctness are ensured even when a
certain proportion of entities are malicious. No information leaves any of the entities.
NOTE 1 See ISO/IEC 4922-1 and ISO/IEC 4922-2 for more details on MPC.
© ISO/IEC 2025 – All rights reserved
ISO/IEC FDIS 27565:2025(en)
Key
S1 server 1
S2 server 2
S3 server 3
Figure 1 — Setup module
There are several variations of the setup and the level of trust placed in it, including the following:
NOTE 2 See ISO/IEC 9798-5 for more details.
a) No setup or trustless setup: This is when no trust is needed, for example because the setup is just a copy
of a security parameter, or because everyone can directly verify the setup.
b) Uniform random string: All parties have access to a uniform random string (URS) from a trusted
common source of randomness e.g. sunspot activity.
c) Common reference string: The URS model is a special case of the CRS model. However, in the CRS model,
it is also possible that the common setup is sampled with a non-uniform distribution, which can exclude
easy access to a trusted common source. A distinction can be made as to whether the CRS has a verifiable
structure, i.e. it is easy to verify that the CRS is well-formed.
d) Designated verifier setup: A setup, where the verifier receives some extra private information (in
addition to the public CRS received by all parties) so that it can verify the proof. This depends on the
setup algorithm being trusted.
e) Random oracle model: The common setup describes a cryptographic hash function, e.g. SHA256 (see
ISO/IEC 10118-3 for more details). In the random oracle model, the hash function is heuristically
assumed to act like a random oracle that returns a random value whenever it is queried on an input not
seen before. There are theoretical examples where the random oracle model fails, exploiting the fact
that in real life the hash function is a deterministic function, but in practice the heuristic gives good
efficiency and currently no weaknesses are known in practice.
f) Updatable CRS: In some ZKP systems, the CRS can be updated after its initial setup. Updating a CRS
nullifies the trapdoor associated with the old CRS, which makes the system more trustworthy.
© ISO/IEC 2025 – All rights reserved
ISO/IEC FDIS 27565:2025(en)
NOTE 3 Auditors can be either authorities or any renowned trusted third party.
5.3.3 Prover module
The prover module takes the statement and the witness as input. It may also optionally take the common
reference string (CRS) generated by the setup module as extra input. It interacts with the verifier module
according to the ZKP protocol description, aiming to convince the verifier that the statement is true.
The prover module can be executed by a single entity or among multiple entities. Figure 2 depicts two
suggested deployment scenarios for the prover module, where P1, P2, and P3 are three provers.
1) Scenario one: The prover module is executed by a single entity. It takes the prover reference string,
relevant public information, private information as input, and it interacts with the verifier module via
some medium.
2) Scenario two: The prover module is executed among multiple entities forming MPC. The prover reference
string, relevant public information and private information can be input to those entities either in the
clear form or in the protected form, such as secret sharing.
NOTE See ISO/IEC 4922-1 and ISO/IEC 4922-2 for more details on MPC.
Key
P1 prover 1
P2 prover 2
P3 prover 3
Figure 2 — Prover module
5.3.4 Verifier module
The verifier module takes the statement as input. It may also optionally take the CRS generated by the setup
module as extra input. It interacts with the prover module according to the ZKP protocol description and
outputs a decision on whether it accepts the proof at the end of the interaction.
The verifier module can be executed by a single entity or among multiple entities. Figure 3 depicts two
suggested deployment scenarios for the verifier module, where V1, V2, and V3 are three verifiers.
1) Scenario one: The verifier module is executed by a single entity. It takes the verifier reference string and
relevant public information as inputs, and it interacts with the prover module via some medium.
© ISO/IEC 2025 – All rights reserved
ISO/IEC FDIS 27565:2025(en)
2) Scenario two: The verifier module is executed among multiple entities forming MPC. The verifier
reference string and relevant public information may be input into those entities either in the clear
form or in the protected form, such as secret sharing. After the execution, all the entities should reach a
consensus on whether the proof was accepted or rejected.
NOTE See ISO/IEC 4922-1 and ISO/IEC 4922-2 for more details on MPC.
Figure 3 — Verifier module
5.4 Characteristics of ZKPs
Originally, ZKP was introduced using examples of a dialogue between two parties where some computations
were performed on numbers belonging to certain algebraic structures (e.g. finite fields), or on other kinds of
structured data (e.g. graphs). Later, these computations were transposed into real world situations.
The composite statement of a ZKP usually consists of ANDs, ORs and function compositions of a mix of
algebraic and arithmetic operations (expressed by a set of additions and multiplications).
An OR-composition is a set of statements, where the prover wants to show in zero-knowledge that at least
one of these statements is true, but without revealing which one.
The sequential composition of two or more ZKP protocols is still a ZKP protocol.
Sigma protocols are efficient for algebraic statements while much slower for non-algebraic ones. So, an
appropriate (and possibly different) ZKP protocol should be used for each individual statement which is part
of a composite statement.
Some useful ZKP protocols include the following:
a) zero-knowledge range protocols that allow determination of whether a value fits within some range of
values; and
b) zero-knowledge set membership protocols that allow determination of whether a value belongs to a set
of valid values.
Some of these protocols may be based on the use of one-way cryptographic accumulators, in particular
Merkle hash trees and RSA accumulators.
A zero-knowledge range protocol is a special case of a zero-knowledge set membership protocol, because
any numeric interval is also a set of values. Therefore, if a zero-knowledge set membership protocol can be
© ISO/IEC 2025 – All rights reserved
ISO/IEC FDIS 27565:2025(en)
more efficient in solving a given problem than a zero-knowledge range protocol, then the zero-knowledge
set membership protocol can replace zero-knowledge range protocol to increase the performance.
Depending upon the number of values in the set, different zero-knowledge set membership
...
Formatted
...
Style Definition
...
Style Definition
...
Style Definition
...
Style Definition
...
ISO/IEC DISFDIS 27565.2:2025(en)
Style Definition
...
ISO/IEC JTC 1/SC 27
Style Definition
...
Style Definition
...
Secretariat: DIN
Style Definition
...
Date: 2025-06-10-20
Style Definition
...
Style Definition
...
Style Definition
...
Style Definition
...
Style Definition
...
Style Definition
...
Information security, cybersecurity and privacy protection —
Style Definition
...
Guidelines on privacy preservation based on zero-knowledge proofs
Style Definition
...
Sécurité de l'information, cybersécurité et protection de la vie privée — Lignes directrices pour la préservap to
Style Definition
...
htion de la vie privée basées sur des preuves à divulgationu nulle de connaissance
Style Definition
...
Style Definition
...
Style Definition
...
Style Definition
...
Style Definition
...
Style Definition
...
Style Definition
...
Style Definition
...
FDIS stage
Style Definition
...
Style Definition
...
Style Definition
...
Style Definition
...
Style Definition
...
Style Definition
...
Style Definition
...
Style Definition
...
Style Definition
...
Style Definition
...
Style Definition
...
Style Definition
...
Style Definition
...
Style Definition
...
Style Definition
...
Style Definition
...
Style Definition
...
Style Definition
...
Style Definition
...
Style Definition
...
Style Definition
...
Style Definition
...
Style Definition
...
Style Definition
...
Style Definition
...
Style Definition
...
Style Definition
...
Style Definition
...
Style Definition
...
Style Definition
...
Style Definition
...
St l D fi iti
ISO/IEC FDIS 27565:2025(en)
Formatted: Font: Bold
Formatted: HeaderCentered
© ISO/IEC 2025
Formatted: Default Paragraph Font
Formatted: Default Paragraph Font
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication
may be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying,
or posting on the internet or an intranet, without prior written permission. Permission can be requested from either ISO
at the address below or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: + 41 22 749 01 11
EmailE-mail: copyright@iso.org
Website: www.iso.orgwww.iso.org
Published in Switzerland
Formatted: FooterPageRomanNumber
© ISO/IEC 2025 – All rights reserved
ii
ISO/IEC DISFDIS 27565.2:2025(en) Formatted: Font: 11 pt, Bold
Formatted: Font: 11 pt, Bold
Formatted: Font: 11 pt, Bold
Contents
Formatted: Font: Bold
Formatted: HeaderCentered, Left
Foreword . vii
Formatted: Adjust space between Latin and Asian text,
Introduction . viii
Adjust space between Asian text and numbers, Tab
1 Scope . 1 stops: Not at 10.01 cm
2 Normative references . 1
3 Terms and definitions . 1
4 Abbreviated terms . 4
5 Introduction to zero-knowledge proofs . 5
5.1 General. 5
5.2 Interactive and Non-interactive ZKP . 6
5.3 Components of a ZKP system . 7
5.4 Characteristics of ZKPs . 12
5.5 ZKP performance . 13
6 Considerations of implementing ZKPs for attribute verification . 14
6.1 Attribute providers . 14
6.2 Replay attack detection or protection . 14
6.3 Prevention of collusions between users . 14
6.4 Use of an authoritative document or of a trusted authority . 15
7 Use cases of ZKPs . 15
7.1 Proving some properties of a hidden attribute . 15
7.2 Proving the contents in an authoritative document . 16
7.3 Proving the contents across several authoritative documents . 17
7.4 Selective disclosure of attributes . 17
8 Privacy preservation using zero-knowledge proofs . 19
8.1 Privacy principles in the context of ZKP . 19
8.2 Privacy risk assessment . 19
8.3 Privacy functional requirements for ZKP . 20
8.4 Security considerations . 21
9 Functional use cases . 22
9.1 Functional use examples . 22
9.2 Selection of ZKP models . 23
10 Business use examples . 23
10.1 Age verification . 23
10.2 Fraud prevention . 24
10.3 Auction . 24
10.4 Disability proof . 24
10.5 Distributed ledger technologies and blockchains . 25
10.6 Central bank digital currencies . 25
Annex A (informative) Factors facilitating or hindering ZKP developments . 26
Annex B (informative) Subject binding . 27
Formatted: Font: 10 pt
Annex C (informative) Example of a consistency check between two documents . 29
Formatted: FooterCentered, Left, Space Before: 0 pt,
Annex D (informative) Example of ZKP for selective disclosure . 31
Tab stops: Not at 17.2 cm
Annex E (informative) Examples of selective disclosure without using ZKPs . 33
Formatted: Font: 11 pt
Annex F (informative) Example of secure comparison of two numbers . 34
Formatted: FooterPageRomanNumber, Left, Space
After: 0 pt, Tab stops: Not at 17.2 cm
© ISO/IEC 2025 – All rights reserved
iii
ISO/IEC FDIS 27565:2025(en)
Formatted: Font: Bold
Formatted: HeaderCentered
Annex G (informative) Implementing digital credentials with ZKP . 36
Bibliography . 41
Foreword . vi
Introduction . vii
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Abbreviated terms . 4
5 Introduction to Zero-knowledge Proofs . 5
5.1 General. 5
5.2 Interactive and Non-interactive ZKP . 6
5.2.1 General. 6
5.2.2 Interactive zero-knowledge proofs . 6
5.2.3 Non-interactive zero-knowledge proofs . 6
5.3 Components of a ZKP system . 7
5.3.1 General. 7
5.3.2 Setup module . 7
Figure 1 — Setup module . 8
5.3.3 Prover module . 9
Figure 2 — Prover module . 9
5.3.4 Verifier module. 10
Figure 3 — Verifier module . 10
5.4 Characteristics of ZKPs . 10
5.5 ZKP performance . 11
6 Considerations of implementing ZKPs for attribute verification . 11
6.1 Attribute providers . 11
6.2 Replay attack detection or protection . 12
6.3 Prevention of collusions between users . 12
6.4 Use of an authoritative document or of a trusted authority . 12
7 Use cases of ZKPs . 12
7.1 Proving some properties of a hidden attribute . 12
Figure 4 — ZKP of a property relative to a hidden attribute . 13
7.2 Proving the contents in an authoritative document . 13
7.3 Proving the contents across several authoritative documents . 14
7.4 Selective disclosure of attributes . 14
7.4.1 General. 14
7.4.2 Pre-generation of digital credentials . 14
7.4.3 On-demand generation of digital credentials . 15
8 Privacy preservation using zero-knowledge proofs . 15
8.1 Privacy principles in the context of ZKP . 15
8.2 Privacy risk assessment . 16
8.3 Privacy functional requirements for ZKP . 16
8.3.1 General. 16
8.3.2 Collection limitation . 17
8.3.3 Data minimization . 17
8.3.4 Options and choice . 17
Formatted: FooterPageRomanNumber
© ISO/IEC 2025 – All rights reserved
iv
ISO/IEC DISFDIS 27565.2:2025(en) Formatted: Font: 11 pt, Bold
Formatted: Font: 11 pt, Bold
Formatted: Font: 11 pt, Bold
8.3.5 Selective disclosure . 17
Formatted: Font: Bold
8.3.6 Purpose legitimacy and specification . 17
8.3.7 Anonymity of the authority that has issued the attestation . 17
Formatted: HeaderCentered, Left
8.3.8 Non-disclosure of the identity of the verifiers to the attribute issuer . 17
8.3.9 Use, retention and disclosure limitation . 17
8.3.10 Accuracy and quality . 17
8.3.11 Openness, transparency and notice . 17
8.3.12 Individual participation and access . 17
8.3.13 Accountability . 17
8.3.14 Information security . 18
8.3.15 Unlinkability . 18
8.4 Security considerations . 18
9 Functional use cases . 19
9.1 Functional use examples . 19
9.2 Selection of ZKP models . 19
Table 1 — Choice considerations of ZKP models . 19
10 Business use examples . 20
10.1 Age verification . 20
10.2 Fraud prevention . 20
10.3 Auction . 21
10.4 Disability proof . 21
10.5 Distributed ledger technologies and blockchains . 21
10.6 Central bank digital currencies . 21
Annex A (informative) Factors facilitating or hindering ZKP developments . 22
A.1 Factors facilitating ZKP developments . 22
A.2 Factors hindering ZKP developments . 22
A.3 Post-quantum resistance . 22
Annex B Subject binding . 23
B.1 General. 23
Annex C (informative) Example of a consistency check between two documents . 25
C.1 General. 25
C.2 Document structure . 25
C.3 Roles . 25
C.4 Protocol . 25
Annex D (informative) Example of ZKP for selective disclosure . 27
D.1 General. 27
D.2 Database structure . 27
D.3 Roles . 27
D.4 Protocol . 27
Formatted: Font: 10 pt
Annex E (informative) Examples of selective disclosure without using ZKPs . 29
Formatted: FooterCentered, Left, Space Before: 0 pt,
E.1 General. 29
Tab stops: Not at 17.2 cm
Annex F (informative) Example of secure comparison of two numbers . 30
Formatted: Font: 11 pt
F.1 General. 30
Formatted: FooterPageRomanNumber, Left, Space
After: 0 pt, Tab stops: Not at 17.2 cm
© ISO/IEC 2025 – All rights reserved
v
ISO/IEC FDIS 27565:2025(en)
Formatted: Font: Bold
Formatted: HeaderCentered
F.2 Data structure . 30
F.3 Roles . 30
F.4 Protocol . 30
Annex G (informative) Implementing digital credentials with ZKP . 32
G.1 Digital credentials . 32
G.2 The three-role model . 32
G.3 Issuance of digital credentials . 32
G.4 Unlinkability property between verifiers . 34
G.5 Presentation of digital proofs to a verifier . 34
G.6 Enforcement of collection limitation by a holder. 34
G.7 Verification of digital proofs by a verifier . 35
G.8 Suspension and revocation checking . 35
Bibliography . 37
Formatted: FooterPageRomanNumber
© ISO/IEC 2025 – All rights reserved
vi
ISO/IEC DISFDIS 27565.2:2025(en) Formatted: Font: 11 pt, Bold
Formatted: Font: 11 pt, Bold
Formatted: Font: 11 pt, Bold
Foreword
Formatted: Font: Bold
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical Formatted: HeaderCentered, Left
Commission) form the specialized system for worldwide standardization. National bodies that are members
of ISO or IEC participate in the development of International Standards through technical committees
established by the respective organization to deal with particular fields of technical activity. ISO and IEC
technical committees collaborate in fields of mutual interest. Other international organizations, governmental
and non-governmental, in liaison with ISO and IEC, also take part in the work.
The procedures used to develop this document and those intended for its further maintenance are described
in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the different types of
document should be noted. This document was drafted in accordance with the editorial rules of the ISO/IEC
Directives, Part 2 (see www.iso.org/directiveswww.iso.org/directives or
www.iec.ch/members_experts/refdocs).
Formatted: English (United Kingdom)
Field Code Changed
ISO and IEC draw attention to the possibility that the implementation of this document may involve the use of
(a) patent(s). ISO and IEC take no position concerning the evidence, validity or applicability of any claimed
patent rights in respect thereof. As of the date of publication of this document, ISO and IEC had not received
Formatted: Font color: Auto
notice of (a) patent(s) which may be required to implement this document. However, implementers are
cautioned that this may not represent the latest information, which may be obtained from the patent database
available at www.iso.org/patents and https://patents.iec.ch.www.iso.org/patents and https://patents.iec.ch.
ISO and IEC shall not be held responsible for identifying any or all such patent rights.
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and expressions
related to conformity assessment, as well as information about ISO's adherence to the World Trade
Organization (WTO) principles in the Technical Barriers to Trade (TBT) see
www.iso.org/iso/foreword.html.www.iso.org/iso/foreword.html. In the IEC, see www.iec.ch/understanding-
Formatted: English (United Kingdom)
standards.
Field Code Changed
This document was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology,
Subcommittee SC 27, Information security, cybersecurity and privacy protection.
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www.iso.org/members.html and www.iec.ch/national-
committeeswww.iso.org/members.html and www.iec.ch/national-committees.
Formatted: Adjust space between Latin and Asian text,
Adjust space between Asian text and numbers
Formatted: Font: 10 pt
Formatted: FooterCentered, Left, Space Before: 0 pt,
Tab stops: Not at 17.2 cm
Formatted: Font: 11 pt
Formatted: FooterPageRomanNumber, Left, Space
After: 0 pt, Tab stops: Not at 17.2 cm
© ISO/IEC 2025 – All rights reserved
vii
ISO/IEC FDIS 27565:2025(en)
Formatted: Font: Bold
Formatted: HeaderCentered
Introduction
The world is witnessing unprecedented data-driven innovation and growth in digital technologies that include
use of big data, AI and blockchain. These technologies are providing societal and economic benefits, as well as
improving efficiency, user experience and convenience. At the same time, there is a corresponding increase in
privacy risks that requires stronger privacy preserving measures to minimize such risks when designing and
Formatted: Font color: Auto
implementing solutions. Legislators are introducing new data privacy laws and regulations, and strengthening
existing ones, to make organizations accountable and compliant with data privacy protection requirements.
Formatted: Font color: Auto, English (United Kingdom)
They also require support for investigation and regulatory enforcement, where privacy protections are being
Formatted: Font color: Auto
misused to harm society.
A number of new technologies enable organizations to operate and do business in new ways that are compliant
with many regulations, while still protecting privacy. These privacy-enhancing technologies (PETs) apply data
protection principles intended to minimize the exposure and use of personal data.
Zero-knowledge proof (ZKP) technology is one such PET, which preserves privacy by eliminating the need to
expose or share personal information and personally identifying information (PII), while achieving its desired
function. ZKP is a privacy-enhancing technology that can be used to adhere to the principles of collection
limitation, user consent and choice and disclosure limitation as mentioned in ISO/IEC 29100:2024.
Formatted: Default Paragraph Font
Formatted: Default Paragraph Font
ZKP allows the validation of data held by an authoritative or an authentic source if it is known to both the
Formatted: Default Paragraph Font
prover and the verifier. This results in greater compliance with the data minimization principle of ISO/IEC
29100:2024, since only necessary data isare disclosed.
Formatted: Default Paragraph Font
Formatted: Default Paragraph Font
This document begins with an explanation of ZKP and its features. It then describes the privacy and functional
requirements that ZKP can address and provides guidelines for using ZKP in a way that is most useful for
privacy practitioners.
Formatted: FooterPageRomanNumber
© ISO/IEC 2025 – All rights reserved
viii
DRAFT International Standard ISO/IEC DIS 27565.2:2025(en)
Formatted: Left
Formatted: Main Title 1, Adjust space between Latin
Information security, cybersecurity and privacy protection —
and Asian text, Adjust space between Asian text and
Guidelines on privacy preservation based on zero-knowledge proofs
numbers
1 Scope
This document provides guidelines on using zero-knowledge proofs (ZKP) to improve privacy by reducing the
risks associated with the sharing or transmission of personal data between organizations and users by
minimizing unnecessary information disclosure. It includes several ZKP functional requirements relevant to
a range of different business use cases, then describes how different ZKP models can be used to meet those
functional requirements securely.
2 Normative references
There are no normative references in this document.
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
ISO and IEC maintain terminology databases for use in standardization at the following addresses:
Formatted: English (United Kingdom)
Formatted: Font: 11 pt, English (United Kingdom)
— — ISO Online browsing platform: available at https://www.iso.org/obphttps://www.iso.org/obp
Formatted: English (United Kingdom)
— — IEC Electropedia: available at https://www.electropedia.org/https://www.electropedia.org/
Formatted: English (United Kingdom)
3.1 3.1
Formatted: TermNum2, Adjust space between Latin
application
and Asian text, Adjust space between Asian text and
software component that issues commands and receives responses to the commands within a system
numbers
[SOURCE: ISO/IEC 15961-1:2021, 3.1.1]
Formatted: Default Paragraph Font
Formatted: Default Paragraph Font
3.2 3.2
Formatted: Default Paragraph Font
application attestation
confirmation to a server that it is communicating with an instance of its genuine application (3.1)(3.1) that
Formatted: Default Paragraph Font
has specific characteristics and is running in a trusted environment
Formatted: Default Paragraph Font
3.3 3.3
Formatted: Adjust space between Latin and Asian text,
attribute
Adjust space between Asian text and numbers, Tab
characteristic or property of an entity stops: Not at 0.7 cm + 1.4 cm + 2.1 cm + 2.8 cm +
3.5 cm + 4.2 cm + 4.9 cm + 5.6 cm + 6.3 cm + 7 cm
EXAMPLE An entity type, address information, telephone number, a privilege, a MAC address, a domain name are
Formatted: Default Paragraph Font
possible attributes.
Formatted: Default Paragraph Font
[SOURCE: ISO/IEC 24760-1:—, :2025, 3.1.3 ]
Formatted: Default Paragraph Font
Formatted: Adjust space between Latin and Asian text,
Adjust space between Asian text and numbers
Formatted: Font: Not Bold
Formatted: Footer, Left, Space After: 0 pt, Tab stops:
Under preparation. Stage at the time of publication: ISO/IEC FDIS 24760-1:2025.
Not at 17.2 cm
© ISO/IEC 2025 – All rights reserved
ISO/IEC FDIS 27565:2025(en)
Formatted: Font: Bold
Formatted: HeaderCentered
3.4 3.4
attribute provider
authority trusted by one or more users and one or more relying parties to issue or verify attributes (3.3)(3.3)
related to an entity
[SOURCE: ISO/IEC 27551:2021, 3.2]
Formatted: Default Paragraph Font
Formatted: Default Paragraph Font
3.5 3.5
Formatted: Default Paragraph Font
authoritative document
document known to be reliable because its authority or authenticity is widely recognized or it bears a
Formatted: Default Paragraph Font
signature or seal attesting its validity
3.6 3.6
completeness
property where a trusted verifier can be convinced by a trusted prover that a statement is true with
overwhelming probability
3.7 3.7
computed attribute
attribute (3.3)(3.3) that is computed from one or more attributes and public information
3.8 3.8
digital credential
set of identity attributes and associated data about an individual, cryptographically signed in advance by a
credential issuer which includes key information that allows to demonstrate the possession of it
3.9 3.9
digital credential issuer
authoritative source that registers subscribers and subsequently issues digital credentials to its subscribers
Formatted: Default Paragraph Font
3.10 3.10
Formatted: Default Paragraph Font
digital wallet
application (3.1)(3.1) that stores and manages digital credentials and keys and can use them upon request Formatted: Default Paragraph Font
Formatted: Default Paragraph Font
3.11 3.11
Formatted: Default Paragraph Font
domain
environment where an entity can use a set of attributes (3.3)(3.3) for identification and other purposes
Formatted: Default Paragraph Font
Formatted: Default Paragraph Font
[SOURCE: ISO/IEC 24760-1:—,:2025, 3.2.3, modified — notes to entry and example have been removed.]
Formatted: Default Paragraph Font
3.12 3.12
Formatted: Default Paragraph Font
distinguishing identifier
Formatted: Default Paragraph Font
information which unambiguously distinguishes an entity within a given context
Formatted: Default Paragraph Font
[SOURCE: ISO/IEC 11770-7:2021, 3.5, modified —"—“within a given context"” has been added.]
Formatted: Default Paragraph Font
Formatted: Default Paragraph Font
3.13 3.13
identifying attribute
Formatted: Default Paragraph Font
attribute (3.2)attribute (3.2) that contributes to uniquely identifying a subject within a context
Formatted: Default Paragraph Font
[SOURCE: ISO/IEC TS 29003:2018, 3.8] Formatted: Font: 10 pt
Formatted: Font: 10 pt
3.14 3.14
Formatted: Font: 11 pt
linkability
property for a dataset that it is possible to associate (by linking) a record concerning a data principal with a
Formatted: FooterPageNumber, Space After: 0 pt, Line
record concerning the same data principal in a separate dataset
spacing: single
2 © ISO #### /IEC 2025 – All rights reserved
ISO/IEC DISFDIS 27565.2:2025(en) Formatted: Font: 11 pt, Bold
Formatted: Font: 11 pt, Bold
Formatted: Font: 11 pt, Bold
[SOURCE: ISO/IEC 20889:2018, 3.20]
Formatted: Font: Bold
3.15 3.15
Formatted: HeaderCentered, Left
online
Formatted: Default Paragraph Font
normal state of the data link layer where both application and network management communication are
Formatted: Default Paragraph Font
possible
Formatted: Default Paragraph Font
[SOURCE: ISO 17356-1:2005, 2.80]
Formatted: Default Paragraph Font
3.16 3.19
Formatted: Default Paragraph Font
personal data
Formatted: Default Paragraph Font
information relating to an identified or identifiable natural person
Formatted: Default Paragraph Font
[SOURCE: ISO/TS 17573-2:2020, 3.136]
Formatted: Default Paragraph Font
Formatted: Default Paragraph Font
3.17 3.20
proof verification Formatted: Default Paragraph Font
process where a verifier checks that a proof is valid
Formatted: Default Paragraph Font
Formatted: Default Paragraph Font
Note 1 to entry: Checks can include the cryptography and digital signature.
Formatted: Default Paragraph Font
3.18 3.21
Formatted: Default Paragraph Font
prover
entity that presents a proof to a verifier Formatted: Default Paragraph Font
Formatted: Adjust space between Latin and Asian text,
Note 1 to entry: The prover may be an authoritative source or a trusted intermediary.
Adjust space between Asian text and numbers, Tab
stops: Not at 0.7 cm + 1.4 cm + 2.1 cm + 2.8 cm +
3.19 3.22
3.5 cm + 4.2 cm + 4.9 cm + 5.6 cm + 6.3 cm + 7 cm
public coin interactive zero-knowledge proof
Formatted: TermNum2, Adjust space between Latin
public coin interactive ZKP
and Asian text, Adjust space between Asian text and
interactive zero-knowledge proof (ZKP) (3.32)(3.26) where the verifier’s messages are uniformly random and
numbers
independent of the prover’s messages
Formatted: Adjust space between Latin and Asian text,
3.20 3.23 Adjust space between Asian text and numbers, Tab
stops: Not at 0.7 cm + 1.4 cm + 2.1 cm + 2.8 cm +
record
3.5 cm + 4.2 cm + 4.9 cm + 5.6 cm + 6.3 cm + 7 cm
set of attributes concerning a single data principal
Formatted: TermNum2, Adjust space between Latin
3.21 3.24
and Asian text, Adjust space between Asian text and
soundness
numbers
property where a malicious prover, if the statement is false, has only a negligible chance in convincing a
verifier that the statement is true
3.22 3.27
Formatted: English (United Kingdom)
subject binding
property that assures that a claim is associated with the correct natural person
Formatted: Default Paragraph Font
Formatted: Default Paragraph Font
3.23 3.28
trusted execution environment Formatted: Default Paragraph Font
TEE
Formatted: Default Paragraph Font
aspect of the mobile device comprising either hardware or software, or both, which provides security services
Formatted: Default Paragraph Font
to the mobile device computing environment, protects data against general software attacks and isolates
hardware and software security resources from the operating system
Formatted: Font: 10 pt
Formatted
...
[SOURCE: ISO 12812-1:2017, 3.60]
Formatted: Font: 11 pt
Formatted
...
© ISO/IEC 2025 – All rights reserved
Formatted
...
Formatted
...
ISO/IEC FDIS 27565:2025(en)
Formatted
...
Formatted
...
Formatted
...
3.24 3.29
unlinkability Formatted
...
property that ensures that an individual may make multiple uses of resources or services without others being
Formatted
...
able to link these uses together
Formatted
...
Note 1 to entry: There is a distinction between the following two cases: (i) multiple uses of the same services, and (ii)
Formatted Table
...
Thethe uses of multiple different services.
Formatted
...
[SOURCE: ISO/IEC TR 27550:2019, 3.25, modified — note 1 to entry has been added.]
Formatted
...
Formatted
...
3.25 3.30
Formatted
verifier
...
entity relying on a verified proof to prove that a statement is true
Formatted
...
Formatted
...
Note 1 to entry: The verifier is often the relying party seeking proof that a claimed attribute or statement made by an
individual is true.
Formatted
...
Formatted
...
3.26 3.32
Formatted
zero-knowledge proof
...
ZKP
Formatted
...
method involving one or more exchanges between a prover and a verifier where the prover is able to convince
Formatted
...
the verifier that a statement is true, without revealing to the verifier any additional information beyond that
knowledge Formatted
...
Formatted
...
3.27 3.33
Formatted
zero-knowledge proof functional requirement .
ZKP functional requirement
Formatted
...
functional requirements of a system to be fulfilled using zero-knowledge proof (ZKP) (3.32)(3.26)
Formatted
...
Formatted
4 Abbreviated terms .
Formatted
...
anti-money laundering AML
Formatted
...
central bank digital currency CBDC
Formatted
...
certification revocation list CRL
Formatted
...
Formatted
common reference string CRS
...
Formatted
counter terrorist financing CTF .
Formatted
...
distributed ledger technology DLT
Formatted
...
multi-party computation MPC
Formatted
...
national institute of standards and technology NIST
Formatted
...
non-interactive zero-knowledge proof NIZKP
Formatted
...
online certificate status protocol OCSP
Formatted
...
personally identifiable information PII
Formatted
...
public key certificate PKC
Formatted
...
trusted third party TTP
Formatted
...
Formatted
...
Formatted
...
Formatted
...
Formatted
...
Formatted
...
4 © ISO #### /IEC 2025 – All rights reserved
ISO/IEC DISFDIS 27565.2:2025(en) Formatted: Font: 11 pt, Bold
Formatted: Font: 11 pt, Bold
Formatted: Font: 11 pt, Bold
5 Introduction to Zerozero-knowledge Proofsproofs
Formatted: Font: Bold
5.1 General
Formatted: HeaderCentered, Left
Formatted: Space Before: 12 pt, Adjust space between
In the digital world, not collecting or exposing personal information is the best possible way to preserve the
Latin and Asian text, Adjust space between Asian text
privacy of an individual. However, this is not always practically possible due to the need to use or validate
and numbers
personal information for various business and legal purposes during the course of a business process or the
Formatted: Adjust space between Latin and Asian text,
provision of a public service. For instance, it can be necessary for individuals to validate a claimed bank
...












Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.
Loading comments...