ISO/IEC DIS 27565.2:2025(en)

ISO/IEC JTC 1/SC 27

Secretariat: DIN

Date: 2025-04-10

Information security, cybersecurity 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 pour la préservap to htion de la vie privée basées sur des preuves à divulgationu nulle de connaissance

© ISO/IEC 2025

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

Contents

Foreword 6

Introduction 7

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 8

Figure 2 — Prover module 9

5.3.4 Verifier module 9

Figure 3 — Verifier module 9

5.4 Characteristics of ZKPs 9

5.5 ZKP performance 10

6 Requirements of implementing ZKPs for attribute verification 10

6.1 Attribute providers 10

6.2 Subject binding 11

6.3 Replay attack detection or protection 12

6.4 Prevention of collusions between users 12

6.5 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 of attributes 14

7.4.1 General 14

7.4.2 Pre-generation of digital credentials 15

7.4.3 On-demand generation of digital credentials 15

8 Privacy Preservation using Zero Knowledge Proofs 16

8.1 Privacy Principles in the context of ZKP 16

8.2 Privacy Risk Assessment 16

8.3 Privacy Functional Requirements for ZKP 17

8.3.1 General 17

8.3.2 Collection limitation 17

8.3.3 Data minimization 17

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 18

8.3.11 Openness, transparency and notice 18

8.3.12 Individual participation and access 18

8.3.13 Accountability 18

8.3.14 Information security 18

8.3.15 Unlinkability 18

8.4 Security Considerations 18

8.4.1 Alice and Bob collusion attack 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 20

10 Business Use Examples 20

10.1 Age Verification 20

10.2 Fraud Prevention 21

10.3 Auction 21

10.4 Disability Proof 21

10.5 Distributed Ledger Technologies (DLT) and blockchains 21

10.6 Central Bank Digital Currencies (CBDCs) 21

Annex A (informative) Factors facilitating or hindering ZKP developments 23

A.1 Factors facilitating ZKP developments 23

A.2 Factors hindering ZKP developments 23

A.3 Post-quantum resistance 23

Annex B (informative) Example of a consistency check between two documents 24

B.1 General 24

B.2 Document structure 24

B.3 Roles 24

B.4 Protocol 24

Annex C (informative) Example of selective disclosure 26

C.1 General 26

C.2 Database structure 26

C.3 Roles 26

C.4 Protocol 26

Annex D (informative) Example of secure comparison of two numbers 28

Annex E (informative) ZKP usage example using digital credentials 30

E.1 Digital credentials 30

E.2 The three roles model 30

E.3 Issuance of digital credentials 30

E.4 Unlinkability property between Verifiers 32

E.5 Presentation of digital proofs to a Verifier 32

E.6 Enforcement of collection limitation by a Holder 32

E.7 Verification of digital proofs by a Verifier 33

E.8 Suspension and revocation checking 33

Bibliography 35

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 Technical Committee ISO/TC JTC1, 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.

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 organisations accountable and compliant regarding data privacy protection., They also require support for investigation and regulatory enforcement, where privacy protections are being misused to harm society.

A number of new technologies enable organisations 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 the desired function. ZKP is a privacy enhancing technology, and 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^[24].

This technology also allows the validation of data held by an authoritative or an authentic source of the data if it is known to both the prover and the verifier. This results in greater compliance to the data minimization principle of ISO/IEC 29100:2024,^[14] since only necessary data is disclosed.

This document begins with an explanation of ZKP and its features. The privacy and functional requirements that ZKP can address are then described, followed by guidelines for using ZKP in a way that is most useful for privacy practitioners.

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 organisations 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.

There are no normative references in this document.

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:—,^[1] 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]

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 that stores and manages digital credentials and keys and can use them upon request

Note 1 to entry: An application is a software component that can be installed and run on some hardware, like a smartphone, a tablet, or other electronic device.

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 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]

3.19

personal data

information relating to an identified or identifiable natural person

[SOURCE: ISO/TS 17573-2:2020, 3.136]

3.20

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.21

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.22

public coin interactive ZKP protocol

interactive ZKP protocol where the verifier’s messages are uniformly random and independent of the prover’s messages

3.23

record

set of attributes concerning a single data principal

3.24

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.27

subject binding

property that assures that a claim is associated with the correct natural person

3.28

trusted execution environment

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.29

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.30

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.

3.32

zero-knowledge proof

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.33

zero-knowledge proof functional requirement

functional requirements of the system to be fulfilled using zero-knowledge proof

Note 1 to entry: This term does not refer to the functional requirements of zero-knowledge proof."

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 collection of personal information using ZKP techniques since the knowledge of some property about it can be sufficient. Instead of sharing confidential personal information in order 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. The personal information is not revealed to the verifier, only the proof is communicated, thereby eliminating the potential harm that can be caused by exposing the personal information.

When making a PII-based decision, personal information (attributes) shall 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 shall support the following three properties:

a) completeness: if the prover's statement is true, then the verifier will accept it with overwhelming probability;

b) soundness: if the prover's statement is false, then no matter how the prover behaves, the verifier will reject 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.

For more details on ZKP, see Reference [2].

In addition to the three well-known properties applicable to ZKP protocols, a non-interactive zero-knowledge proof (NIZKP) protocol should support 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.

ZKP can be divided into two categories: (a) interactive ZKP and (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, the verifier may not be online when the proof was produced.

To establish such proofs, both the verifier and the prover shall be online at same time. In order to prove the same statement again to another verifier, the prover shall interact with another verifier again.

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 ,

2) During the challenge phase, a second message (fresh random value) is sent from the verifier to the prover that contains a challenge , and

3) During the response phase, a final message 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 is true or false based on the values of .

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.

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.

In the case of the public coin, the challenge message does not take place but is simulated using pseudo-random values that are not generated by the verifier but by other approaches. Three different approaches that meet this property are specified in 5.2.3.2 to 5.2.3.4 .

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 is true. The prover generates the first message, . Then, it hashes and computes the correct response, for the challenge . It then sends as proof. To validate the proof, the verifier executes the hash function on to calculate and verifies that 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, , 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^[26], ISO/IEC 10118-2^[27], ISO/IEC 10118-3^[28], and ISO/IEC 10118-4^[29] for more details on cryptographic hash function.

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. In the USA, the public utility is supported by the NIST^[30].

Using a structured Common Reference String

The Common Reference String (CRS) can be used to embed the challenges that the prover shall 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 shall be generated by a trusted source.

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.

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 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 See ISO/IEC 4922-1^[12] and ISO/IEC 4922-2^[13] for more details on MPC.

Figure 1 — Setup module

There are several variations of the setup and the level of trust placed in it, including the following:

NOTE 1 See ISO/IEC 9798‑5 for more details.

a) No setup or trustless setup: This is when no trust is required, 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, or whether full trust is required.

4) 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.

5) 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.

6) Updatable CRS: In some ZKP systems, the CRS can be updated after its initial setup. Updating a CRS will nullify the trapdoor associated with the old CRS, which makes the system more trustworthy.

NOTE 2 Auditors can be either authorities or any renowned trusted third-party.

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, private information can be input to those entities either in the clear form or in the protected form, such as secret sharing.

