Topic G: Zero Knowledge Proof

[phin10]

Welcome to the discussion on the Zero knowledge Proof, part of the ongoing development of the Architecture and Reference Framework (ARF) for the European Digital Identity (EUDI) Wallet.

This discussion is based on the document Topic G - Zero knowledge Proof.

ZKP offer strong potential as a privacy-enhancing technique. It should be revisited to determine the foundational requirements needed for its future integration, particularly focusing on defining specific requirements for implementing ZKP by using any type of WSCD/WSCA.

The paper presents the privacy properties of Zero-Knowledge Proof schemes, and introduces families of Zero-Knowledge Proof schemes and gives an overview of representative solutions. For the purpose of the ARF topics are discussed related to the integration of Zero-Knowledge Proof schemes into the ARF, and finally lists the additions and changes that will be made to the ARF as a result of discussing this topic with Member States.

This discussion is part of a structured process to refine and complete the ARF, with your input playing a vital role. We invite you to share your comments, insights, and suggestions here. Your contributions will be carefully reviewed and considered as we work towards the next version of the ARF, which will incorporate updates on this topic.

Thank you for participating in this important conversation.

[joelposti]

The discussion paper has this bullet point.

• Soundness: If the statement is false, a dishonest prover cannot convince an honest verifier that it is true, except with some negligible probability.

What does ‘negligible probability’ refer to? Is there some element of randomness that would allow a false statement to be considered true?

[matteo-frigo]

That's correct. Zero-knowledge proofs are inherently randomized and they have a small probability of failure. The exact value of "negligible" is a tradeoff between soundness, CPU time, and size of the proof, but you can take 2^{-100} as a reasonable target.

[ottomorac]

Hello @phin10 . Thank you for opening this discussion. Question. Why are you considering BBS+ to be a zero knowledge proof scheme? As far I understand the scheme provides selective disclosure. It is not categorized as a Non Interactive Zero Knowledge Proof scheme (NIZKP)?

Valid NIZKP protocols include: zk-SNARKs, zk-STARKs, and bulletproofs (and derivatives of them) . But I do not know of any academic paper that mentions BBS+ as valid NIZKP.

[giovannibartolomeo01]

Hi, I believe the EC reference is to the Tessaro Zhu paper, from which BBS is going to be standardized in IETF: https://eprint.iacr.org/2023/275.pdf

[ottomorac]

I see. I would be willing to concede that BBS+ provides a form of "anonymous signatures" (I believe that is what they were being called originally). Or even selective disclosure. You could even argue that BBS+ can be used in conjunction with ZKP-friendly cryptographic protocols, to allow the construction of proofs where a verifier can check that a credential is valid without knowing all the details (as seems to be the case in the paper that you shared).

However from a categorization standpoint, I have not seem them categorized as a ZKP. Non Interactive ZKPs (NIZKP) like zk-SNARKs, zk-STARKs, and bulletproofs are the ones that I have seen in academic papers.

[anjleh]

Just to clarify, what you refer to as "valid NIZKP protocols" such as zkSNARK, zkSTARK, etc. are a particular type of non-interactive zero-knowledge proof, but not the only one. The oldest type of non-interactive ZKP are Schnorr-type proofs, which are made non-interactive through the Fiat-Shamir transform.

BBS+ is a signature scheme that already comes with an efficient ZKP of the signature (and attributes), and this proof is such a Schnorr-type NIZK.

When ZKPs are mentioned in the EUDI context, it usually means signatures with efficient proofs, not ZKP as a stand-alone tool. BBS+ is one such instantiation, and zkSNARKs built on top of ECDSA signatures are another.

[giovannibartolomeo01]

Hi Otto, yes, more specifically, I believe there are two different concepts here, one is "anonymity" (i.e., a property of some protocols), the other one is ZKP (whose properties are correctness, soundness and "zeroknowledgeness").

• There are protocols using ZKP that not necessarily ensure anonymity (e.g., Schnorr does use ZKP, but it is an identification protocol).