See ISO/IEC 4922-1^[12] and ISO/IEC 4922-2^[13] for more details on MPC.

Figure 2 — Prover 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.

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.

See ISO/IEC 4922-1 and ISO/IEC 4922-2 for more details on MPC.

Figure 3 — Verifier module

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 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.

Key considerations for ZKP Performance are listed as follows:

1) 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.

2) Size of the messages exchanged: Size of the messages could also be several Kilobytes long.

3) 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 may 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.

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 from them, for example by computing the age of a person by making a subtraction between the current date and the date of birth of the person.

An attribute provider, who is a trusted third party (TTP), is trusted both by the prover and the verifier to hold attributes that have been previously verified. Most often, verifiers will know an identifier and a public key that is associated with the attribute providers that they trust. Such information is usually provided in the form of a public key certificate (PKC). This is an example of common knowledge.

A ZKP may be constructed by a user when using a digital credential issued by an attribute provider. From that attestation, a prover can derive statements containing information that follows some construction rules about the content of the attestation. The verifier can then verify the statements derived from the attestation.

Typically supported properties are:

a) to prove that some attributes have been signed by an attribute provider and to reveal only a subset of them;

b) to prove that some attributes have been signed by an attribute provider, to reveal only a subset of them and to demonstrate that one hidden attribute is within some range;

c) to prove that some attributes have been signed by an attribute provider, to reveal only a subset of them and to demonstrate that the sum of some hidden attributes is within some range.

In the case of proving a complex statement, one solution is to decompose the statement into some elementary statements and to compute in parallel multiple independent proofs on each elementary statement, using a single challenge that simulates the behaviour of the verifier.

To associate a statement with the right individual, either a user identifier or one or more identifying attributes that relate to the individual shall be included into the common knowledge statement. The user identifier or the identifying attribute(s) should be sufficient, within a given context, to uniquely relate to the user. Such information is called a distinguishing identifier.

The attribute provider shall verify that the value placed in either the user identifier or in one or more identifying attributes, or both, corresponds to attributes that belong to the correct user.

A user identifier may be one or more of the following:

a) a globally unique user identifier,

b) a locally unique user identifier used to identify a user by whatever verifier is being involved,

c) a unique user identifier used to identify a user for each attribute providers/verifier pair,

d) a unique user identifier used to identify a user for each user/ verifier pair, or

e) a temporary user identifier.

In the following, more explanations are provided for each type of identifier:

f) Globally unique user identifier

Several verifiers (not necessarily receiving a proof) can establish a link between their users’ accounts by using this single identifying attribute.

g) Locally unique user identifier

Several verifiers (receiving a proof from the same Attribute provider) may be able to establish a link between their users’ accounts by using this single identifying attribute.

h) User identifier unique for each Attribute server / Server application pair

To be able to generate such an identifying attribute, the client application of the user needs to disclose the identity or an identifier of the verifier to the attribute provider.

As a consequence, the attribute provider might learn some information about the context of the proofs to be issued. This can be a privacy concern for individuals.

However, this case offers a benefit: several verifiers (necessarily receiving a proof from the same attribute provider) will be unable to establish a link between their user accounts by using this single identifying attribute.

i) Unique user identifier for each user/server application pair

Several verifiers (receiving a proof from the same attribute provider) will be unable to establish a link between their users’ accounts by using this single identifying attribute.

j) Temporary unique user identifier

Several verifiers (receiving a proof from different attribute providers) will be unable to establish a link between their user accounts by using this single identifying attribute.

The user should be able to choose which types of user identifiers or identifying attributes should be included into the statement because such choice can affect their privacy.

Using an interactive ZKP allows protection against a ZKP replay attack against any verifier. In this way, the verifier can be confident about the timeliness of the ZKP.

When using a non-interactive ZKP, in order to detect a replay attack against the same verifier, it is necessary to include an element in the computation of the ZKP that allows the verifier to verify the timeliness of the ZKP. This is usually done by incorporating a nonce composed of the time of the day and of a random number into the computation of the ZKP.

When using a non-interactive ZKP, in order to prevent the replay attack against another verifier, it is necessary to include an identifier of the verifier in the ZKP, which allows the ZKP to be verified by the intended verifier.

A proof should be associated with the right individual. Collusions between users shall be considered and prevented.

A user who has legitimately either received a digital credential from an attribute issuer or constructed a proof using information issued by an attribute issuer that ascertains the correctness of a statement can attempt to collaborate with another user to fool a verifier to make it believe that the other user can get the benefits of that proof.

If the link between the statement and the individual association is done using the "identity of the person", i.e. a set of attributes that uniquely identify that person, then the proof can be disclosing more attributes than necessary. While such a link would be secure, it would not preserve the privacy of the user. Furthermore, it can allow several verifiers to link their user accounts. The selection by the user of one or more appropriate identifying attributes known or verifiable by the attribute issuer can solve this concern.

In order to be able to verify the authenticity of the statement, the statement shall be built using an authoritative document signed by a trusted authority or by any authority among a set of trusted authorities. The verifier shall be able to verify the signature of that authority.

In some cases, it is desirable to demonstrate that the value of a hidden attribute has a property such as being within a range of values or belonging to a set of discrete values. Such cases are typical use case of ZKPs.

NOTE This use case is an example that corresponds to the case where digital credentials are called Verifiable Credentials (VCs) and where a VC can contain a Decentralized IDentifier (DID). The VC is issued by an Issuer and then made available to the prover. For more details, see Reference [3].

Depending upon the property that the verifier would like to be aware of, the prover creates a verifiable presentation using both the VC and a composite ZKP protocol.

As illustrated in Figure 4, the ZKP is provided using an online exchange between the prover and the verifier.

Figure 4 — ZKP of a property relative to a hidden attribute

ZKP is particularly useful to prove some properties or characteristics contained in an authoritative document.

Claiming to be over 18 does not prove the date of birth of the individual. Instead, it is more useful over the Internet if the individual states that they know the details of a signed document issued by a trusted issuer (e.g. a government or a bank) that is within its validity period, which contains their date of birth and which is linked by that issuer to one of their identifiers that are meaningful for the verifier to which the ZKP will be presented where their age, computed using the difference between the current date and my birth date, is greater than 18.

Such an example can be described as a set of composite statements where for each statement a different proof mechanism can be used and where its design can be efficiency-optimized for a specific task.

The example of claiming to be over 18 highlights three major characteristics:

a) the ZKP is based on the content of a valid formatted document bearing a signature or a seal attesting its origin and that it is authoritative,

b) the ZKP is linked by the issuer to a distinguishing identifier meaningful for the verifier that will allow the verifier to identify unambiguously one of its users (in order to address collusion attack detection, see 9.1).

c) the ZKP allows the prover to demonstrate that the value of an attribute contained in the formatted document is greater or lower than a value, or lies within an interval or belongs to a set of elements.

It may also be desirable to hide the identity of the issuer of the authoritative document. From the verifier point of view, it may be sufficient to know that the proof is coming from a trusted source among a set of trusted sources without knowing the identity of the source.

For example, it may be sufficient to know that the information is coming from one bank among a set of banks without knowing from which bank it is amongst that set. This can be achieved by using group signatures or ring signatures. In cryptographic terms, these mechanisms allow entities to sign anonymously inside of a group.

NOTE See ISO/IEC 20008-2^[31] for more details on group signatures and ISO/IEC 20008-3^[32] for more details on ring signatures.

Before starting the execution of the protocol, several conditions shall be met, in particular:

d) the data structure of the authoritative document shall be disclosed by the prover to the verifier and accepted by the verifier so that it is possible to know which field contains the date of birth and to know the format,

e) the set of composite statements shall be disclosed by the prover to the verifier and accepted by the verifier,

f) if a ZKP protocol used in one or more statements is using a CRS, that CRS shall be agreed between the prover and the verifier.

ZKP is also useful to prove some properties or characteristics contained in two or more authoritative documents issued by different issuers.

For example, a document such as a driving licence can attest that the individual is over 18, while another document can attest that the individual is a student at a particular .

A verifier may wish to make sure that the individual is over 18 and is also a student at any university.

The main problem to be solved is demonstrating that these two properties belong to the same individual, even in the case of a collusion between users (See 9.1); that is these two properties are linked.

The use of linked properties allows a holder's application to demonstrate to a verifier that the credentials issued by a different digital credential issuer were indeed issued to the same holder (see Annex E).

Individuals may be provided with various digital credentials, e.g. issued by governmental agencies, social security agencies, insurance companies, banks, schools or universities, that often contain more information than necessary and should not be disclosed to a verifier.

Since the privacy principle of "collection limitation" applies (see ISO/IEC 29100:2024^[14]), a verifier should not collect more than necessary information about an individual to perform a given operation.

In such a case, the server first indicates which attributes are required, from which issuer(s) and for which processing purposes. Upon requested by a user, a legitimate holder of a digital credential only discloses the required subset of attributes to the online server.

Selective disclosure enables collection limitation. This may be realized using ZKPs but this not always necessary. See Annex C for an example of ZKP for selective disclosure.

The following description explains how to support selective disclosure without using ZKPs. Two different approaches may be used:

a) the issuer generates a single attestation and the tasks of the prover are to use it and generate a statement hiding one or more attributes that were present in the attestation, or

b) the issuer generates several digital credentials that contain only a subset of his attributes so that the prover may select which one(s) to use and in order to generate several statements for the verifier.

A single attestation contains several attributes and it is possible to hide some of them. Some simple (non-ZKP) techniques can be used in a similar way to salt each attribute and including in the attestation a hash of both the salt and the attribute. In this way, the holder may reveal some of the salted attributes.

Otherwise, instead of issuing a single digital credential, an issuer can prepare a set of digital credentials containing some useful groupings of attributes. In this way, the holder can choose the relevant digital credential and create a statement of knowledge out of it.

It is important that the user should be able to choose which type of distinguishing identifier will be included into the statement because such choice will affect his privacy.

The issuer may pre-generate digital credentials that include a distinguishing identifier (e.g. first name, second name, family name) and either:

— a globally unique user identifier, or

— a locally unique user identifier, or

— no user identifier at all,

or may generate on demand a digital credential that includes either:

— a user identifier unique for each issuer/server pair, or

— a unique user identifier for each user /server pair.

These considerations lead to the two following cases:

— pre-generation of digital credentials, and

— on-demand generation of digital credentials.

This case is an example that corresponds to a use case where digital credentials are called Verifiable Credentials (VCs), which can contain a Decentralized IDentifier (DID).

NOTE For more details, see: Verifiable Credentials Data Model v2.0.^[3] There are alternative digital credential formats, such as SD-JWT^[10] and the SD-CWT^[11] which do not support ZKP, yet they offer selective disclosure of attributes. For more details, see Annex E.

Although a DID is unique for a given issuer/subject pair, it does not necessarily identify the legitimate owner of the VC and is thus subject to the ABC (Alice and Bob collusion) attack (see 7.5.1 for details). This can be addressed by using a Verifiable Presentation (VP) (that serves as an envelope for VCs), which contains a set of identifying attributes, including the above VC. It allows, in the context on the verifier, to unambiguously identify the user.

It is necessary to include a set of attributes that will not be hidden when creating a Verifiable Presentation (VP) and that will likely be recognized either by one online server or a set of online servers.

In some cases, it can be desirable to allow a set of online servers to link their user accounts for a specific user (e.g. when they belong to the same domain). Two scenarios are given in the following.

a) If such an identifier is a globally unique identifier (e.g. an email address), all the servers (not necessarily receiving a statement) will have the knowledge of that globally unique identifier and will be able to link the user accounts on the servers for that specific user.

b) If such identifier is a locally unique identifier (e.g. a student number), all the servers receiving a statement built from a digital credential issued by the same issuer will be able to establish a link between the relevant user accounts.

On-demand generation of digital credentials rresponds to use cases where it is not desirable to allow a set of verifiers to link the provers. It is thus necessary to prevent a set of verifiers from linking the provers by using a single identifier. Two scenarios are given in the following.

a) If such an identifier is an identifier unique for each issuer / server pair, the issuer shall know the identifier of the server and consequently, the issuer may be able to act as "Big Brother" since it will know the identifiers of the verifiers where the statement will be presented. However, several servers receiving a statement built from a digital credential produced by the same issuer will be unable to establish a link between the provers by using this single identifier.

NOTE 1 In this case, if no additional identifying attribute is present, the statement may be used by an illegitimate prover in the context of a prover collusion attack.

b) If such an identifier is an identifier unique for each prover/verifier pair, a Verifier receiving a statement built from a digital credential produced by any issuer will be able to establish a link with a prover by using this single identifier.

NOTE 2 In this case, the statement cannot be used by an illegitimate user in the context of a prover collusion attack. An additional advantage is that it allows a binding of statements to be established, built from different digital credentials produced by different issuers that apply to the same individual. However, such a technique requires every prover to be able to demonstrate to every issuer that they are really using that identifier on that verifier.

Unlinkability in the context of zero knowledge proof means that any verifier should not be able to know the other verifiers to which the same individual presented a digital proof. The risks associated with the sharing or transmission of personal data between organisations when the same individual transacts with multiple organizations pertain to the unlinkability property.

The risks associated with minimising information disclosure are related to collection limitation and to data minimization as defined in ISO/IEC 29100:2024^[14].

A risk assessment according to ISO 31000 and a Privacy Impact Assessment (PIA) according to ISO/IEC 29134 should be conducted to determine how to use ZKP for a specific use case.

When platforms and solutions are developed, absence of knowledge and availability of privacy preserving techniques lets designers introduce data processing steps that are completely unwanted. Designers often collect and store information with the intent of meeting potential future needs of data even when such needs are non-existent or disproportionate, and more so because digital storage media is becoming inexpensive with time. It is a privacy engineer’s role to envisage risks and build solutions that help to deliver the intended service effectively while preserving privacy. The privacy impact assessment shall consider all potential privacy threats associated with the use case and the context. Threats that are minimized or eliminated by use of ZKP include the following:

a) Collection of Identity information, when such identity is desirable but not essential in delivering the service, e.g., when an ID card is used to verify age