• Viceversa, there are anonymous protocols that do not necessarily use ZKP (e.g., Deuber, Maffei, Malavolta, https://petsymposium.org/popets/2018/popets-2018-0013.php)

So I guess the intent is to refer to ZKP as a mean to support anonymity.

[AltmannPeter]

View ZKP as a property of a proof system. There are many (N)IZKP proof systems that fall outside of the standard three arguably popularized by cryptocurrencies.

Specifically, BBS+ has ZKP guarantees for undisclosed messages, and allows the prover to create a ZKP of knowledge of the signature. That does not mean that the ZKP property applies to anything beyond those two.

[ad-Orange]

[Comments on chapter 3]

[Chapter 3.1.1]
We would argue that the BBS# description does not fully reflect the advances it brings as compared to BBS+ in an eIDAS 2.0 context and would therefore like to propose the following update for the last sentence:

“BBS# [Ora2024] is a modification of BBS+ allowing group signatures and selective disclosure based on ECDSA” => “BBS#[Ora2024] is an extension of BBS+ whose objective is to increase its security (by allowing holder-binding using classical WSCDs) and certifiability properties while maintaining its inherent privacy properties.

[Chapter 3.1.3]
One of the goals of BBS# is to ease the deployment and rely on existing WSCDs. As a result, the dependency on the WSCD in terms of signature is limited to ECDSA or ECSDSA. ECDSA is indeed “widely supported”. On the issuer side, both BBS+ and BBS# require BBS signatures, that are indeed not widespread today.

Therefore, we propose to change the disadvantages to “Require support for digital signature schemes that are not widely supported yet on the issuer side”.

[Chapter 3.2.1]
From a practical point of view, zk-SNARKs use does require changes to the issuance process.
To get a new attestation, the holder needs to be authenticated by the issuer. In real-life, for high value issuers in particular, this will require the issuer to play a relying party role and most usually to check the holder’s PID. This relying party role will definitely be impacted by the implementation of zk-SNARKs and thus require the use of new cryptographic algorithms.

Not only does the issuer need to play this relying party role, but the higher the needed level of certification for the issuer, the more it will need to have confidence in the quality of the presentation verification feature implementation, e.g. through formal proof mechanisms. However, the sensitivity of zk-SNARKs to the type of attestation and their complexity will generate significant burden for the issuers (and for the relying parties alike), particularly for high value ones in terms of deployability/interoperability/certifiability.

Therefore we don’t believe that the statement that there are no significant changes in the issuer process is correct and we would even argue that the process of adding a new, relatively simple signature algorithm could be less of a burden than the management of notoriously complex zk-SNARKs.

[ad-Orange]

[Comments on chapter 4.1]

Generally, what the use of a properly designed ZKP scheme should do is decorrelate the “identity service layer” from the “infrastructure layer”. In other words, the ZKP scheme shall ensure that whatever is required by the relying party, provided by the issuer and presented by the holder, at the end of the presentation, the relying party only learns something from the information that the holder explicitly wanted to provide and learns nothing more from the underlying infrastructure. As a matter of fact, the issuer shall learn nothing in the process. What that means is that the holder is deciding by itself (and also based on relying party needs) what attribute it reveals in clear (e.g. date of birth), completely hides (e.g. *****), or minimises (e.g. “over 18”).

If this is applied and if the considered scheme does not significantly increase the necessary processing, then the thinking should be reversed: is there any reason NOT to use a ZKP scheme for all transactions ? Using a ZKP scheme verifying the decorrelation between the infrastructure layer and the identity service layer would ensure a very flexible ecosystem naturally evolving towards more privacy.

For instance, already today, ZKPs would be needed to implement the following relying party requests in a fully privacy protecting manner even if it could be implemented like today, with a much reduced level of privacy:

• A student wants to leverage a public transportation discount without disclosing all the information on their current curriculum
• A professional who wants to rent a flat needs to prove their revenue is above the threshold (and since at least 6 months) without revealing their exact salary or their tax level
• A member wants to access a gym room without being tracked (the gym just needs to know that they are a registered member)
• A traveller wants to prove they have had the proper vaccination to be able to travel, without providing all their information to all the control points
• A citizen wants to prove that they live in a specific country without revealing their full postal address (e.g. to get the “local” discount on a community swimming pool)
• In a recruiting context, prove skills / diplomas without being identified and risk getting discriminated against

In order to achieve that vision properly, the most important features to implement are:

• Full unlinkability
• Everlasting privacy
• Privacy preserving revocation
• Selective disclosure
• Plausible deniability
• Minimisation
• Pseudonymity
• Blind signatures
• secure multi-VC linking

If a proper ZKP scheme is implemented, we see no reason to implement anything else, except potentially for resistance to quantum computer based forgery if the considered scheme is not quantum resistant.

[ad-Orange]

[Comments on chapter 4.2]

Yes, the support of ZKPs shall not endanger the security model and a WSCD-bound user binding shall absolutely be enforced, and of course without jeopardizing the privacy benefits brought by the use of ZKPs. In order to enforce the full trust model, the ZKP scheme shall also allow an efficient secure multi-VC linking, i.e. the ability to efficiently prove that multiple VCs used as part of a single VP are indeed associated to the same WSCD.

Please note that the BBS# scheme requires WSCD-bound user binding by design, supports efficient secure multi-VC linking and is compatible with deployed WSCDs without requiring any update.

[ad-Orange]

[Comments on chapter 4.3]

Regarding proof generation time
We believe that the proof generation time should not exceed 1 second (including in a multi-VC linking situation with up to 10 VCs), based on standards in the banking sector : 500 ms (transaction on Electronic Payment Terminal) and transport sector : 300 ms (Validation of Transport Tickets ). This applies for a reasonable number of attestations and attributes in the attestations or the type of proof generated.

In the context of the BBS# schema, the computation time for a proof is approximately 100 ms for an attestation containing 50 attributes, of which 10 are disclosed.

Regarding storage and communication overhead
The European Wallet is a solution designed to accommodate a wide range of use cases and situations. If the Wallet gains wider adoption, individual users may store dozens of different types of attestations within their wallets. In such scenarios, a dependency on large per attestation type public parameters (potentially dozens of MB) may not be optimal and could lead to a significant increase in the overall size of the wallet.

The overall size of data necessary for presentations shall also not be over a few MB in order to ensure the fluidity of transaction, in particular face to face, taking into account the low power requirements of the underlying proximity interfaces and thus their relatively limited performances. Even for online transactions, taking into account limited or transient connectivity situations would point to the same direction. - Depending on the envisioned solution, that probably means that the signatures used in presentations shall be under a few kB, especially taking into account the multi-VC presentation use case.

Regarding hardware requirements
Given the smartphone footprint in the EU, the assumption should be for users to be able to achieve the target proof generation time performance with Snapdragon 680 equivalent performance level and a maximum of 128GB of storage and 6GB of RAM.

[ad-Orange]

[Comments on chapter 4.4]

Yes, ZKP scheme providers should collaborate with the relevant standardization bodies but in order to facilitate this process:

• The provided scheme should be compatible with the core structure of the considered standard, otherwise the gap could end up being too big for the standardization body
• The considered ZKP scheme should have reached some form of maturity, at least for the part being standardized. For the parts still under intense research, it does not make sense to envision a standardization process
• The EU Commission should go to the relevant standardization bodies and support the additional standardization work by listing the expected requirements to result from the standardization work

[ad-Orange]

[Comments on chapter 4.5]

The system load analysis cannot be completely assessed theoretically, especially in view of a constantly evolving technical infrastructure where even the theorical impact of interactions on system load becomes a moving target. We therefore find it difficult to decide on a priori limits on technical interactions as long as full privacy, high security and the target user experience are achieved.

Please also note that the comparisons on the overall load with and without ZKP might not always go against using ZKPs. In particular, implementing efficient privacy preserving revocation mechanisms might heavily reduce the load on the issuer side by allowing for much longer validity periods than 24 or 48h for attestations.

[ad-Orange]

[Comments on chapter 4.6]

Here are the additional properties that we think should be sought for in a ZKP scheme to be used in the eIDAS 2 context.

Wieldy for MS : any proposed scheme shall be understandable, auditable and flexible enough in its deployment for Member States and their respective certification bodies to feel comfortable about using it in all circumstances without fearing any downstream use case limitation or risk.

Compatible with the EC chosen protocols & formats : given the the EC willingness to use some specific protocols (like mDL & SD-JWT) as the core protocol for eIDAS, it is necessary for any proposed scheme to be compatible with these ARF promoted protocols and formats without major structural changes

Everlasting privacy (AKA unconditional privacy) : the signature scheme shall support everlasting privacy. In particular, given the eventual arrival of quantum computer, transaction logs shall not offer any opportunity to come back to their author or the involved hidden attributes in any circumstance. Voting comes as an evident example to mind.

Minimisation : chapter 2 lists range proofs as an example of “additional privacy properties”. We think it should be extended to any sort of minimisation whose final goal would be to only transact on predicates whereby the wallet would only answer “yes/no” to the exact required property from the verifier. E.g., for a business requirement of “over 18, not living in region A, and earning less than X” the answer would be yes or no as opposed to sending to the verifier the date of birth, the postal address and the salary which they don’t really need.

Support plausible deniability for both issuance and presentation: plausible deniability states that the receiver of a signature cannot transfer it to a third party in a way that the third party can believe its completeness. This shall always be implemented for issuance in order to limit the incentive to steal credentials and optionally be implemented for presentation in the use cases where the knowledge of the transaction details might put the holder in an uncomfortable situation.

Long VC validity periods : limiting the validity of VCs could create a wide range of issues from overloading the technical issuance and revocation chains to imposing unjustified end-user interactions. Being able to revoke VCs in real time (as soon as the information reaches the issuer) would allow such policies. Therefore, the proposed ZKP scheme would need to offer an implementation of this property that does not create new security or privacy risks.

Blind signature : the signature of attribute by the issuer in a way that the issuer doesn’t know the value it is signing is instrumental in implementing a proper trust model while preserving privacy (and in particular full unlinkability).

Secure multi-VC linking : in most (if not all) situations, presentations will require at least 2 attestations to be combined to be fully compliant with the trust model. In many situations, especially when the ecosystem grows and the use cases become richer, even more attestations might be required. In order to ensure that the attestations all originate from the same user with the same WSCD, it will be necessary to ensure that the considered ZKP scheme includes an efficient way to securely prove that they are indeed related while also preserving all privacy properties.

Centralized WSCD attacks descaling : with the HSM being increasingly seen as the best compromise between security and reach at the launch of eIDAS, it is important to ensure that the breach of an HSM platform would not lead to a complete and immediate loss of security for all the users associated to it. If the considered scheme is able to split the credentials between an HSM part and a part on the device (even in software), the impact of the attack is immediately reduced as a potential attacker would then need to ALSO compromise each and every associated device.

[ottomorac]

Feedback: 3.2.1 zk-SNARKs
Suggest that the Iden3 stack that support zk-snarks be discussed an mentioned as an example.

The Iden3 protocol started its development back in 2018, led by Jordi Baylina, David Schwartz, and Antoni Martin, with the goal of creating decentralized and trusted digital identities that could be used in the scenario of a national referendum via an on-chain voting system. Iden3 is owned by the nonprofit “0KIMS Association” and is managed as a public good.

A few components of the Iden3 protocol are worth highlighting:

• CIRCOM (world most used language and compiler to create zk-SNARK circuits), also recently referenced in this paper from zk researchers at various universities
• JWZ (JWT with ZKProofs) (method of signing and verifying authenticity of JWT payload messages using Zero-Knowledge Proofs)
• SnarkJS (the first general-purpose zk-SNARK prover capable of running on edge devices)
• ZKQuery Language (first general-purpose query language for zkp enabled credentials)

Verifiable Credential Issuance Signatures / Proofs used in the Iden3 Protocol:
Verifiable credentials in the Iden3 protocol can be issued in either of the following methods.

1- Signature Issuance Proof (BJJSignature2021): It proves that the specific issuer has issued the verifiable credential by a BJJSignature, which means the issuer simply signs the credential with their BJJ key and does not alter their issuer state tree.
About BJJ Cryptography:
Baby Jub Jub (BJJ) Cryptography was developed in 2018, and published in 2021 under a creative commons license. The BJJ cryptography is being used and tested at scale by various companies in the banking industry including HSBC and DB .

2 - Merkle Tree Issuance Proof (MTP - Iden3SparseMerkleTreeProof ): It proves that the specific issuer has issued this verifiable credential by a Merkle tree proof that this claim is included in the issuer’s Claims Merkle tree, and is therefore in the issuer’s state. This state is published by the issuer to a trusted ledger. Since this algorithm does not use any kind of signature it is stronger against potential quantum attacks, versus other signature algorithms.

You can see more details about each credential issuance methods in the Iden3 documentation for BJJSignature2021 and Iden3SparseMerkleTreeProof.

Key Advantages of the Iden3 Credential Signature Schemes:

1. Optimized for zk-SNARK Circuits: specifically BJJ signatures are designed for efficiency within zk-SNARKs. The Baby Jubjub curve minimizes circuit complexity and reduces computational overhead compared to other signature schemes (see table 1 in this paper). These characteristics make them ideal for low-latency applications requiring efficient proof generation and verification.
2. Scalability and Interoperability: Due to smaller proof sizes and reduced verification times, BJJ signatures scale effectively across large ecosystems, such as the EUDIW and others.
3. Privacy and Compliance: They enable users to prove attributes (e.g., age or business credentials) without exposing sensitive data, aligning with GDPR and privacy-by-design principles.
4. More flexibility thanks to ZK Proof and signature decoupling: The ZK proofs are decoupled from the signature schemes themselves, allowing to dynamically add new ZK circuits and implement more predicate operators or other features without modifying the signature schemes, this also prevents the need to re-issue credentials to support new features.

[ad-Orange]

On version 0.2

Following the update to version 0.2 of the discussion paper, we would like to highlight some points of importance.

[Chapter 2]
it is still not clear to us why range proofs are singled out as minimisation tools. Minimisation shall be mentioned as a whole and if not, set membership proof shall also be added as well as the combinations of such proofs (range and set membership) across VCs and combined through any logic operator (and, or, not, =, <). We don’t see any clear reason to single out range proofs.

On composite proofs, please note that a "hidden attribute binding" is not necessary with some ZKP schemes, and that all the randomized VCs leveraged in the VP embedding the same public key shall be enough of a signal to ensure proper combination. It would also ease the computing process on the relying party side for verification of the VP.
Note: similar to [Chapter 4.1.4] comments.

We insist again that everlasting/unconditional privacy is a critical feature to support in such a potentially wide encompassing framework as eIDAS 2.0.

Please note that any attribute that can be used as part of any conditional disclosure scheme will not have the everlasting privacy feature.

Finaly, we are happy to see that you added the “Deniable Presentation” property, but quite puzzled as to why you left “Deniable Issuance” out. This is very strange, as 1. It brings a clear benefit in all cases, whereas the “Deniable Presentation” use case is highly dependant on a particular use case 2. Both are complementary and adding “Deniable Presentation” doesn’t cover at all for any of the issues that would be covered by a “Deniable Issuance” feature.

[Chapter 4.1.4]
The trick of reusing a common hidden attribute is not necessary. The same embedded public key can be presented for an easy check of the combination.

Note: similar to [Chapter 2] comments.

[Chapter 4.5]
We take issue with the following statement, and for different reasons.

“Additionally, support for ZKP schemes is expected to follow the launch of the EUDI Wallet. PID Providers and Attestation Providers will likely have already invested in PID and attestation issuance infrastructure and software, with many PIDs and attestations already issued. A ZKP system should be designed to minimize disruptions to the existing issuance ecosystem at the time of its deployment.”

On one hand, it was brought to the attention of the commission that to ensure citizen trust and wide adoption of the eIDAS 2 wallets, the proper level of privacy shall be mandatory for the launch of the wallet. However, we do consider that the ARF excluded the only known tool able to achieve this goal: ZKP (this point is also shared by several experts). The late concern about including them is what is bringing us to the expectation that ZKP schemes are going to "follow the launch of the EUDI Wallet", i.e. arrive very late to the party.

On the other hand, due to the late integration of ZKP in the ARF, we might end up in a migration type situation. This involves all parts of the ecosystem. Issuers are an important part of the ecosystem but not the only one. The sustainability and expansion of the ecosystem will most probably depend on the financial flows originated from the Relying Parties.

Taking all the above in consideration, we propose to change the statement to the following one:
"All actors of the nascent ecosystem will likely have already invested in the legacy (ZKP-less) infrastructure and software and deployed associated components and credentials. A ZKP system should be designed to minimize disruptions to the existing ecosystem at the time of its deployment."

There is no obvious rational reason (to us at least) to only take into account issuer induced constraints and leave those of the rest of the ecosystem aside. As explained in this very discussion document, including ZKPs could touch on a lot of different aspects of the ecosystem, and they all need to be taken into account at the time when this will happen. The ecosystem not being completely defined yet and the associated impacts of ZKPs even less, concentrating on the impacts on only one of the ecosystem functions already from now would certainly introduce some analytical bias that we’re sure is not desired by the commission.

This is a general issue that we have with the while 4.5 chapter: defining precise expectations for parts of the ecosystem from now on that are not related to the user experience seems very premature given the overall technical maturity of the ARF and we see a strong risk of introducing unjustifiable bias.

Finally, we strongly believe that launching the eIDAS 2.0 infrastructure without including ZKP and their deriving privacy preserving properties is a very bad idea as it does not match the expectations of the European civil society and, as you rightly included in your own discussion paper, will create downstream migration issues.

[Requirements]

6&7: unclear. Both in terms of what it means and what the purpose is.
8: same as in 4.5: why concentrate on the "issuance process" only and not consider the whole ecosystem ?

[General Comments]

Focus on issuers
We are VERY puzzled by the apparent very strong focus on the issuer impact, mostly leaving out the potential impacts on other actors. There is arguably an implicit priority or assumption here and it is absolutely necessary to make it explicit for the exchanges to be more efficient with all actors

Examples thereof:
• Deniable Presentation but no Deniable Issuance
• Impact of migration to ZKP on the issuers but on no other actors
• Requirement 8 focused on the issuance process only

Everlasting Privacy
As previously explained, everlasting/unconditional privacy is a critical property that SHALL absolutely be a core requirement of the eIDAS 2.0 ecosystem.

[AEPDmbeltran]

On behalf of the Spanish Data Protection Authority (AEPD)

The attached document contains our comments on this topic.

topicG AEPD response.pdf

Thank you very much for this opportunity to contribute to this important discussion.

[ottomorac]

Good comments on the need for unlikability, this is a key feature that ZKP protocols should provide. Also the performance metrics are highly relevant as presummably many of these zk proofs would be generated directly on mobile devices. We think this is in line with many features provided by the Iden3 protocol as explained above.

Finally, agree that a mapping of zkp schemes would help the market to look at the different options and allow implementers to make a decision based on the merits / trade-offs of each one.

[phin10]

@AEPDmbeltran, thank you for your input to the discussion on topic G. Please find below the response of the @eu-digital-identity-wallet/arf-writers:

AEPD: As we have introduced in the discussion of previous topics, we think that it would be beneficial, from a data protection perspective, to separate two types of wallet use cases clearly: 1) use cases in which the user must identify themself to the Relying Party and 2) use cases in which the user must not identify themself to the Relying Party. To comply with the data protection by default requirement, we recommend considering the use of ZKP as a default for all transactions (in both groups of use cases), revealing identity data or relaxing the unlikability property, for example, only as needed by a specific use case (very likely, within the first group).