b) Knowledge of personal information about the individual that is not needed but can have adverse consequences, e.g., when a passport is checked to ascertain eligibility to travel, an individual’s address and country that issued a visa is also known. Likewise, a participant’s bid information is known in an auction;

c) Purpose limitation is achieved by eliminating the need to know detailed information. E.g, availability of information not needed for authenticating a person’s age being above threshold, does not require exact age to be known, the knowledge of which can lead to newer use cases that can violate legal requirements or other applicable privacy regulation.

d) Linkability and consequent misuse of personal data, e.g., when identity is known along with travel history;

e) Risk of data leakage or unauthorised access is eliminated by not collecting information or capturing only minimal information.

The mechanism of "Selective disclosure" is used by an individual that allows them to disclose to a verifier the minimum information that he agrees to be necessary to perform a given action. It is possible to avoid the collection of personal information, since the knowledge of some property about it can be sufficient. Instead of sharing the personal information, while using ZKP, it is possible to convince a verifier that a certain statement or a set of statements about personal information is true. The personal information is not revealed to the verifier, only a digital proof is communicated, thereby eliminating the potential harm that can be caused by exposing the personal information. Thus, a prover can prove to a verifier that some relevant attributes satisfy certain criteria in a privacy-preserving manner.

However, this is insufficient since those criteria also shall be associated with the correct individual in a privacy-preserving manner. The risks associated with the sharing or transmission of personal data between individuals are related to the support of "attribute to individual binding" property, which is elaborated in 7.2.

ZKP functional requirements means the functional requirements of the system to be fulfilled using ZKP in the context. Once a risk assessment is carried out, it is important to derive various functional requirements that get implemented using ZKP. Clauses 8.3.2 – 8.3.15 identify several privacy functional requirements that can have relevancy to some use-cases. This list should not be considered as being exhaustive.

The Verifier should limit the collection of statements to that which is and strictly necessary to allow the operation that the user is willing to perform on the resource.

The Verifier should not process more information than necessary. If the verifier is willing to perform some additional processing or to communicate to another party some information derived from that processing, the verifier should first seek the consent of the individual.

The verifier can propose one or more options to a user. Before making a choice, the user should be able to obtain information from the verifier about his rights and explanations about the implications of each option. When a single option is proposed, the user should be able to refuse to choose it.

The user should be able to choose which types of attributes should be included into the statement.

The Verifier should only request the production of statements that are necessary to perform the transaction requested by the user. The verifier shall verify that the purpose(s) for which the statements are collected and stored complies with applicable law and relies on a permissible legal basis.

The Verifier should not be able to identify the authority that has issued the attestation. It should only be able to know that this issuer of the proof is a member of a set of trusted authorities.

The attribute issuer should not be able to know to which verifier the attestation it generates is intended.

The verifier should retain the statements that have been successfully verified only as long as necessary to fulfil the stated purposes, and thereafter securely destroying or anonymizing it.

The verifier should establish control mechanisms to periodically check the accuracy and quality of collected and stored statements.

The verifier should provide the users with clear and easily accessible information about its policies with respect to the processing of the statements and provide appropriate notices about the purpose of the collection of these statements.

An attribute issuer should give to their users the ability to access and review their attributes, provided their identity is first authenticated with an appropriate level of assurance.

The verifier should assign to a specified individual within the organization the task of implementing the privacy-related policies, procedures and practices. When transferring statements to a third parties, the verifier should ensure that the third-party recipient will be bound to provide an equivalent level of privacy protection through contracts or other means. The verifier should also demonstrate that the processing meets data protection and privacy safeguarding requirements by periodically conducting audits using internal auditors or trusted third-party auditors.

The verifier should protect the stored statements to ensure their integrity, confidentiality and availability and protect them against risks such as unauthorized access, destruction, use, modification, disclosure or loss throughout the whole of their life cycle.

A verifier that receives a proof shall not be able to link that proof with another proof received by another verifier, unless the proof is about a statement about multiple attributes able to uniquely identify the individual.

As stated 6.5.1 and 6.5.2, a verifier shall be able to detect collusion attacks between users. The EXAMPLE below illustrates how such an attack can be performed.

EXAMPLE Alice who is 12 would like to connect to a server selling goods or services restricted to individuals over 18 and obtain some services or goods from that server.

She contacts her uncle Bob, who is 25, and asks him whether he would collaborate with her to demonstrate that she is over 18. Let us suppose that Bob accepts.

Alice first creates her own user account on the server under a pseudonym.

Suppose there is software in the public domain that facilitates a redirection of a verifier’s challenge and prover’s proof. This software running on Alice’s laptop, which redirects the ZKP protocol to communicate with Bob’s laptop. The two laptops can communicate using a WAN network. Bob is in Paris while Alice is in San Francisco.

Once Alice has created her own user account, she asks for goods or services. The server asks the user to demonstrate that she (or he) is over 18. Alice forwards information received from the server to Bob using the specific piece of software. Bob receives that information and delivers to his niece a ZKP demonstrating that the holder of the ZKP is over 18. Alice then presents it to the server, which verifies and accepts it.

Since Alice has been able to demonstrate once to that server that she is over 18, the server can remember this characteristic and, in the future, she may not demonstrate it again. She will keep the advantages associated with this characteristic on her user account on that server.

Now, Alice can access to services or to buy goods restricted to persons over 18 at any time she wishes without the need to ask for another collusion with Bob. In addition, Bob will be kept ignorant of the services accessed by Alice or of the goods bought by Alice on that server.

Whatever kind of cryptographic ZKP is being used, when two users collude in this way, no software-only solution can prevent the transfer of a ZKP of a user that possesses it to another user that does not possess it.

The use of a trusted secure element (or a TEE) alone to protect the confidentiality and the integrity of secret or private keys, while useful, will be insufficient to counter the Alice and Bob collusion attack. Additional properties are required for the secure element (or the TEE) to defeat this attack.

NOTE This attack is not specific to ZKP and is also applicable to other technologies, e.g. when using access tokens issued by an Attribute Provider.

There are several fundamental functional use cases, including but not limited to:

a) Proving that two parties hold the same data attribute or set of attributes or any other formatted data object. See Annex B for an example of a consistency check between two documents;

b) User or device authentication either by validation of a shared secret or proving possession of a password;

c) Validating claimed data against an authoritative source;

d) Proving that a rule is satisfied sufficient for policy compliance;

e) Proving that the results of a calculation or algorithm or Boolean/logical expression are compliant or the same between two or more organisations;

f) Speeding up the verification process of multiple verifying tasks in a batch, e.g., verifying multiple signatures.

Wherever the data is personal data or PII, privacy is preserved.

Some common knowledge needs to be established between the prover and the verifier before executing a ZKP so that the correct record in the prover and the verifier can be compared. For instance, the statement is associated with the right individual; there exists trusted third parties that know many attributes that relate to individuals, e.g. a bank.

In practice, the right ZKP model needs to be selected according to each functional use case. Table 1 summarizes the choice considerations of different ZKP models. Here, the term “ZKP model” encompasses a broad range of characteristics of ZKPs, including interaction/non-interaction of ZKPs, trusted setup of ZKPs, the computational cost of ZKPs, and the size of ZKP proofs.

NOTE As most ZKP/NIZKP schemes are trademarked, this clause does not provide any concrete scheme names. A ZKP is considered to be succinct if its proof size is asymptotically less than the statement size, e.g., independent of the statement size, or logarithmic to the statement size. See ZKProof Community Reference [2] for more details on proof succinctness.

Table 1 — Choice considerations of ZKP models

Age Verification (AV) provides an example of a monotonic, persistent computed attribute.

Once a person has been verified to be over 18 by computing the difference between the current date and the date of birth of the individual, there is no need to ask them again since that property persists.

Beside the demonstration of that property, other properties shall be verifiable in the statement presented by the prover to the verifier.

The statement shall demonstrate that the date of birth is in a field present in an authoritative document, that this field has a given format, that the age difference is computed between the current date and the content of that field, that the authoritative document has been signed by an authority trusted by the verifier, that the authoritative document is within its validity period, that the statement is bound to a distinguishing identifier of the correct user that is able to uniquely relate the statement to the correct user, within the context of the verifier.

A rather long composite statement shall demonstrate all these properties. See Annex D for an example of ZKP for secure comparison of two numbers.

Insider trading is a major threat for shareholders holding stock for a specific company, since senior employees or employees in certain roles in the company are privy to information about the company’s performance and key investment decisions before they become public, thereby giving them a disproportionate advantage over other shareholders and general public.

The employers are therefore required to let employees know the blacklist and as per applicable laws, to monitor and flag any potential insider trading transaction (of one in the list) to the regulators. The monitoring would often require employees to proactively disclose to the Company’s compliance function, the details of their trading accounts, current stock portfolio and any transactions for the company stock. This would violate employee privacy and hence transparency needs to be balanced with confidentiality.

Using ZKP, parties can prove, without revealing the stock holdings, that stocks owned by an employee is not one of them in the published blacklist, thus help preserve financial privacy.

A privacy friendly online auction system can offer complete transparency on the lowest bid while keeping each party’s bid confidential. Using ZKP, the bidders get assurance that the winner was chosen with adherence to the norms, without revealing any information about any bidder. Refer [4] for one example auction scheme using ZKP; The process involves auction initiation, bid commitments, opening bids, proof generation, and proof verification.

The proof of Disability is officially used to recognize an individual’s disability and to prove their eligibility of the care/support programs provided by governments, companies, or communities. For example, such proofs of eligibility due to a particular disability would simplify the production and international transfer of specially-adapted books for people with blindness or visual impairments.

An online video-content provider can use ZKP to verify user’s certification of disability with privacy preservation. More specifically, when digital credentials are used, one can utilize ZKP to ensure each digital certification user can prove the validity of its identity with only revealing the necessary data needed, i.e. the online video-content provider only learns that the user is whether a true holder of the certificate, and he/she is eligible to access to those specially-adapted contents. See Annex E for more details on digital credentials based on ZKP.

The goal of DLTs is to record transactions about assets in which the transactions and some of their details are recorded in multiple places at the same time.

This guarantees the availability of the recording of the transactions and their traceability. Zero-knowledge techniques allow to hide the details of the transactions to the miners while enabling their validation.

ZKPs also allow DLT nodes to consider legislations on Anti-Money Laundering (AML) and for Counter Terrorist Financing (CTF).

In this context, ZKP allows counterparties to know whether the (undisclosed) amount of money being transferred is lower than a threshold above which the identities of the two parties of the transactions shall be disclosed.

Fiat money is a government-issued currency that is not backed by any tangible asset, such as gold or silver. Its value is based on the trust the people have in the government issuing it.

NOTE The term "fiat" is derived from the Latin word meaning an authoritative determination or order.

A central bank digital currency (CBDC) is intended to become the digital form of a country's fiat currency. CBDC are similar to crypto currencies. However, while the value of a crypto currency is set in a decentralized way and cannot be regulated by a single authority, the value of a CBDC is set by a single authority, i.e. the central bank.

Zero-knowledge proof (ZKP) technology can be applied to CBDCs to achieve cash-imitating levels of privacy while ensuring regulatory compliance, such as anti-money laundering (AML) regulations. In particular, transaction details can be kept confidential between the sender and receiver using ZKP. A third party, like a financial authority, cannot access the details unless it hits certain preset thresholds. Then, the transacting pair can only continue making payments after they are confirmed to be comply with applicable legal requirements.

1. 
   (informative)
   
   Factors facilitating or hindering ZKP developments
   1. Factors facilitating ZKP developments

ZKP protocols that have been invented by cryptographers are implemented by software developers. There is a plethora of programming languages and many of them have not been designed to handle operations like exponentiations on large numbers (e.g. 256 bits).

Nevertheless, currently, building blocks to construct elementary ZKP protocols are emerging thanks to the availability of zero-knowledge compilers.

A zero-knowledge compiler is a compiler which takes on or more "proof-goal" as its input language and outputs an implementation of them. They are being developed for different classes of proof-goals. They allow software developers to implement ZKP protocols without having an in-depth knowledge of ZKP cryptography and without the risk of introducing security flaws in their implementations.

Proof-goals may be written in languages designed specifically for addressing this problem, and the output may be a program written in a high-level language, such as C++, which is not optimum to handle large integers on 64 bits machines.

• 1. Factors hindering ZKP developments

A ZKP protocol usable for some business purpose is a composition of several individual ZKP protocols. In order to allow for interoperability, it is necessary to define and to standardize suites of ZKP protocols. For solving a given problem, there is not a single solution but many solutions, each one with its own merits and drawbacks which depend on the context of use and on the computation limitations of the processors that will be used to implement them. The processors used by a prover and by a verifier are not necessarily the same.

Since the variety of cryptographic techniques being used is important, ZKP protocols are hard to understand even for some cryptographers. Complete explanations of composite ZKP protocols are currently inexistent.

Since the standardization process of composite ZKP protocols has not yet started, interoperability is still a faraway goal.

• 1. Post-quantum resistance

Large -scale quantum computers may be developed in the coming future. With quantum computers, the Shor's algorithm is able to efficiently factorise numbers and compute to discrete logarithms on which some ZKP schemes are based on. If the expected lifetime of the proof system extends beyond the emergence of quantum computers, then it is necessary to rely on intractability assumptions that are believed to resist quantum computers. Currently, post-quantum resistance ZKP schemes are less efficient in general. Note that Bulletproofs^[7]used by the examples in this document are not post-quantum resistant. See more discussion in ZKProof Community Reference [2].

1. 
   (informative)
   
   Example of a consistency check between two documents
   1. General

A consistency check between two documents is used to demonstrate that two signed formatted documents contain the same value in a given field identified such as a family name, a date of birth, a ZIP code or a phone number without disclosing this value to the verifier.

NOTE This example is over-simplified since there is no proof that the data present in the database relates to the legitimate holder of these two documents and is valid at the time the proof is presented.

• 1. Document structure

— Two documents are formatted as collections of attributes. For instance, <, … > and <, … >, where the NameField₁ and the NameField₆ contain a character string that supposed to be the same.

• 1. Roles