Response: In the discussion paper we have identified many use cases where ZKP should be used when it becomes available. These use cases cover both cases mentioned in your comment.

AEPD: We understand the mention of the required changes to support ZKP schemes (attestation format, issuance and presentation protocols) as a potential disadvantage of introducing these schemes in the ARF. However, if all actors in the EUDI wallet ecosystem comply with the data protection by design requirement, ZKP is going to be supported from the beginning in their products and services design. We can try to minimize the number of changes, or their scope, in relation to previous versions of the ARF so as not to incur an additional cost for those actors that that have already advanced in designs, prototypes, pilots, etc. But they are necessary changes to respect the rights and freedoms of citizens.

We interpret that attestation formats are still mDL and SD-JWT and that the changes contemplated here are the addition of new metadata or fields to these formats if necessary to support ZKP. Is that correct?

Response: Yes, the formats are still those specified in [ISO/IEC 18013-5] and [SD-JWT VC] and indeed new metadata fields must be added to the standards depending on the ZKP method used.

AEPD: Section 2 mentions “Additional privacy properties” for ZKP schemes (in addition to Selective disclosure, Relying Party unlinkability and Full unlinkability). It is not clear if this list is setting expectations for the ARF. Should the used ZKP schemes support all these properties? Are these desirable properties but not required by regulation? The relationship between this list and section 4.1, “Expectations from ZKP systems” must be clarified.