— Two authorities are responsible for signing the formatted user’s documents.

— The prover wants to prove that the character string contained in in is the same as the character string contained in in , without disclosing the value of the character string.

— The verifier wants to verify that the two documents indeed contain the same character string in and respectively.

• 1. Protocol

— Step 1. Each of the authorities signs each document, respectively.

Denote authorities A₁’s public key as , and the signature of as .

Denote authorities A₂’s public key as , and the signature of as .

BBS+ signature can be adopted for implementing the underlying signature scheme, see [5] for more details.

— Step 2. The prover commits to all the attributes in each document via the vector commitment. Vector commitment can be used to commit a vector of attributes; later, the prover can partially open a certain entry of the vector to the verifier with an opening proof.

Denote the commitment of as and denote the commitment of as .

Merkle hash tree can be adopted for implementing the underlying vector commitment; more precisely, we can let the leaves of the Merkle hash tree be the components of the vector and let the root of the Merkle hash tree be the resulting commitment. See [6] for more details.

— Step 3. The prover generates a ZK proof using the statement <> and the witness <>, where shows that the following statement is true:

[I know Document <, … > and <, … > and their signatures such that and and

and

and ].

Bulletproofs can be adopted for implementing the underlying zero-knowledge proof, see [7] for more details.

— Step 4. The prover sends <> to the verifier.

— Step 5. The verifier checks the validity of ZK proof .

1. 
   (informative)
   
   Example of selective disclosure
   1. General

Selective disclosure allows a user registered by an authority in a database, to disclose only a collection of their attributes such as their country of residence, the state of his residence or the city or the ZIP Code of their residence, without necessarily revealing their family name, first name or email address.

NOTE This example is over-simplified since there is no proof that the data present in the database relates to the legitimate holder of the entry in the data base and is valid at the time the proof is presented.

• 1. Database structure

— A database is formatted as a collection of attributes. For instance, <, …>, where is the selected attribute to be revealed.

For each user, an entry of the database is signed by an authority.

• 1. Roles

— An authority is responsible for signing the collection of attributes for the user as formatted in the database.

— The prover wants to reveal the value of and to demonstrate that this value is a an attribute contained in the , without disclosing the rest of his attributes.

— The verifier wants to verify that is indeed data signed by the authority maintaining the .

• 1. Protocol

— Step 1. The authority signs the attributes contained in the user’s database entry . Let PK be the authority’s public key, and let be the signature over the user’s database entry. BBS+ signature can be adopted for implementing the underlying signature scheme, see [5] for more details.

— Step 2. The prover commits to the database via the vector commitment.

Denote the commitment of as .

Merkle hash tree can be adopted for implementing the underlying vector commitment, see [6] for more details. See discussions about vector commitment and Merkle hash tree in Annex B.

— Step 3. The prover partially opens the commitment for the first entry . Denote the opening proof as .

— Step 4. The prover generates a ZK proof using the statement <> and the witness <>, where shows that the following statement is true:

[I know a database <, … > and its signature

such that and ].

Bulletproofs can be adopted for implementing the underlying zero-knowledge proof, see [7] for more details.

— Step 5. The prover sends <> to the verifier.

— Step 6. The verifier first checks if . Then the verifier checks the validity of ZK proof .

1. 
   (informative)
   
   Example of secure comparison of two numbers

Secure comparison of two numbers is used to reveal the comparison result of two committed or encrypted numbers correctly, without disclosing these two numbers in plaintext.

NOTE This example is only theoretical, since the meaning and the origin of the two numbers is unspecified as well as their relationships, if any, with the prover. In addition, it is not demonstrated that the proof is valid at the time the proof is presented.

Data structure

— It is assumed that two numbers are non-negative integers , e.g., . It is also assumed that .

Roles

— Two authorities are responsible for signing the two numbers.

— The prover wants to prove that , without disclosing .

— The verifier wants to verify that is indeed larger than .

Protocol

— Step 1. Each of the authorities signs each number, respectively.

Denote authorities A₁’s public key as , and the signature of as .

Denote authorities A₂’s public key as , and the signature of as .

ECDSA signature can be adopted for implementing the underlying signature scheme.

— Step 2. The prover commits to the two numbers. Denote the commitment of as and denote the commitment of as .

Pedersen commitment can be adopted for implementing the underlying commitment. Pedersen commitment is widely used in cryptography due to its additive homomorphism and its high efficiency. See [8] for more details.

— Step 3. The prover decomposes into bits such that .

Similarly, the prover decomposes into bits such that .

— Step 4. The prover commits to and respectively. Denote the commitment of as and denote the commitment of as for each .

Pedersen commitment can be adopted for implementing the underlying commitment, see [7] for more details.

— Step 5. The prover generates a ZK proof using the statement <> and the witness <>, where shows that the following statement is true:

[I know two numbers and their signatures

such that and and

and and

and

and

and and ].

Bulletproofs can be adopted for implementing the underlying zero-knowledge proof, see [7] for more details.

— Step 6. The prover sends <> to the verifier.

— Step 7. The verifier checks the validity of ZK proof .

1. 
   (informative)
   
   ZKP usage example using digital credentials
   1. Digital credentials

Digital credentials can be seen as equivalent to physical credentials, such as driver licenses, ID cards, passports and diplomas. While these physical credentials are mostly verified by a human being in a face-to-face configuration, digital credentials are issued by a digital credential issuer to an individual, who has an application that can derive a digital proof from the digital credential using ZKP.

• 1. The three roles model

The three roles are the following:

1) the digital credential Issuer,

2) the Holder, which is the individual who has control of the application that receives a digital credential,

3) the Verifier, an entity relying on the verification of a digital proof derived from a digital credential placed under the control from a Holder.

These three roles involve the use of three different applications each managed by three different entities.

This model has two cryptographic variations: when it uses ZKP and when it uses traditional cryptography.

ZKP can provide the following benefits:

1) binding a key to the digital credential, so that the Holder can later on demonstrate that it is the legitimate holder of a digital credential received from the digital credential Issuer,

2) hiding the key used by the holder to demonstrate that it is the legitimate holder of the digital credential received from the digital credential Issuer,

3) demonstrating knowledge of that key to a Verifier,

4) hiding the signature of the digital credential created by the credential Issuer,

5) for the selective disclosure of a set of attributes contained in the digital credential to a Verifier.

• 1. Issuance of digital credentials

A digital credential is issued in accordance with a schema or a template maintained by the digital credential issuer. It always contains one part that is digitally signed by the digital credential issuer but it may also contain other unsigned parts.

Before being able to receive a digital credential, the Holder shall first generate a pair of cryptographic keys. The individual may then request a digital credential from a digital credential Issuer by selecting a schema or a template and/or fill-in a form.

Two kinds of cryptographic keys can be generated by the Holder:

a) either, when using traditional cryptography, an asymmetric key pair, i.e., a private key and a public key,

b) or, when using ZKP, both a link secret and a blinded link secret.

Either the private key or the link secret is kept by the Holder's application. When the Holder's application sends a digital credential request, either the public key or a blinded link secret is communicated to the digital credential Issuer, and that application shall demonstrate to the digital credential Issuer that it knows either private key or the link secret.