Response: This list is only informative. The properties that ZKP schemes SHALL or SHOULD support are provided in section 4.1.

AEPD: Furthermore, since the HLRs to be included in the ARF are based on this list of expectations, they must be carefully defined. We strongly recommend focusing this first discussion on deciding which properties must be guaranteed by the specified ZKP scheme

Response: That was the approach we followed. Please let us know if you have any comments for any of these HLRs.

AEPD: At the moment, we are missing at least two essential properties mandated by the regulation in section 4.1 and the HLR:

• Unconditional or everlasting privacy: The ZKP scheme should support this property (from eIDAS2 “(a) not allow providers of electronic attestations of attributes or any other party, after the issuance of the attestation of attributes, to obtain data that allows transactions or user behaviour to be tracked, linked or correlated, or knowledge of transactions or user behaviour to be otherwise obtained, unless explicitly authorised by the user”), ensuring data protection indefinitely, even if future advancements in computational power (quantum computing) or cryptographic techniques render current methods obsolete. Transaction logs shall not offer any opportunity to link the user or learn hidden attributes in any circumstance in the future. For example, this is particularly important in use cases concerning medical records or elections.
• Composite proofs: The ZKP should support this kind of presentation (from eIDAS2 “It should be technically possible for the user to selectively disclose attributes, including from multiple, distinct electronic attestations, and to combine and present them seamlessly to relying parties”), which is highly versatile for different use cases where multiple conditions must be verified simultaneously. Composite proofs can be designed to optimize the trade-offs between proof size, computational cost and verification time.

Response: Please note that the regulation does not mention “ensuring data protection indefinitely, even if future advancements in computational power (quantum computing) or cryptographic techniques render current methods obsolete” Protection against quantum computers should be considered as a whole and not specifically for attestation presentation. We believe that composite proofs are covered by requirements 1 and 3.

AEPD: Additional desirable properties such as blind issuance of attestations or repudiation capability (plausible deniability for both, issuance and presentation of attestations) or those mentioned in section 2 should be discussed to decide whether they are expected and new HLR are required.

Response: Blind issuance SHOULD be supported according to requirement 4. We did not identify any use case for repudiation capability during the focus group meetings.

AEPD: Performance baselines should also be included as HLRs because, otherwise, a ZKP scheme could guarantee all the established privacy properties but at a computational cost, storage overhead, or response times that are unaffordable for all or some us cases or devices. This could imply usability issues or the exclusion of most users for not having the proper device. What is considered acceptable for this ARF regarding these fundamental performance parameters?

Response: Requirement 5 is the requirement we agreed on during the focus group meeting with respect to performance.

AEPD: Once the expected properties are established and defined, a coverage map can be generated that clearly indicates which ZKP schemes meet each of these properties (always based on evidence since a theoretical evaluation is almost impossible I some cases, for example, concerning performance).

Response: This is the goal of TS4. Note however that currently no ZKP scheme meets all these properties.

AEPD: It seems that REQUIREMENT 8 “A Wallet Solution SHALL ensure that integrated ZKP schemes introduce minimal to the PID or attestation issuance process” needs to fix the wording. Introduce minimal changes, interference, overload? And, why only for the issuance process?

Response: This requirement has been re-worded to (Requirement 6): A ZKP scheme SHOULD be able to generate proofs for already issued PIDs and attestations in the formats specified in [ISO/IEC 18013-5] or [SD-JWT VC].

AEPD: Implementing ZKP schemes may require complex infrastructure at issuers and changes in the wallet units or some essential protocols. If not managed well, this additional complexity could introduce new privacy threats and risks that should be objectively assessed before adopting any solution. A good example is the new interactions that may be required between attestation issuers, wallet units, and RPs, a potential source of linkability.

Response: We agree with this statement and that was the motivation for Requirement 7.

[ad-Orange]

BBS# description

The_BBS_Sharp_Protocol.pdf

We have put together an updated document describing BBS# in more details. We think it should be added to the references (chapter 6) in the Topic G document.

[matteo-frigo]