A link secret is a large random number. A cryptographic commitment is made based on the link secret. It can be viewed as enclosing the link secret in an envelope. Once the envelope is sealed, it cannot be changed anymore. It is possible to blind the same commitment in different ways so that it can be shared without modification.

It is not possible for a malicious party to use multiple different blinded link secret values to derive the link secret, but it is possible for the Holder to prove to a Verifier that the same link secret was used to construct a blinded link secret included in a digital credential.

When a public key is included in the digital credential, its value appears in a field of the digital credential.

However, when a blinded link secret is included in the digital credential, its value does not appear in a field of the digital credential. It is a "hidden" field that takes part in the computation of the digital signature made by the digital credential issuer.

When a Holder requests a digital credential from several digital credential Issuers, for each request, it uses a different blinded link secret and hence each issued digital credential contains a different blinded link secret. This value does not allow anybody to correlate digital credentials issued by different digital credential issuers for the same Holder.

An important benefit of using link secrets is the ability for a Holder's application to demonstrate to a verifier that credentials issued by different digital credential issuers were indeed issued to the same Holder.

When the Issuer issues a digital credential, it uses a blind signature because it knows all the fields except the commitment (i.e. the blinded link secret, which is a "blinded field").

When the Holder's application receives the digital credential, it unblinds the blind signature in order to obtain a valid signature over all the fields. It is then able to check that the received digital credential conforms to the schema or template that was initially selected and that it contains appropriate values.

In order to prevent the export of the private keys or of the link secret keys, it is necessary to prevent a Holder's application to masquerade as another Holder's application. However, it is not sufficient. A Holder's application would still be able to perform the cryptographic computations that are necessary for another Holder's application to demonstrate that it holds a valid digital proof derived from a digital credential issued to the first Holder. This would be a collusion attack between Holders performed against a Verifier, with the consent of the individuals controlling these Holders applications.

When the digital credential Issuer receives a digital credential request, it should be able to know the characteristics of the protection features of the private keys or of the link secret supported by the Holder's application.

The digital credential Issuer needs to be confident that the cryptographic key included in the digital credential has been generated by an application able to:

c) generate a key pair according to a given cryptographic algorithm,

d) protect the secret or the private key and to prevent its exportation,

e) restrict the usage of the secret or the private key to the intended protocols only.

This can be done by using an application attestation that allows the digital credential Issuer to be confident that it is communicating with an instance of a genuine application that has specific characteristics and running in a trusted environment.

In practice, the Holder's application will be a Trusted Application (TA) running under a TEE (Trusted Execution Environment). If the protection features of the TA are unknown or are considered insufficient, then the digital credential issuer will not issue the requested digital credential.

The digital credential request shall be protected for integrity, and its origin shall be verifiable by the digital credential issuer. This can be done using a private key specific to a TA or shared between a set of TAs. The use of this private key(s) indirectly allows the digital credential issuer to know the characteristics of the TA.

• 1. Unlinkability property between Verifiers

This property can be supported when the digital credential includes either a public key or a blinded link secret.

1) When a digital credential includes a public key, it can only be used once; otherwise, the public key value would be usable to link two digital proofs.

This means that the Holder's application shallfirst create a batch of asymmetric key pairs and then request from the digital credential issuer a batch of digital credentials for each public key. In this way, the value of the public key cannot be used for correlation purposes. Before all the digital credentials in this batch are used, the Holder's application should acquire a new batch of digital credentials. To do so, it shall communicate with the digital credential Issuer, but it can then use these digital credentials when it is offline, e.g., when it is communicating with a Verifier using the NFC technology.

2) When a digital credential includes a Blinded Link Secret, it can be used by the Holder until its expiration date is reached or it is suspended or revoked.

• 1. Presentation of digital proofs to a Verifier

When a Verifier requires the Holder to demonstrate a statement, it sends a challenge to the Holder's application. Since the Holder's application knows from which verifier it obtained the challenge, it is able to include in the digital proof both the challenge and an identifier of that Verifier (usually a base URL).

The challenge provides a replay attack protection against the same verifier, because the identifier of that verifier restricts the use of that digital proof to that verifier.

When a digital credential contains a public key generated by the Holder's application, that application can demonstrate to a Verifier that it knows the value of the corresponding private key by computing a digital signature based on both the received challenge and the identifier of that Verifier.

When a digital credential contains a Blinded Link Secret generated by the Holder, the Holder's application is able to demonstrate to a Verifier that it knows the value of the corresponding Link Secret using an algorithm that proves in zero-knowledge that the Link Secret behind different commitments is the same.

• 1. Enforcement of collection limitation by a Holder

Collection limitation will primarily be accomplished by the Holder's application selectively disclosing the attributes of an individual.

Selective disclosure can be accomplished using traditional cryptography techniques. In this case, the idea is to use salted-hashed attributes where hash values computed over a salted-attribute (composed of a name and of a value) are included in the signed part of the digital credential while the salted-attributes are external to the signed part of the digital credential. By communicating or not communicating to the Verifier some external salted-attributes, the Holder's application is able to limit the disclosure of the attributes. In order to support the unlinkability property, batches of digital credentials need to be issued, where each digital credential is using a different salt value for each attribute.

Selective disclosure can also be accomplished using ZKP techniques where the prime example is the use of BBS or BBS+ signature mechanisms. See [9] for the mathematical background for the construction of BBS+ signatures.

Such signatures contain one header and several messages. The header contains a single signature that allows to individually sign each of these messages. In order to be able to interpret the content of the digital credential, the Verifier needs to use an appropriate schema or template. The Holder can then generate a randomised proof for a subset of the signed messages. It is thus a selective disclosure of these messages. The generated proofs are unlinkable from a cryptographic perspective.

• 1. Verification of digital proofs by a Verifier

When a Verifier receives a digital proof from a Holder's application, it should first verify that the challenge and its own identifier are included in the digital proof (or in the header of a BBS+ signature). Afterwards, it should verify that the digital proof includes a signature from a trusted digital credential issuer. By using the header and the digital issuer public key, the Verifier can validate the randomised proofs for a subset of the originally signed messages.

The Verifier should then use either the public key or the Blinded Link Secret included in the digital proof to verify that the Holder has used either the corresponding private key or the Link Secret matching with the Blinded Link Secret in order to integrity protect a set of additional data. The techniques used behind the use of the Link Secret and the Blinded Link Secret are based on Zero-Knowledge techniques.

A digital credential is considered valid, if two conditions can be verified:

— the digital credential is presented to the Verifier during its validity period, and

— the digital credential has not been suspended or revoked.

The first condition is supported by including a validity period inside the credential that will be reflected in the digital proof. The granularity of the "not before" and the "not after" dates should be coarse enough so that these two dates cannot be used to correlate two digital credentials.

• 1. Suspension and revocation checking

Currently, when using X.509 digital certificates, there are two mechanisms for verifying if an X.509 certificate has been suspended or revoked: using either CRLs or OCSP responses. These mechanisms can also be used to verify that a digital credential has not been suspended or revoked.

However, inside the digital credential, they require the inclusion of a unique serial number which provides a means for the Verifiers to correlate the use of the same digital credential by two different Verifiers.

When we want to hide the identity of the verifiers, OCSP-like mechanisms cannot be used, since any callback from a Verifier to a digital credential issuer would allow to the digital credential issuer to tell by which Verifier a digital credential has been used.

A CRL fetched by the holder's application and forwarded to the Verifier would be an alternative solution, but it only works when a digital credential is used once, otherwise it provides means for different Verifiers to correlate digital proofs derived from same digital credential.

The following description achieves the goal but does not involve the use of any ZKP mechanism. The goal can be obtained by taking advantage from the fact that digital credentials are managed by a Holder's application that is often called a digital identity wallet, or simply a digital wallet.

Since a digital wallet requests the issuance of digital credentials from one or more digital credential Issuers, it can know their identifiers, in particular a URL for requesting digital credentials and a URL for managing digital credentials before and after their issuance. When a digital wallet is online, it can contact the digital credential Issuer for each digital credential to query whether a digital credential already stored in the digital wallet is suspended.

A local policy dictated by a digital credential Issuer and enforced by the digital wallet can ensure that a digital credential stored in the digital wallet will only be usable if the digital wallet has been able to contact the digital credential issuer within a timeline set in the local policy e.g., the last 24 or 36 hours. When this is not be the case, the digital credential will be suspended until a contact can be re-established with the digital credential Issuer.

When online, the digital wallet can query or poll each from time to time, as defined in the local policy e.g., every hour, to ask whether a digital credential is suspended or not. When a digital credential is suspended by a digital credential Issuer, the Holder's application is informed of that suspension at the time it is making the query or the poll.

The use of a digital wallet also allows all the digital credentials stored in it to be suspended simultaneously, by contacting the provider of the digital wallet, e.g., the TA Provider. This can be performed if the digital wallet queries the TA Provider periodically, e.g., every hour. The TA provider can instruct a digital wallet instance to suspend the use of any or all digital credentials, in particular when an individual has lost his digital wallet.

By the digital wallet querying the digital credential Issuers and the TA Provider periodically, the use of one or all the digital credentials can be suspended and restored once the reason for the suspension has been fixed. This approach enables a significant reduction in risks and costs (from both operating costs and fraud), and hence improves the overall security level.

Bibliography

[1] ISO/IEC 9798‑5:2009, Information technology — Security techniques — Entity authentication — Part 5: Mechanisms using zero-knowledge techniques

[2] ZKProof Community Reference. Available online from https://docs.zkproof.org/pages/reference/versions/ZkpComRef-0-3.pdf

[3] Verifiable Credentials Data Model v2.0 Available online from https://www.w3.org/TR/vc-data-model-2.0/

[4] Zero Knowledge Proofs applied to auctions. May 16, 2019 Available online from: https://courses.csail.mit.edu/6.857/2019/project/18-doNascimento-Kumari-Ganesan.pdf

[5] The BBS Signature Scheme. July 10, 2023 Available online from: https://datatracker.ietf.org/doc/draft-irtf-cfrg-bbs-signatures/ Available online from: https://identity.foundation/bbs-signature/draft-irtf-cfrg-bbs-signatures.html

[6] Merkle R.C. "A digital signature based on a conventional encryption function." Conference on the theory and application of cryptographic techniques. Berlin, Heidelberg: Springer Berlin Heidelberg, 1987. Available from: https://people.eecs.berkeley.edu/~raluca/cs261-f15/readings/merkle.pdf

[7] Bünz. Benedikt, et al. "Bulletproofs: Short proofs for confidential transactions and more." 2018 IEEE symposium on security and privacy (SP). IEEE, 2018. Available online from: https://eprint.iacr.org/2017/1066.pdf

[8] Pedersen T.P. "Non-interactive and information-theoretic secure verifiable secret sharing." Annual international cryptology conference. Berlin, Heidelberg: Springer Berlin Heidelberg, 1991. Available online from: https://link.springer.com/content/pdf/10.1007/3-540-46766-1_9.pdf

[9] "Privacy-Preserving Credentials for Self-Sovereign Identity with BBS+ Signatures". Master Degree Thesis. Alessandro Guggino. 2021-2022. Available online from: https://webthesis.biblio.polito.it/24502/1/tesi.pdf

[10] Selective Disclosure for JWTs (SD-JWT) Available online from: https://datatracker.ietf.org/doc/draft-ietf-oauth-selective-disclosure-jwt/

[11] Selective Disclosure CWTs (SD-CWT) Available online from: https://datatracker.ietf.org/doc/draft-prorock-cose-sd-cwt/

[12] ISO/IEC 4922‑1:2023, Information security — Secure multiparty computation — Part 1: General

[13] ISO/IEC 4922‑2:2024, Information security — Secure multiparty computation — Part 2: Mechanisms based on secret sharing

[14] ISO/IEC 29100:2024, Information technology — Security techniques — Privacy framework

[15] ISO 31000:2018, Risk management — Guidelines

[16] ISO/IEC 29134:2023, Information technology — Security techniques — Guidelines for privacy impact assessment

[17] ISO/IEC 24760‑1:2025, IT Security and Privacy — A framework for identity management Part 1: Terminology and concepts

[18] ISO/IEC 11770‑7:2021, Information security — Key management — Part 7: Cross-domain password-based authenticated key exchange

[19] ISO/IEC 27551:2021, Information security, cybersecurity and privacy protection — Requirements for attribute-based unlinkable entity authentication

[20] ISO/IEC/TS 29003:2018, Information technology — Security techniques — Identity proofing

[21] ISO/IEC 20889:2018, Privacy enhancing data de-identification terminology and classification of techniques

[22] ISO 12812‑1:2017, Core banking — Mobile financial services — Part 1: General framework

[23] ISO 17356‑1:2005, Road vehicles — Open interface for embedded automotive applications — Part 1: General structure and terms, definitions and abbreviated terms

[24] ISO/TS 17573‑2:2020, Electronic fee collection — System architecture for vehicle related tolling — Part 2: Vocabulary

[25] ISO/IEC/TR 27550:2019, Information technology — Security techniques — Privacy engineering for system life cycle processes

[26] ISO/IEC 10118‑1:2016, Information technology — Security techniques — Hash-functions — Part 1: General

[27] ISO/IEC 10118‑2:2010, Information technology — Security techniques — Hash-functions — Part 2: Hash-functions using an n-bit block cipher

[28] ISO/IEC 10118‑3:2018, IT Security techniques — Hash-functions — Part 3: Dedicated hash-functions

[29] ISO/IEC 10118‑4:1998/Amd 1:2014, Information technology — Security techniques — Hash-functions — Part 4: Hash-functions using modular arithmetic — Amendment 1: Object identifiers

[30] NISTIR 8213 A Reference for Randomness Beacons

[31] ISO/IEC 20008‑2:2013, Information technology — Security techniques — Anonymous digital signatures — Part 2: Mechanisms using a group public key

[32] ISO/IEC 20008‑3:2024, Information security — Anonymous digital signatures — Part 3: Mechanisms using multiple public keys

1. Under preparation. Stage at the time of publication: ISO/IEC FDIS 24760-1:2025. ↑