I think there is a typo in Version 1, Requirement 1, NOTE. The text refers to function (vi) but only five functions are defined. I think you mean function (v).

[Sebastian-Elfors-IDnow]

Thanks for documenting ARF Discussion Topic G - Zero Knowledge Proof.

Please find below some comments that may be considered. More information about these comments can also be found in ETSI TR 119 476 v1.2.1.

Standardization of cryptographic algorithms and SOG-IS approval

In order for an eID scheme to reach LoA High according to EU CIR 2015/1502, in conjunction with Regulation (EU) No 1025/2012 on European standardization, the cryptographic algorithms need to be approved by the SOG-IS Agreed Cryptographic Mechanisms. Hence, one more requirement to be considered for the ZKP schemes is whether the cryptographic algorithms are approved according to the SOG-IS Agreed Cryptographic Mechanisms.

In relation to standardization of cryptographic algorithms, it could be mentioned that IETF CFRG is currently in the process of specifying BBS+ in the IETF CFRG BBS standard, whilst DIF is drafting a specification for blind signatures extension of BBS+. ISO/IEC has initiated the Preliminary Work Item (PWI) 24843 on privacy-preserving attribute-based credentials. One objective of ISO/IEC PWI 24843 is to formally standardize the multi-message signature scheme version of ISO/IEC 20008-2, i.e. BBS+. ISO/IEC are also working on the common draft ISO/IEC CD 27565 "Guidelines on privacy preservation based on zero knowledge proofs". More specifically, Annex C of ISO/IEC CD 27565 includes an example of selective disclosure by using BBS+, with a reference to the IETF CFRG BBS draft specification.

When it comes to zk-SNARKs, none of the zk-SNARK schemes are standardized yet, although some zk-SNARK schemes are based on hash algorithms that are SOG-IS approved.

The standardization aspect and the SOG-IS approval of cryptographic algorithms should be considered as a separate requirement in ARF Discussion Topic G - Zero Knowledge Proof.

zk-SNARK based solutions

In addition to the mentioned zk-SNARK solutions in [Fri2024] and [Paq2024], it could be worthwhile to also mention Cinderella (zk-SNARKs used with X.509 certificates) and zk-Creds (zk-SNARKs used with ICAO DTC).

Post-quantum safe ZKP schemes

For more information on plausible post-quantum safe ZKP schemes, it is recommended to study Annex A.1 (PQS zk-SNARKs) and Annex C.3 (Lattice-based anonymous credentials schemes ) in ETSI TR 119 476 v1.2.1.

Implementations in constrained devices

One more aspect to be considered is whether the ZKP can be implemented in constrained WSCDs, such as secure elements or SIM-cards. Example of a ZKP solutions that are suitable for constrained WSCDs is Keyed-Verification Anonymous Credentials (KVAC) and BBS#.

Other

There is a small typo: "IRTF Crypto Forum Research Group" should be changed to "IETF Crypto Forum Research Group".

[c2bo]

Minor nitpicks:

In relation to standardization of cryptographic algorithms, it could be mentioned that IETF CFRG is currently in the process of specifying BBS+ in the IETF CFRG BBS standard, whilst DIF is drafting a specification for blind signatures extension of BBS+

All 3 drafts for BBS (core, blind issuance, pseudonyms) have been adopted by the CFRG and are on track to become RFCs:

• https://datatracker.ietf.org/doc/draft-irtf-cfrg-bbs-signatures/
• https://datatracker.ietf.org/doc/draft-irtf-cfrg-bbs-blind-signatures/
• https://datatracker.ietf.org/doc/draft-irtf-cfrg-bbs-per-verifier-linkability/

There is a small typo: "IRTF Crypto Forum Research Group" should be changed to "IETF Crypto Forum Research Group".

IRTF (Internet Research Task Force) is correct here: https://www.irtf.org/cfrg.html

[Sebastian-Elfors-IDnow]

Ok, thanks for the clarifications.

[ad-Orange]

On version 1.0

As compared to previous versions
While we’re happy that plausible deniability was added also for the issuance process, we are still very disappointed to see that many of the proposals we made have neither been taken into account nor clearly rebutted in a way that would highlight why they wouldn’t make sense.
Of particular importance is everlasting privacy. It is a critical property for any recent ID framework as we believe that ensuring privacy protection even against unknown future technology advances is a mandatory feature and we don’t understand why it still does not appear anywhere.
We also don’t understand why minimization is not taken in a larger and more generic way than just range proofs.
We insist that we would like the last posted paper in this very thread to be taken as reference for BBS# and not the old technical report you currently take as reference.
We strongly believe that launching eIDAS without proper data protection provisions in place will be detrimental to the adoption of the wallet by European citizens and we definitively encourage to modify the document to take these requirements into account.
Finally we still don’t understand (and it is a growing concern) why the impacts are only assessed from the point of view of the issuers. This is does not make sense to us. We are missing a rational analysis and a clear explanation.

Requirement 10
The “proprietary” aspect of a solution shall be properly defined in order for the requirement to be properly understood and able to be taken into account. Otherwise it could lead to arbitrary decisions by whoever decides that something is “proprietary” or not.

Requirement 11
The first and very important remark here, is that a scheme supporting everlasting privacy would be immune to any privacy related attack on past (and future actually) transactions, whatever computer power the attacker has at disposal, and even if the user’s and/or issuer’s secret key is leaked. This would not ensure protection against forgery by itself but it would basically make sure that transactions can safely be done until the advent of PQC. There lies the importance of everlasting privacy.
Then, “supporting migration to post-quantum safe algorithms” is unclear, and once again, if not defined properly it could lead to arbitrary decisions by whoever decides that it applies to a particular ZKP scheme or not.
Finally, we also think that the migration ability to a post quantum safe protocol is absolutely undecidable at this point as:

1. We do not even know what the “post-quantum safe” algorithm that support ZKPs and user-binding simultaneously will be, not even if they exist in any implementable form.
2. From there on, it is obvious that we know even less what the associated constraints for migration will be and, once again, trying to setup rules now, while we don’t have a clue about the envisioned target, could only lead to bias and arbitrary decisions.

We already know that double signature at issuance and parallel infrastructures (if they are incompatible) between 2 types of schemes would be a way to migrate whatever the 2 protocols. We are really not sure what this requirement is trying to achieve and we think it shall simply be removed. On the contrary, important requirements such as everlasting privacy, that we know would actually start to be useful immediately, are still missing and shall be added immediately.

[DibranMulder]

Great to see that Zero Knowledge Proofs are being considered so carefully in context of the ARF. I have looked at the discussion paper and ETSI TR 119 476 v1.2.1. from @Sebastian-Elfors-IDnow I think it gives a good overview and helps to interpret the complex subject matter. The paper mentions CL signatures and citates Idemix and the IRMA project, I'm currently responsible for that project and I would love to help in terms of giving practical insights.

Might be good to know that we are currently exploring the following:

• Usage of Idemix credentials in SD-JWT and disclose them using OpenID4VP. We are currently trying to implement this using the European Reference Wallet libraries.

Furthermore I had one minor question about the requirements. All requirements except for Requirement 7 have the following or condition proximity-based or remote presentation flows. Requirement 7 uses an proximity-based and remote presentation flows statement, is this intended? One could argue that a ZKP scheme is only usable in remote presentation flows.

[ottomorac]

Hello Sir. Agree that the mention of the ETSI report is the right move. But why would you consider zkp only relevant for remote presentation flows? After all isn't one of the most classical zk use cases to prove your age to a bar tender without handing out your full credential? Or proving that you have a valid driving document and a low number of driving offenses to a police officer using zk?

I could think of other use cases where zkp might be relevant for physical flows even though the credential holder might be in physical proximity of the relying party.

[DibranMulder]

Hi @ottomorac you are right my last sentence was not correct, excuse me. I think both flows are relevant.

[ad-Orange]

The WUA MUST be managed through a ZKP scheme

As explained in this post, we do not see any other way than managing the WUA used for privacy sensitive (and then: why not for all ?) us cases through the ZKP schemes discussed in this topic. These include for instance majority / over 18 proofs which are eagerly awaited by some European governments and this is one of the (numerous) reasons why we think these ZKP schemes should be used already at the initial launch of the eIDAS wallet.
In order to clarify how a sound trust model could be implemented with this kind of multi-message signature schemes, we have described how a BBS# presentation flow would look like here.

[ad-Orange]

Proper sync with Topic V
We don't understand why similar debates are started again (in a different way and forgetting some of the protocols...) in Topic V. This should be addressed.

[therealyingtong]

Generic zk-(S)NARKs are the most effective long-term solution for anonymous credentials, and should be prioritised in the post-quantum upgrade path. This is not at odds with the use of BBS/BBS# signatures, which should be adopted in the immediate-term (as opposed to salted hashes).

The main capability enabled by generic zk-(S)NARKs, over less expressive signature schemes, is the decoupling of provable predicates from issued credentials. This has the advantage of being future-proof against:

• new credential formats (e.g. ES256, BBS/BBS#, issuance without signatures), without requiring changes to the issuer or the backend proof system; this is because any signatures would be a private input into our zk(S)NARK circuit, and verification would happen entirely within the circuit
• constraints in HSMs and secure elements: as before, the secure element need only produce a signature, which is then input to a zk(S)NARK prover outside the secure element;
• more complex predicates / private claims (e.g. geolocating an address, new revocation flows), without requiring additional work by the issuer. (BBS/BBS# already allows for a limited set of predicates, including range proofs.)

 Issuer                                   Holder                                   Relying party              
┌─────────────────────────┐              ┌──────────────────────────┐             ┌──────────────────────────┐
│                         │              │                          │             │                          │
│                         │              │                          │             │                          │
│                         │              │    priv:  σ, m           │             │                          │
│                         │              │            │             │             │                          │
│  m = {                  │              │            │             │             │                          │
│         name: ______,   │              │  ZKP.Prove ▼             │             │                          │
│         addr: ______,   │              │  ┌────────────────────┐  │             │                          │
│      }                  │              │  │                    │  │             │                          │
│                         │      σ       │  │  is_in_x(m.addr)   │  │   π, out    │                          │
│                         ├─────────────►│  │                    │  ├────────────►│    ZKP.Verify(π, out)    │
│                         │              │  │ is_valid_sig(σ,m)  │  │             │                          │
│  σ = Sign(m)            │              │  │                    │  │             │                          │
│                         │              │  │                    │  │             │                          │
│                         │              │  └─────────┬──────────┘  │             │                          │
│                         │              │            │             │             │                          │
│                         │              │            ▼             │             │                          │
│                         │              │  ┌───────────────────┐   │             │                          │
│                         │              │  │      π, out       │   │             │                          │
│                         │              │  └───────────────────┘   │             │                          │
└─────────────────────────┘              └──────────────────────────┘             └──────────────────────────┘

(Here is a link to the PNG file for the image above, with colored annotations)

There is a large existing ecosystem of digital identity solutions using generic zk(S)NARKs (e.g. World ID [1], Rarimo [2], Self [3], iden3 [4]), who are eager to work with the EUDI and standards bodies on the longer-term goals of:

• a suitably high-level specification of a zk(S)NARK proof system, described modularly in terms of their underlying components: arithmetisation, interactive oracle proof, and polynomial commitment scheme;
• performant provers and verifiers on mobile devices with limited computational resources (e.g. Mopro [5]); and
• integration with existing credential formats: for instance, abhi shelat and Matteo Frigo’s work on anonymous credentials from ECDSA [6], Microsoft's Crescent [7], and the Dorian proof system [8] were presented at the "Credentials and Signatures" session at RWC 2025.

A high-level specification of generic zk(S)NARKs is a top priority for the TS04 draft specification, and can build on ongoing efforts such as the ZKProof Standards working groups [9].

[1] “World ID by World - Digital proof of human for the Internet”. https://world.org/world-id
[2] “Rarimo - Permissionless (ZK) Registries”. https://rarimo.com/
[3] “Self - Future Proof Security”. https://self.xyz/
[4] “iden3”. https://iden3.io/
[5] “Mopro”. https://zkmopro.org/
[6] Matteo, F. and shelat, a. (2025). Anonymous credentials from ECDSA. Cryptology ePrint Archive.
[7] Woo, A. P., Ozdemir, A., Sharp, C., Pornin, T., & Grubbs, P. (2025). Efficient Proofs of Possession for Legacy Signatures. Cryptology ePrint Archive.
[8] Paquin, C., Policharla, G. V., & Zaverucha, G. (2024). Crescent: Stronger Privacy for Existing Credentials. Cryptology ePrint Archive.
[9] “ZKProof Standards”. https://docs.zkproof.org/standards

[therealyingtong]

TS04 is the technical specification for ZKP implementation in the EUDI Wallet: https://eu-digital-identity-wallet.github.io/eudi-doc-architecture-and-reference-framework/latest/technical-specifications/#technical-specifications

[ad-Orange]

We're not sure about the urge to put zk-SNARKs in TS04. If TS04 is about short term deployment, you seem to agree with us that BBS/BBS# is the way. The biggest risk to us is that eIDAS wallets would be deployed without a proper privacy layer, rather than not having a decision now on the best way to do PQ ZKP, especially since this area is extremely active and the current situation of PQ cryptographic mechanisms (that zk-SNARKs need to interact with) is not yet settled (let alone the subsequent zk-SNARKs themselves).

Indeed, solving for the plausible PQ ZKP challenge will need a few enablers to be in place before deployment can be envisioned, including:

1. Plausible PQ signature algorithms embedded (and certified) inside secure hardware (SE, HSMs, etc...)
2. The corresponding ZKP-layer with the best possible space and computing power characteristics
3. The certification (security and privacy proofs) of the ZKP layer
4. End to end standardization

For the long term PQ ZKP challenge, we note that at least 2 approaches can be envisioned:
A. Generic zk-SNARK (signature "independent", circuit based) as described in the post this answers to
B. ZKP friendly signature (same approach as BBS/BBS#)

Approach A theoretically allows for more versatility in proof types but is lacking in performance and the complexity of the “circuits” it uses generates a lot of variety. Competing proposals with papers coming out weekly optimizing one aspect or balancing them anew, sometimes without complete formal security or privacy proofs. As a result, it’s even less mature than approach B and the maturity of both is still questionable at the very least. Worst of all, none of these solutions is close to being widely available in secure elements or even HSMs at wide scale, much less easily amenable to a large variety of use cases.

To say it in another way, between A and B (is there a C?), the jury is still out, and rightfully so.

What is clear is that points 1 to 4 are far from ready/mature (each of them). Thus, while we agree that a plausible PQ ZKP scheme shall be sought for in the long term, this would not constitute a realistic target for the short term launch of eIDAS. On the contrary, we think that BBS/BBS# is the best compromise and only realistic solution to get both security and privacy in the short term and it should therefore be the priority for TS04.

[matteo-frigo]

Hi @ad-Orange .

(Speaking for myself.)

Although I am one of the authors of [6] and I believe, for a variety of reasons that we don't need to get into here, that some variant of [6] is the only thing that will work for EUDI wallets in today's world, even independently of any PQ considerations, I also happen to have a lot of respect for your BBS# work, which I regard as a serious contender. In contrast, I view non-sharp BBS as a non-starter.

Since I have you here and you mentioned HSMs, I am unclear regarding which requirements BBS# places on HSMs. BBS# cleverly re-purposes the ECDSA signature of the WSCD. Does a similar phenomenon occur on the issuer's side or do you need special BBS# support in the HSM? Concretely, if I wanted to implement a BBS# issuer today with today's HSMs, could I do it?

[ad-Orange]

Hello @matteo-frigo

There is indeed no magic way of avoiding implementing BBS+ as a signature algorithm in the issuer HSM. However, the computing complexity is about the same as ECDSA and leveraging the same basic operations (in particular scalar multiplications on a standard elliptic curve). For supporting PQ safe signatures on the other hand, the gap is much bigger with a different kind of primitives to be implemented.

The lack of decision on a clear path forward is impairing a quick widespread adoption of a privacy preserving solution and while the data protection question has been raised for quite some time already it has only been recently tackled seriously, delaying the advance of the ecosystem.

[therealyingtong]

A generic zk-(S)NARK is not an issuance mechanism in itself, and should instead be understood as a privacy-hardening layer on top of an underlying issuance flow (e.g. ECDSA; BBS/BBS#; inclusion in a Merkle tree). They can be integrated as a verification pathway in the wallet unit, without requiring changes to the issuer or holder's secure element.

For TS04, we propose to include a high-level description of the components of a zk-(S)NARK (arithmetisation, polynomial interactive oracle proof, Fiat-Shamir transform [1], and polynomial commitment scheme), and how to securely compose them. Since this is agnostic to the underlying signature scheme, its specification can be done in parallel.

Although generic zk-(S)NARKs are lagging in standardisation, they are already widely deployed, and it is reasonable to aim for a high-level specification for TS04. We list here a few implementations of zkID systems compatible with legacy issuance mechanisms:

• Aptos Keyless [2], which supports RS256 + JWT parsing;
• zkLogin [3], which supports RS256 + JWT parsing;
• Self [4], which supports ECDSA/RSA + SHA1/SHA2 + passport DG1 parsing; and
• Rarimo [5], which supports ECDSA/RSA + SHA256 + passport DG1 parsing.

[1] Orrù, M. (2025). "Fiat-Shamir Transformation specification". Available at https://mmaker.github.io/draft-zkproof-sigma-protocols/draft-orru-zkproof-fiat-shamir.html
[2] Aptos Labs: Aptos Keyless (2025). Main circuit:https://github.com/aptos-labs/keyless-zk-proofs/blob/4d43a58363561138274baa20efe4666eb24570a1/circuit/templates/mainTemplate.circom
[3] Baldimtsi, Foteini, et al. "zklogin: Privacy-preserving blockchain authentication with existing credentials." Proceedings of the 2024 on ACM SIGSAC Conference on Computer and Communications Security. 2024.
[4] Self Protocol (2025). https://github.com/selfxyz/self/blob/5c450285c48e66cbea3ed3a9e103beaf5a275725/circuits/circuits/register/register.circom
[5] Rarimo: Privacy First Social Protocol (2025). PassportVerificationBuilder circuit: https://github.com/rarimo/passport-zk-circuits/blob/f1a0835b9ac433b2b7cd2a622ec5a7b83d84246d/circuits/passportVerification/passportVerificationBuilder.circom

[burdges]

Just fyi, Zero-knowledge is typically omitted from FRI or subcheck based "zk proofs" for performance, likely this covers almost all STARKs deployments, Ligero, etc. Auditors should carefully check any claims of zero-knowledge by these. See https://eprint.iacr.org/2024/1037 or https://www.youtube.com/watch?v=_A6uhQ2q_0M These proofs sound too large for identity applications anyways, so maybe not a concern, but they may come up when discussing legacy credentials.

Groth16 deployments almost all have zero-knowledge, because afaik they cannot really save anything by not being zero-knowledge. As an aside, identity applications often benefit from the rerandomizability that only Groth16 offers, ala https://eprint.iacr.org/2023/002 or https://eprint.iacr.org/2024/2013. Groth16 is disliked by many zk implementers because of the circuit specific trusted setup, which creates a trust problem for smart contract workflows, but circuit specific trusted setup ceremonies are obviously fine for a government id system.

I'd expect bulletproofs usually have zero-knowledge, because they seem useless without zero-knowledge. I've no idea about Plonk deployments, but zero-knowledge should be cheap for the pairing based ones.

[matteo-frigo]

This is perhaps too pedantic, but I think that the current text leaves the impression that [Api2025] is an improvement on BBS#, which is false. In fact, [Api2025] explicitly ignores device binding (see [Api2025, Footnote 3]), whereas solving device binding in a BBS-like protocol is the great insight of BBS# and the main reason why BBS# is interesting for EUDIW in the first place.

[ad-Orange]

@matteo-frigo , thanks a lot for pointing that out and we obviously agree.

However, there is more. Even leaving out the point mentioned by @matteo-frigo , we still think that what is written in chapter 3.1.1 does not reflect the reality,.
In fact, [Api2025] generalized, formalized and analysed a specific mode of BBS# protocol (but ignores device binding as you rightly pointed out @matteo-frigo), that they called « Server-Aided Anonymous Credentials » (SAAC for short). But contrary to what's written in chapter 3.1.1 we already proved the security of BBS#, and also shown that BBS# provides full unlinkability and statistical anonymity / everlasting privacy in the paper posted above in this thread and the very nice results in [Api2025} just confirm these properties of BBS# (in its SAAC mode).

[ad-Orange]

Given the exchange with @matteo-frigo just above, we feel that there are several misunderstandings regarding the BBS# proposal and we went through all the document and now want to raise issues for things that previously looked benign to us.

1. Why is the reference to our latest paper called [Ora2024] and not [Ora2025] ?
2. Why do you not link to the paper that we posted in your own GitHub discussion area, even in the same topic (3 weeks ago…) while you’re linking all the other (eprints) ? In order to ease the readability of the discussion paper, we suggest to add the link related to our last paper
3. As explained above and contrary to what we think you understood, the paper we linked in this topic (cf point 2.) does include updates to the paper that was proposed almost a year ago (that’s why we posted a new paper) and this new paper does not mandate the holder getting a token from the issuer for each transaction and does comply with Req7, which seems very much targeted at the old paper. Finally, for the avoidance of doubt, please note that this new paper was posted on the GitHub before the nice paper [Api2025].
4. In chapter 3.2.1, you writeAdditionally, PID Providers or Attestation Providers often mandate that attestations be device-bound, integrating secure elements into the authentication process. This further complicates adoption, as multi-message signature schemes would necessitate either updates to both hardware secure elements and operating systems across all user devices, or additional interactions between Wallet Units and PID Providers or Attestation Providers. We disagree with these points. As explained in the very paper [Ora2024] that you list in your topic G document (chapter 6, references), with BBS# there is no need to update neither the SE nor the OS and interactions can as well be between the RP and the issuer, all while complying with Req7.
5. This is a minor nitpick but in chapter 3.2.2 you mention Range Proofs as an example for generic minimization proofs that are achievable with zk-SNARKs. While it is true that very efficient Range Proofs can be implemented with zk-SNARKs, it is also the case for BBS class protocols (as well as Set Membership Proof). So, if the goal is to truly highlight the superior minimization power of zk-SNARKs, it would be better to identify use cases requiring other type of minimization proofs that are not easily achievable with BBS class protocols.
6. In chapter 4.1.2, you write that For this use case, a suitable rate limiting mechanism shall be used in order to prevent users from re-using an attestation in a malicious way. The fact that a user shall authenticate to the WSCD before generating a proof is such a suitable mechanism. Well, to us, in a sane trust model, ANY proof generation by the holder shall be associated to a holder binding proof. What did we miss ?
7. In chapter 4.5, you write that Other schemes, such as BBS#, may require pre-computations that involve communication between a Wallet Unit and a PID Provider or Attestation Provider, before a proof can be generated. This is not entirely true (similar to 4.): it does not require pre-computation and the communication can be between the RP and the issuer and it still complies with Req7…
8. You make Issuer Hiding mandatory (Req1(v)). To the best of our knowledge, the most efficient solutions for that require the use of pairings, which as explained here (see the “Hardware Support and Cryptographic Functions” part) would prevent a rapid deployment with the current SE footprint (and we agree with that). See for example our recent contribution on this topic (Compact Issuer-Hiding Authentication, Application to Anonymous Credential). How do you envision it being implemented ? If this is as difficult to implement as we envision, it would require identifying corresponding benefits in use cases. We didn’t see any such justification in the Topic G paper but might have missed something.
9. On the contrary, we see that in Req3, you mention A ZKP scheme SHOULD support the privacy-preserving binding of an attestation to a PID. This requirement shall be mandatory and not optional (SHOULD in this require shall be replace by SHALL). Most transaction will involve the attestations being linked to a (valid) PID.
10. Finally, in Req8, you mention that A ZKP scheme SHALL rely solely on algorithms standardised by a standardisation organisation recognised by the Commission or in a standard recognised by the Commission. We had the impression (but might be wrong) that the IETF is not in such a list. Yet, you reference one of its RFC in chapter 1.3 of this discussion paper. Did we miss anything ?

Furthermore, it seems that in this version (1.4) that we hope is not the final one based on the various comments made, there still is no mention of everlasting/unconditional privacy, which is completely paradoxical for us as it is the only way to ensure that transactions made now will be privacy protected forever against any sort of attack, even if the attacker gets access to the private key of the holder, or if the attacker has an unlimited computing power (including quantum capabilities). This is all the more surprising that other features that seem much more benign like Issuer Hiding are mandatory (SHALL used in the statement).

All these points taken separately look like errors, however taken together give the impression that all inputs are not taken into account in the same manner, which would not be fair.

[mahesh-nag]

[Google Feedback] Google has reviewed this topic and is supportive of the proposal to incorporate ZKP systems as a component of the EUDIW architecture. We agree with the considerations around performance, and compatibility with existing attestation formats and attestation issuance infrastructure.

[OBIvision]

Welcome to the discussion on the Zero knowledge Proof, part of the ongoing development of the Architecture and Reference Framework (ARF) for the European Digital Identity (EUDI) Wallet.

This discussion is part of a structured process to refine and complete the ARF, with your input playing a vital role. We invite you to share your comments, insights, and suggestions here. Your contributions will be carefully reviewed and considered as we work towards the next version of the ARF, which will incorporate updates on this topic.

Thank you for participating in this important conversation.

Thanks for publishing this document and open for discussion.

My overall comment is essential.

Many in the identity sphere overlook the basics that Qualified Unlinkable signatures represent the essence of eIDAS 2.0 - everything else is secondary as this is the critical principle that aligns the many legitimate requirements on digital processes.

Cybersecurity, anti-crime, research, market/autonomy and fundamental rights all depend on the availability of qualified unlinkable signatures as the default. This is not new as already the Data Directive of 1995 defined data minimization, purpose-specificity and the necessity principles as core just as eIDAS 1.0 defined pseudonym signatures as a must-carry. The basic problem is that without good digital implementation all process based on these core technologies fail.

These issues are not resolved by plastering zk-proofs as lip service on top of an inherently illegal and counter-productive surveillance structure which seems to be the agenda of ARF given the many surveillance-centric use cases that could be upgraded to legal structures.

1. You cannot within the published protocols establish qualified unlinkable identity for trustworthy secure society processes. This is not a criticism of zk nor excluding future evolution can solve the problems, but merely realizing that the set of requirements for basic identity exceed what the zk-protocols documented here can provide today.

Two main problems:
a. Some critical optional requirements are inherently not supported such as e.g. accountability (whether linkability of one transaction to a root identity or linkability of a larger set of transactions in case of severe crimes).

b. The zk-universe is unable to support unlinkability at issuers which is criticial as most data and proofs inherently originate with an RP that require enrollment using unlinkable signatures. Even BBS# assume a shared identifier across providers but have no way to establish assurance that this is not used to link transactions or mix or conflict credentials of different citizens (identity lending or renting).

2. To solve these problems we need to look at the issuance processes itself.

Maintaining integrity unlinkable across many issuers of credentials across many providers of technology is a nightmare that eIDAS specifications are not even close at providing in zk. Secondarily is the ability to establish and maintain integrity across one provider.

Two main approaches:
I. A solution addressing the core of the problem is solving the linkability problem in PKI itself. PKI is not incompatible with unlinkablity as pseudonym certificate (unlinkable PID certificates), QSCD-issuance of new keys and atomic credentials are already standardized. What remains is to design unlinkable certification of new keys and resolve the question of accountability given unlinkablity.

II. Upgrade the set of zk proofs and constructs to deal with the omissions. This require discovery of new mechanisms.

[ad-Orange]

I'm trying to decipher what you mean. First I'll try to define what "qualified unlinkable signature" mean.
Does it mean issuer's signatures that are:

• high from a security point of view
• unlinkable across presentations including if issuers collude with verifiers

Then in a. I understand that in some situations, you want to remove unlinkability. Being able to completely remove unlinkability means that you can't have everlasting privacy from the onset. But it's doable even with protocols of the BBS family (including BBS#) by using classical techniques such as “verifiable encryption”.

Then in b. you seem to kind of imply that there is no "unlinkability at issuers" with the current set of ZKP technologies. At least for BBS#, this is wrong. You can very well provide a different public key for each VC you ask issuers to issue, so that, in the very rare cases when you don't need to show your PID for the service needs, you're unlinkable across different issuance events, even within the same issuer.

Given the above, I'm not too sure what other problems you want to solve on the trust and privacy models. You can always add more requirements for convenience or extended scope, but for the core trust model, I'm not too sure what you are missing here.