Privacy shall be at the heart of ARF

[GSMA-EIG]

Context: Guaranteed privacy of the EU citizens is a major concern for EC. The comments is related to privacy and request to update ARF to ensure EU citizen privacy when using the EU ID Wallet.

Issue: There is no mechanism in ISO mDL that ensure full privacy. This standard is not sufficient to ensure unlinkability and as such Data Minimization. SD-JWT doesn’t manage unlinkability or ZKP (zero-knowledge proof). These 2 protocols do NOT allow proper data minimization and therefore should be replaced by the necessary tools and protocols enforcing unlinkability and data minimization.

Proposition: To ensure Privacy, Data Minimization that includes Selective Disclosure and Unlinkability shall be added in the ARF. We propose to add the definition of Data Minimization in the ARF and to add requirements on anonymization for PID and (Q)EEA. A section dedicated to privacy is needed in the ARF as in ISO/IEC 23220-1, section 5.2. This paragraph shall define Unlinkability and Data Minimization and requirements related to privacy

[Sakurann]

Both MSO and SD-JWT support selective disclosure. Unlinkability for MSO and SD-JWT can be reached by issuing multiple copies of the same credential so that a different credential can be used per Verifier. This way, Verifiers cannot correlate the user even if they collude. Selective Disclosure and Unlinkability can be achieved without necessarily using advanced cryptography like ZKP.

[GSMA-EIG]

There are multiple related reasons why we advise against relying on such a “multi-VC” mechanism: • This significantly and unnecessarily increases the complexity of the design and increases the load (for reference, the attached document illustrates the challenges faced by the Netherlands government when trying to ensure privacy within these constraints; in conclusion it advocates for the use of BBS+) [NL DOCUMENT Attached] • This creates a situation where VCs are issued and managed on behalf of a citizen without them being in control of the process. This is not aligned with security and privacy as core values for EUDIW. • This might create additional UX burden for the end user once the “stock” of existing VCs for a particular need is exhausted on the wallet

In summary, given the long-term implications of the infrastructure design for eIDAS 2.0, and in the absence of any legacy considerations, we strongly advise against a method with such drawbacks. Further details on this issue and other eIDAS 2.0 privacy related topics can be found in the attached paper. [PRIVACY PAPER Attached].

NLW-Design-Considerations-v1.0.3-for-release.pdf GSMA Official Response - Privacy for eIDAS - June 2023.pdf

[confiks]

Unlinkability can be achieved without necessarily using advanced cryptography like ZKP

Only (ECDSA) signature unlinkability between colluding RPs. Issuers can collude with RPs to link the issued signature to a verification session. Idemix and BBS+ also prevent such 'issuer linkability'.

[Sakurann]

First, Credentials and Cryptographic keys are already managed by the "wallet" on behalf of the End-User, even without "multi-VC" approach.

Idemix, BBS, etc. are great, and probably will be the solution in the long-term, but they need to undergo review of the IETF CFRG so that they can pass reviews of the crypto boards and be deployed at scale. Also HW modules do not support these new algorithms/curves (yet), so when HW bound keys are important for high assurance scenarios (like government-issued credentials), conventional curves become the current way to go.

[GSMA-EIG]

"First, Credentials and Cryptographic keys are already managed by the "wallet" on behalf of the End-User, even without "multi-VC" approach.". This part is not completely clear. We agree that the users need to trust the wallet for their private keys and we believe this would be done by ensuring no party can gain sight of the user’s private keys. Indeed we assume that the following reference to hardware bound keys being necessary for security relates to the concern of ensuring no party can gain sight of the user’s private keys. Privacy concerns still stand as part of the end-to-end design of the ecosystem which we think can effectively be mitigated with BBS+ based solutions. The fact that the wallet “sees” all user activities does not create a particular privacy risk as wallets will be certified and following the drive of the commission, for the most part, open source. Furthermore, the use of BBS+ solves other privacy issues than the ones related to the wallet (e.g. issuers or relying parties or both colluding for tracking).

“HW modules do not support these new algorithms/curves (yet), so when HW bound keys are important for high assurance scenarios (like government-issued credentials), conventional curves become the current way to go." Indeed on-device hardware-bound keys are not ready to be used with BBS+ algorithms. We are not really sure why it prevents BBS+ use even for "high" eIDAS scenarios, as there is no public information about the scheme yet. We do not understand that on-device hardware-bound keys are mandatory to achieve "high" eIDAS scenarios.

Overall we would like to understand if the main concern raised is that BBS+ is unnecessary (https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework/issues/66#issuecomment-1603749996 ) or not possible to implement (https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework/issues/66#issuecomment-1611711047 ) .

We also believe that short-term considerations should not prevent the industry from innovating to deliver an ecosystem that will last for years or even decades, especially on privacy which is key success factor for eIDAS 2.0.

[paulbastian]

While Idexmix/Anoncreds offer great privacy features they lack:

• final standardization
• acknowledgment by regulators
• cryptographic agility
• potential to move to PQC algorithms
• support for hardware-backed keys

Hardware-backed keys are needed to protect against credential duplication which is one of the attack vectors that you need to cover to achieve LoA high. Thus, there seems no way to use Anoncreds/BBS+ for high assurance use cases given the current technology.

[GSMA-EIG]

While Idexmix/Anoncreds offer great privacy features they lack:

• final standardization
• acknowledgment by regulators
• cryptographic agility
• potential to move to PQC algorithms
• support for hardware-backed keys

Hardware-backed keys are needed to protect against credential duplication which is one of the attack vectors that you need to cover to achieve LoA high. Thus, there seems no way to use Anoncreds/BBS+ for high assurance use cases given the current technology.

RESPONSE: Let's consider and review the individual claims:

• Final standardization: True. BBS+ is in advanced draft at the ietf in particular, but not final. BBS (same cryptographic underpinnings as BBS+) and several variants of it are however ISO standardized (ISO/IEC 20008-2) and already deployed in hundreds of millions of TPM and Intel SGX enclaves and in some existing wallets. Also, we note with interest that in [https://edi.pleio.nl/file/download/f316c8d9-b048-4dc9-a520-f5f5ab55c605/nlw-design-considerations-v1.pdf] BBS+ is considered a "valuable alternative". Standardisation is not considered as an open issue. . PQC algorithms mentioned later are not standardized either.

• Acknowledgement by regulator: True but not yet. The reasons therefore are not fundamental (except maybe for PQC, more on that later) and in particular, BBS+ is formally proven secure (reference link https://eprint.iacr.org/2016/663.pdf) with no cryptographic flaws proven on these algorithms that exist for more than 20 years. Furthermore, the PQC algorithms are not standardised nor accepted by the regulators either.

• Cryptographic agility: A clear definition of cryptographic agility is still unknown. Nonetheless, some less efficient algorithms than BBS+ with similar properties exists and could replace it in case of a breach: Idemix, CL, PS, etc. so that this claim of lack of "cryptographic agility" for BBS+ like algorithms would need to be substantiated further. Also, if used only as a "classic" signature algorithm and not as an enabler to ZKP, BBS+ is easily swappable with any other signature algorithm.

• Potential to move to PQC algorithm: If the fundamental crypto behind BBS+ gets broken (not just a particular implementation that would require only a software patch) e.g. through the advent of quantum computing, then it is very likely that algorithms like ECDSA and ECSchnorr would be broken at the same time as they rely on very similar underlying mathematical problems. Furthermore, the currently considered algorithms like ECDSA (used in mDL) are not PQC either so it is not really clear what would be lost by moving to BBS+. Finally,, BBS+ offers "everlasting privacy", meaning that even if it got broken (e.g. through quantum computing), the past transactions would remain private forever; a fraudster could only forge falsified Verifiable Credentials. Many of the currently proposed PQC algorithm (and clearly neither ECDSA nor RSA) do not possess this property which is arguably way more important at this stage than PQC for which algorithms are much less mature and standardised than BBS+. How the use of BBS+ could prevent a "potential move to QPC algorithm" is not really clear; indeed it is not clear how the use of any specific algorithm could prevent the "potential move to QPC algorithm".

• Support of hardware backed keys: current SEs on smartphones or in external hardware tokens do not offer BBS+ or the necessary underlying mathematical enabling function to implement it. However, it does not prevent its use in HSMs. Furthermore, GSMA members have already prototyped the implementation of BBS+ on old SIM cards with very satisfying results as indicated in the GSMA paper linked above in this thread, meaning the implementation of BBS+ in SE is a matter of time and political willingness, not an impossibility. As mentioned above, before that happens, HSM can be used. Generally, the comments made here relate to the balancing act of taking into account short term implementation constraints vs securing the right place for privacy that is a fundamental right of European citizens, especially for such a sensitive object as a universal ID wallet. If privacy is taken seriously, the necessary processes can be accelerated; such agility was demonstrated in response to the Covid-19 crisis.

[earizon]

I don't think the multi-VC approach is such a complex solution. As I see it, it can be approached using the intuitive idea of a "proxy".

In this case, next to the original issuer, we place a issuer "proxy". The proxy unconditionally and in real time (synchronously) emits new custom VCs as soon as the original VC is provided. The wallet on-demand requests new proxy VCs and use them to present to third party relying parties. This on-demand process is completely transparent to the user.

This proxy scenario also allows the original issuer to control the usage of identities. With some minor "tuning" this pattern/protocol opens the way for new sort versatile methods of security protective measures. For example, the wallet can attach in the VC-proxy request the purpose for the VC proxy emission ("buy", "identify", "travel", ...) The an e-commerce related relying party will validate that the presented "proxified" VP has the requested attributes (older than 18) and also the "buy" purpose.

The attached "buy" purpose does not leak any personal information, since no money, asset or quantity is attached. It acts sort of a OAuth scope but if simplifies anomaly detections:The issuer proxy can easily detect time-series anomalies (wallet was stolen) and block the issuance or even notify the original owner.

The wallet can even tell to the Issuer proxy "I want a VC telling that I'm older than 18 to be presented to this relying-party". The issuer-proxy can have extra intelligence to fetch the needed extra attributes and issue them automatically. In this regard, the proxy becomes "intelligent". We are creating a mesh-network of issuers and relying parties following the same proxy pattern used for mesh networks and HTTP services (think of an Istio/Envoy proxy for the Identity network). Wallets delegate their intelligence to the proxies, making their design much more simple. Other unrelated problems get also fixed. For example, a wallet was issued an ID credential when the user was "close to 18, but still younger than 18". A few months later, the user needs to request a new ID credential since now he is older than 18. This is probably an slow process/procedure (bio-metric/physical prensence/...). We can skip this new "slow" process/procedure by requesting the "I'm older than 18" to issuer-proxy (vs issuer) instead, and considering that the issuer-proxy is intelligent enough to compare the issuance date of the original VC, the current date and finally decide that user is now older than 18, emiting a new proxy VC and so skipping the slow bio-metric/... procedure.

Certainly, network and computation resources are duplicated, but they are still quite small (when compared to standard apps as Gmail, Facebook, video-games,...) and even supported by IoT devices. This is quite similar to the duplication of resources in mesh networks with side-car proxy containers. Also, the extra proxy-intelligence can avoid resource consumption in other ways, as it is the case with the previous "older than 18" VC example.

Notice also that this zero-knowledge use-case apply to corner scenarios, since in normal scenarios, the relaying-party is obligated by law to known the real identity of the user.

[GSMA-EIG]

RESPONSE: We believe that this kind of solution would neither solve the privacy issue in hand nor be a “simple” solution. In fact it raises more questions than offering solutions.

Most importantly, it doesn’t seem to resolve the privacy issue: the “proxies” would be in a position to track the real time actions of each citizen (as opposed to the model where once a VC is issued, the visibility is restricted only to the wallet. This would mean that neither the issuer nor anyone else can track the use of this VC throughout the ecosystem as proposed in our ZKP/BBS+ approach). It would be helpful to get some clarity on the issuer “controlling” the usage of identities as it seems to challenge the concept of privacy and SSI sought for by the eIDAS community. The privacy goals we are trying to achieve here might be unclear but this sentence “The wallet can even tell to the Issuer proxy "I want a VC telling that I'm older than 18 to be presented to this relying-party.” goes against the fundamental principle of the issuers and verifiers being unaware of one another’s activities related to a particular customer.

Secondly, these “proxies” would never be an easy actor to integrate in the ecosystem. Firstly, it would force a model where the transactions can only ever be online. Secondly, it is a structuring revamp of the architecture model of the ARF that raises a lot of questions about responsibility, security and not least business models. Furthermore, the claimed improvements remain to be proven and analyzed for ramification. This proposal is more linked to architecture than privacy and we would therefore suggest moving it in a more appropriate thread.

I don't think the multi-VC approach is such a complex solution. As I see it, it can be approached using the intuitive idea of a "proxy".

In this case, next to the original issuer, we place a issuer "proxy". The proxy unconditionally and in real time (synchronously) emits new custom VCs as soon as the original VC is provided. The wallet on-demand requests new proxy VCs and use them to present to third party relying parties. This on-demand process is completely transparent to the user.

This proxy scenario also allows the original issuer to control the usage of identities. With some minor "tuning" this pattern/protocol opens the way for new sort versatile methods of security protective measures. For example, the wallet can attach in the VC-proxy request the purpose for the VC proxy emission ("buy", "identify", "travel", ...) The an e-commerce related relying party will validate that the presented "proxified" VP has the requested attributes (older than 18) and also the "buy" purpose.

The attached "buy" purpose does not leak any personal information, since no money, asset or quantity is attached. It acts sort of a OAuth scope but if simplifies anomaly detections:The issuer proxy can easily detect time-series anomalies (wallet was stolen) and block the issuance or even notify the original owner.

The wallet can even tell to the Issuer proxy "I want a VC telling that I'm older than 18 to be presented to this relying-party". The issuer-proxy can have extra intelligence to fetch the needed extra attributes and issue them automatically. In this regard, the proxy becomes "intelligent". We are creating a mesh-network of issuers and relying parties following the same proxy pattern used for mesh networks and HTTP services (think of an Istio/Envoy proxy for the Identity network). Wallets delegate their intelligence to the proxies, making their design much more simple. Other unrelated problems get also fixed. For example, a wallet was issued an ID credential when the user was "close to 18, but still younger than 18". A few months later, the user needs to request a new ID credential since now he is older than 18. This is probably an slow process/procedure (bio-metric/physical prensence/...). We can skip this new "slow" process/procedure by requesting the "I'm older than 18" to issuer-proxy (vs issuer) instead, and considering that the issuer-proxy is intelligent enough to compare the issuance date of the original VC, the current date and finally decide that user is now older than 18, emiting a new proxy VC and so skipping the slow bio-metric/... procedure.

Certainly, network and computation resources are duplicated, but they are still quite small (when compared to standard apps as Gmail, Facebook, video-games,...) and even supported by IoT devices. This is quite similar to the duplication of resources in mesh networks with side-car proxy containers. Also, the extra proxy-intelligence can avoid resource consumption in other ways, as it is the case with the previous "older than 18" VC example.

Notice also that this zero-knowledge use-case apply to corner scenarios, since in normal scenarios, the relaying-party is obligated by law to known the real identity of the user.

[earizon]

RESPONSE: @GSMA-EIG

Just an small clarification, the VC proxy "idea" does not compete with ZKP/BBS+. While a ZKP solution is the "ideal solution", the concept of proxy VC plays the role of "supporting utility". It can fix some privacy problems in the absence of a fully working ZKP, or in cases where there is some usability problem with ZKP in scenario. My intuition tells me that it could even simplify ZKP in some contexts.

Most importantly, it doesn’t seem to resolve the privacy issue: the “proxies” would be in a position to track the real time actions of each citizen (as opposed to the model where once a VC is issued, the visibility is restricted only to the wallet.

I don't think so. A proxy can only trace statistics about how many times a user wants to hide some personal data in the presented VC, without revealing anything else. This can not be perfect from the point of view of pure cryptography, but it will be from the point of view of laws and regulations.

this sentence “The wallet can even tell to the Issuer proxy "I want a VC telling that I'm older than 18 to be presented to this relying-party.” goes against the fundamental principle of the issuers and verifiers being unaware of one another’s activities related to a particular customer.

This is an example on how a proxy can simplify the work of "light" wallets and obviously it breaks privacy. I mention it as an example on how a VC proxy could be used as supporting utility. It is "good enough" when the user is just concerned in not revealing personal data to the verifier, while it doesn't care that much about the VC proxy knowing about the "visited site". And since PID data is delegated to trusted national bodies under the control of Conformance Assessment Bodies it is a sensible decision to think that VC-proxy issuers can be considered "trustable enough". This trust is in contrast to standard Web Proxies and DNS public servers under the control of Google, Akamai, Telcos and the likes with economic incentives to break the user privacy and link the activity of a given user in different sites.

Secondly, these “proxies” would never be an easy actor to integrate in the ecosystem. Firstly, it would force a model where the transactions can only ever be online.

Not really, the wallet just need to have a minimum logic to have a growing queue of prepared proxy-VCs to be used "later on", either on-line or offline, adding a minimum extra logic such as:
"once the wallet presents the last-but-one free proxy-VC to a verifier, try to refill the buffer online".
With such a simple algorithm the user can present two consecutive proxy-VC to two different verifiers while offline. Only if a third proxy-VC is needed while still offline, the verification process will be blocked or the user will be forced to reuse a proxy-VC with a "used"/"tainted" signature. I guess this is quite a pessimistic and unrealistic scenario.

Edit: This proxy-VC can also fix security issues with did:key like distributed VC. Such credentials are only stored in the user's wallet (vs any de/centralized ledger) and once issued, revocation becomes very difficult. Ad-hoc mechanisms can be used to let verifier query the issuers (just online) about the revocation status, revocation lists can be redistributed (but they can become big and difficult to manage). The proxy-VC pattern can be used in this case as a "simpler" alternative that can still be used offline. A verifier will just accept proxy-VCs with a sort "life-time".

All problems in computer science can be solved by another level of indirection," Butler Lampson, 1972

[GSMA-EIG]

This proposal undoubtedly has a lot of architectural (and other) impacts, including privacy, but probably not primarily privacy. We think it should be discussed in its own thread as it seems only lightly linked to the initial proposals and remarks made in this thread.

[wbl]

The absence of the SOG-IS is just a self-inflected excuse: if this is really important, they can do their jobs. Likewise the CFRG assessment can go faster, if it's going to be used, and it's not like the EU doesn't have cryptographers qualified to assess it.

The fact that SD-JWT is being considered despite not meeting the security property required is disappointing.

[paulbastian]

While Idexmix/Anoncreds offer great privacy features they lack:

• final standardization
• acknowledgment by regulators
• cryptographic agility
• potential to move to PQC algorithms
• support for hardware-backed keys

Hardware-backed keys are needed to protect against credential duplication which is one of the attack vectors that you need to cover to achieve LoA high. Thus, there seems no way to use Anoncreds/BBS+ for high assurance use cases given the current technology.

RESPONSE: Let's consider and review the individual claims:

• Final standardization: True. BBS+ is in advanced draft at the ietf in particular, but not final. BBS (same cryptographic underpinnings as BBS+) and several variants of it are however ISO standardized (ISO/IEC 20008-2) and already deployed in hundreds of millions of TPM and Intel SGX enclaves and in some existing wallets. Also, we note with interest that in [https://edi.pleio.nl/file/download/f316c8d9-b048-4dc9-a520-f5f5ab55c605/nlw-design-considerations-v1.pdf] BBS+ is considered a "valuable alternative". Standardisation is not considered as an open issue. . PQC algorithms mentioned later are not standardized either.

• Acknowledgement by regulator: True but not yet. The reasons therefore are not fundamental (except maybe for PQC, more on that later) and in particular, BBS+ is formally proven secure (reference link https://eprint.iacr.org/2016/663.pdf) with no cryptographic flaws proven on these algorithms that exist for more than 20 years. Furthermore, the PQC algorithms are not standardised nor accepted by the regulators either.

• Cryptographic agility: A clear definition of cryptographic agility is still unknown. Nonetheless, some less efficient algorithms than BBS+ with similar properties exists and could replace it in case of a breach: Idemix, CL, PS, etc. so that this claim of lack of "cryptographic agility" for BBS+ like algorithms would need to be substantiated further. Also, if used only as a "classic" signature algorithm and not as an enabler to ZKP, BBS+ is easily swappable with any other signature algorithm.

• Potential to move to PQC algorithm: If the fundamental crypto behind BBS+ gets broken (not just a particular implementation that would require only a software patch) e.g. through the advent of quantum computing, then it is very likely that algorithms like ECDSA and ECSchnorr would be broken at the same time as they rely on very similar underlying mathematical problems. Furthermore, the currently considered algorithms like ECDSA (used in mDL) are not PQC either so it is not really clear what would be lost by moving to BBS+. Finally,, BBS+ offers "everlasting privacy", meaning that even if it got broken (e.g. through quantum computing), the past transactions would remain private forever; a fraudster could only forge falsified Verifiable Credentials. Many of the currently proposed PQC algorithm (and clearly neither ECDSA nor RSA) do not possess this property which is arguably way more important at this stage than PQC for which algorithms are much less mature and standardised than BBS+. How the use of BBS+ could prevent a "potential move to QPC algorithm" is not really clear; indeed it is not clear how the use of any specific algorithm could prevent the "potential move to QPC algorithm".

• Support of hardware backed keys: current SEs on smartphones or in external hardware tokens do not offer BBS+ or the necessary underlying mathematical enabling function to implement it. However, it does not prevent its use in HSMs. Furthermore, GSMA members have already prototyped the implementation of BBS+ on old SIM cards with very satisfying results as indicated in the GSMA paper linked above in this thread, meaning the implementation of BBS+ in SE is a matter of time and political willingness, not an impossibility. As mentioned above, before that happens, HSM can be used. Generally, the comments made here relate to the balancing act of taking into account short term implementation constraints vs securing the right place for privacy that is a fundamental right of European citizens, especially for such a sensitive object as a universal ID wallet. If privacy is taken seriously, the necessary processes can be accelerated; such agility was demonstrated in response to the Covid-19 crisis.

As I read your text, I see that you more or less agree with all 5 arguments that I've given. eIDAS wants to start building something now and BBS+ is not ready for the given reasons. I've got even two more:

• BBS+ is only defined in combination with JSON-LD that has its own security issues and ARF clearly said they do not allow JSON-LD for Type 1.
• the only well supported mechanism for holder Bindung is using did:key which introduces another correlator and destroys air privacy features

I like the idea of ZKP based VCs but the truth is they are not mature yet. Some issues could be improved but I don't see any momentum.

[wbl]

There's no reason eIDAS couldn't do the necessary work to develop a privacy preserving technology and improve the JSON-LD issues. Basically the message I'm getting is "we prefer writing less code and doing less work to ensuring Europeans have privacy" and being honest with the stakeholders that what they want is not possible.

[GSMA-EIG]

The absence of the SOG-IS is just a self-inflected excuse: if this is really important, they can do their jobs. Likewise the CFRG assessment can go faster, if it's going to be used, and it's not like the EU doesn't have cryptographers qualified to assess it.

The fact that SD-JWT is being considered despite not meeting the security property required is disappointing.

Each organisation has its own internal process but we are indeed surprised by the choices that were made in the ARF if privacy is deemed important by the eIDAS expert group: • We consider that SD-JWT (same for mDL) is indeed structurally incompatible with full unlinkability • We have not yet heard of any factual reason from any security agency in Europe why BBS+ should not be included in SOG-IS, only vague and unsubstantiated assertions about the supposed inferiority of pairing-based cryptography as opposed to classical elliptic curves. This is all the more regrettable that SOG-IS inclusion is the only real obstacle to the inclusion of BBS+ in the ARF. • BBS+ is the only protocol we know of that has all the good properties we should wish for in an ID framework, including the necessary efficiency to be run in a Secure Element and everlasting privacy • We are not sure that the CFRG is facing any sort of delay but are ready to help here

At this stage, we have not yet received any official feedback from the commission to our comments and suggestions . We hope the detailed exchange here will help resolve matters soon so that privacy is at the heart of the upcoming eIDAS2 framework.

[jaromil]

The issues raised by @GSMA-EIG are severe, and I'm thankful for the time dedicated to detail them.

Even beyond Idemix and BBS+, ZKP technologies have been thoroughly researched and developed on behalf of the EC in success stories like DECODE and REFLOW. We have developed production-ready technology which even Facebook adopted.

Today, when designing the ARF recommendation, from which more than a public tender will depend, adopting privacy by design and data minimization principles should be paramount and clearly stated.

This issue is also political: resorting to old technology rules out all the innovators who have worked hard for two decades and preserves the market dominance of an inadequate oligopoly of solution providers.

[OBIvision]

I can only acknowledge the problems stated and how far the ARF are from even a minimum solution that deliver on the initial eIDAS 2.0 claims.

Anyone having tried to build trustworthy identity in pure zkp (where U-prove is of course orders of magnitude better than any of the other alternatives) will know that is very hard in a world where multiple providers - trustworthy or trusted alike - can be able to issue credentials that shall recombined and issued with selective disclosure to new context.

I talked about the issues at the EDPS Workshop on Identity more than a year ago https://edps.europa.eu/system/files/2022-07/03_-_stephan_engberg_-_edps_trustworthy_pki_engberg_20220622_en_0.pdf

My core point - we cannot and should not try to solve these problem within a single wallet perspective. CitizenKey will be based on multi-layered wallets and zero dependency on key revocation.

We concluded more than a year ago that eIDAS 2.0 / ARF would fail. We consider that a done deal.

The key issue is to prevent monopolized or cartel structures where nobody from civil society can challenge and mitigating BigTech or BigGov with better solutions. Over-standardization will not do the trick as that will just enable the lock-in problems of tomorrow and the real test is many-to-many, not if the structure with a tight list of additional requirements can resolve a simple very narrow problem.

We need to aim much wider and for continuous improvement if Eu shall avoid enforcing the structures that will kill the EU principles based on fundamental human rights, free markets and functional democracy.

[GSMA-EIG]

While Idexmix/Anoncreds offer great privacy features they lack:

• final standardization
• acknowledgment by regulators
• cryptographic agility
• potential to move to PQC algorithms
• support for hardware-backed keys

Hardware-backed keys are needed to protect against credential duplication which is one of the attack vectors that you need to cover to achieve LoA high. Thus, there seems no way to use Anoncreds/BBS+ for high assurance use cases given the current technology.

RESPONSE: Let's consider and review the individual claims: • Final standardization: True. BBS+ is in advanced draft at the ietf in particular, but not final. BBS (same cryptographic underpinnings as BBS+) and several variants of it are however ISO standardized (ISO/IEC 20008-2) and already deployed in hundreds of millions of TPM and Intel SGX enclaves and in some existing wallets. Also, we note with interest that in [https://edi.pleio.nl/file/download/f316c8d9-b048-4dc9-a520-f5f5ab55c605/nlw-design-considerations-v1.pdf] BBS+ is considered a "valuable alternative". Standardisation is not considered as an open issue. . PQC algorithms mentioned later are not standardized either. • Acknowledgement by regulator: True but not yet. The reasons therefore are not fundamental (except maybe for PQC, more on that later) and in particular, BBS+ is formally proven secure (reference link https://eprint.iacr.org/2016/663.pdf) with no cryptographic flaws proven on these algorithms that exist for more than 20 years. Furthermore, the PQC algorithms are not standardised nor accepted by the regulators either. • Cryptographic agility: A clear definition of cryptographic agility is still unknown. Nonetheless, some less efficient algorithms than BBS+ with similar properties exists and could replace it in case of a breach: Idemix, CL, PS, etc. so that this claim of lack of "cryptographic agility" for BBS+ like algorithms would need to be substantiated further. Also, if used only as a "classic" signature algorithm and not as an enabler to ZKP, BBS+ is easily swappable with any other signature algorithm. • Potential to move to PQC algorithm: If the fundamental crypto behind BBS+ gets broken (not just a particular implementation that would require only a software patch) e.g. through the advent of quantum computing, then it is very likely that algorithms like ECDSA and ECSchnorr would be broken at the same time as they rely on very similar underlying mathematical problems. Furthermore, the currently considered algorithms like ECDSA (used in mDL) are not PQC either so it is not really clear what would be lost by moving to BBS+. Finally,, BBS+ offers "everlasting privacy", meaning that even if it got broken (e.g. through quantum computing), the past transactions would remain private forever; a fraudster could only forge falsified Verifiable Credentials. Many of the currently proposed PQC algorithm (and clearly neither ECDSA nor RSA) do not possess this property which is arguably way more important at this stage than PQC for which algorithms are much less mature and standardised than BBS+. How the use of BBS+ could prevent a "potential move to QPC algorithm" is not really clear; indeed it is not clear how the use of any specific algorithm could prevent the "potential move to QPC algorithm". • Support of hardware backed keys: current SEs on smartphones or in external hardware tokens do not offer BBS+ or the necessary underlying mathematical enabling function to implement it. However, it does not prevent its use in HSMs. Furthermore, GSMA members have already prototyped the implementation of BBS+ on old SIM cards with very satisfying results as indicated in the GSMA paper linked above in this thread, meaning the implementation of BBS+ in SE is a matter of time and political willingness, not an impossibility. As mentioned above, before that happens, HSM can be used. Generally, the comments made here relate to the balancing act of taking into account short term implementation constraints vs securing the right place for privacy that is a fundamental right of European citizens, especially for such a sensitive object as a universal ID wallet. If privacy is taken seriously, the necessary processes can be accelerated; such agility was demonstrated in response to the Covid-19 crisis.

As I read your text, I see that you more or less agree with all 5 arguments that I've given. eIDAS wants to start building something now and BBS+ is not ready for the given reasons. I've got even two more:

• BBS+ is only defined in combination with JSON-LD that has its own security issues and ARF clearly said they do not allow JSON-LD for Type 1.
• the only well supported mechanism for holder Bindung is using did:key which introduces another correlator and destroys air privacy features

I like the idea of ZKP based VCs but the truth is they are not mature yet. Some issues could be improved but I don't see any momentum.

GSMA Response: Here’s a more succinct response for the different remarks that have been outlined. Unfortunately we are not in agreement including on your earlier points. It is challenging to inform less technical stakeholders accurately on topics as complex as these and hope this response helps decision-makers gain further clarity. - Final standardization: BBS+ is in final stages of standardization at IETF, as confirmed to GSMA following our recent Liaison Statement (https://mailarchive.ietf.org/arch/browse/cfrg/). The questions to be raised here are - Is everything included in the ARF already fully standardized? What is the deadline being referenced as “now”? How does the current status of BBS+ standardization prevent actors from implementing open-source BBS+ libraries used commercially? Ex: https://github.com/docknetwork/crypto and https://github.com/mattrglobal/bbs-signatures Acknowledgement by regulators: Processes could be accelerated if need be, as mentioned in above post (https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework/issues/66#issuecomment-1689302014) this equates to a “self-inflicted excuse”. Are there any weaknesses of these protocols that have been published since 2004? Cryptographic agility: This doesn’t seem agreeable. For a bit of perspective, please have a look here. Potential move to PQC algorithms: The current choices of the ARF are not quantum safe either and it would be helpful to understand how BBS+ would prevent moving to PQC algorithms later on. Support for hardware-backed keys: this could only be considered as an issue if it was proven that none of the currently certified HSMs can support BBS+ keys and processing.

Regarding the latest objections raised:

• “JSON-LD that has its own security issues”: we would like to understand what security issues are referenced here.
• “ARF clearly said they do not allow JSON-LD for Type 1”: We have not seen any valid rationale.“ The only well-supported mechanism for holder binding is using did: key which introduces another correlator and destroys air privacy features”: Not sure where this can be found? We would like to draw your attention to the 2 implementation examples provided above : while they are deep into DID: key implementations for other parts of their product, the part of their product that supports BBS+ does NOT use DIDs
• “I don't see any momentum”: Momentum” lacks a clear definition. However we understand that concerns about tracking and unlinkability rate high across European Member States and we expect die Bundesdruckerei is already aware of the need to identify solutions. We also note that BBS+ is mandatory in recent US government RFP: https://sam.gov/opp/33b3b247777c4912b08c23ba97dc8af4/view and https://sam.gov/api/prod/opps/v3/opportunities/resources/files/dbaddc61a9e5426bb4c87c4d5e3c6509/download?&token=

In conclusion, if privacy is prioritised as a key success factor for eIDAS2, then BBS+ best caters to this requirement. Political willingness to prioritise privacy should result in its integration in eIDAS2. Among key benefits BBS+ provides full unlinkability, everlasting privacy, scalable and privacy-preserving revocation, and implementability on Secure Elements.

[AltmannPeter]

This thread has a lot of information to digest. I will first comment on the GSMA report, then I will comment on a few of the points raised.

The GSMA official response

I find the text rather uninformed. Just a few comments that may help with a potential future revision:

1. Technically enforced privacy does not exist. The best you can hope for is to increase the cost of correlation, and technical means is just one way. eIDAS 2.0 is not some theoretical exercise focused only on ZKP, it exists in a context that has to resist nation state attackers.
2. ZKP is not a technology, it is a property of a proof system. I remain unconvinced that the zero-knowledge property is important for eIDAS 2.0.
3. Could you clarify your adversarial assumptions? The ARF assumes trusted issuers for Type 1 (which does allow JSON-LD but mandates SD-JWT and mdoc-MSO). It is only for Type 2 attestations where issuer collusion is assumed a threat. As per the NL paper you link yourself (page 11), with the assumptions assumes for Type 1, batch issuance is a solution.
4. Verifiers do not receive any information about the user's wallet instance. The trust model assumes that it is the issuer who performs the necessary wallet checks.
5. BBS+ is years away from mature standardization. The response that ISO 20008-2 already standardized group signatures means nothing. I frankly get frustrated with claims that point to a mature standard that has nothing to do eIDAS 2.0. Sort of like how people point to the ISO 18013-5 standard claiming its mature for eIDAS when it is a device interface standard. Few things are as dangerous as using a mature solution in one domain in a new domain assuming that its use is mature there as well.

Then there are several questionable claims about ZKP and BBS+

7. The use of BBS+ does not mean you automatically can support any predicate / proof. The W3C VCDM application is a perfect example of this.
8. How can you claim scalability and efficient computation as benefits? Also what accumulator setup do you have in mind that allows for efficient revocation and that is extremely scalable?
9. Anonymous presentation of multiple attestations is not tied to BBS+ or ZKP.
10. Anonymous billing is relevant why?
11. "not only are ZKP able to perform unprecedented rich privacy preserving transactions, they also do so without any scalability, security nor ease of use issues" lol.

Then there are claims about the impact on the ARF.

12. How can you claim that privacy has no adverse impact on other aspects?
13. Bath issuance solves verifier collusion. Again adversarial assumptions matter.
14. What are the benefits of LD-proofs for eIDAS 2.0 Type 1, a context where issuers can agree on attribute names, where verifiers know the issuers, and where there is little need to model attestations as knowledge graphs.
15. Why would every configuration mandate the same level of privacy? This depends entirely on your adversarial assumption and how effective other privacy means (e.g., legal contracts) are at increasing the cost of profiling.
16. It is not the Toolbox's job to recognize ZKP, but to realize the proposed eIDAS 2.0 regulation.

With the above stated, perhaps what baffles me the most is that the ARF already allows for BBS+ and other ZKP friendly solutions. What more do you want?

Comments in this thread

a. Why is ISO/IEC 20008-2 relevant for eIDAS? b. In the NL report you link that mentions BBS+ as a valuable alternative (or rather mentions multimessage signatures as valuable) there are other points that clearly explains why BBS+ cannot be used. c. Formal proofs of security are just one consideration. Underlying hardness problems for instance is another. d. Any solution where predicates are computed in a way that requires the algebraic properties of the messages to be preserved in the signature is arguably far less agile than those that do not. e. If ECDSA is broken, I just sign my salted hashes using any other signature scheme. It is a simple parameter setting. f. There is absolutely no difference between using salted attribute digests and ZKP in terms of what PQC would mean. Just as a ZKP of knowledge of valid signature reveals nothing of the signature, there is no way an attacker can find the inputs to a salted attribute digest using only the digest. g. The EUDIW is presently not an HSM based solution so it does not matter if BBS+ can be HSM implemented. h. I am happy that BBS+ can be implemented in SIMs. What is needed is time. What we do not have is time. I welcome such solutions in eIDAS 4.0. i. Using the COVID-19 as an example is comparing apples to oranges. I know the people behind the adopted solution, and am very familiar with the work process that led up to that solution. eIDAS 2.0 and the EUDIW is entirely different. j. The ARF relies on widely available standards and maturity is a very tricky discussion. For instance, SD-JWT VCs are arguably not a mature standard but far more mature for use in identity ecosystems than is ISO 18013-5 or 23220. The ARF considers more things than just a simple standard in isolation. k. The ARF allows for use of BBS+ in Type 2. Have fun. l. While I am not paulbastian, JSON-LD requires the ability of a verifier do external referencing which is problematic in some cases, especially if non content addressable uris are used. m. The ARF does allow for JSON-LD in Type 1. It mandates SD-JWT. n. dids are not discussed nor likely to be discussed for Type 1. o. The EU is not the US. But again, the ARF allows for JSON-LD and BBS+. Just as the US gov links you sent allow for both SD-JWT and JSON-LD with BBS+. p. Claiming that BBS+ is the best candidate now to cater for the privacy needs in eIDAS 2.0 is a very narrow statement that does not consider the complex reality that is Member State issued identity. q. How does BBS+ provide scalable revocation?

[OBIvision]

"Technically enforced privacy does not exist. The best you can hope for is to increase the cost of correlation, and technical means is just one way. eIDAS 2.0 is not some theoretical exercise focused only on ZKP, it exists in a context that has to resist nation state attackers."

Politely - that is IMHO wrong and a very dangerous mistake. In fact the implied assumption of empowerment as an impossibility is the very reason eIDAS 2.0 is already failing - it was deliberately designed to fail and remain non-compliant with GDPR.

It is complex and there can be many solutions - but when we start abandoning the minimum objectives and not even trying, we already lost.

It is both true that BBS+ belong to a class of crypto that could make real solutions, but also true that BBS+ is clearly immature.

It is - however - also true that we can build trustworthy identity and adapt the security requirements to the multi-stakeholder context in otherwise anonymous cyberspace. How we prevent linkability in the underlying infrastructure is an issue in itself, but cryptographically we can - also within the standards described in the report you co-authored (e.g. 5.2.2) etsi.org/deliver/etsi_tr/119400_119499/119476/01.01.01_60/tr_119476v010101p.pdf

This means that the by far most important aspect of eIDAS 2.0 is the right to challenge the ARF-version as it is clearly not going to deliver on minimum objectives.

[IDmachines]

Tyvm Stephan. Clearly there are alternatives, and there are laws in place, what is missing are the c0-governance technologies that can address the issues, complemented by technologies for personal data control and the traditional data protection concept.

From: Stephan Engberg @.> Sent: Friday, September 15, 2023 9:35 AM To: eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework @.> Cc: Subscribed @.***> Subject: Re: [eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework] Privacy shall be at the heart of ARF (Issue #66)

"Technically enforced privacy does not exist. The best you can hope for is to increase the cost of correlation, and technical means is just one way. eIDAS 2.0 is not some theoretical exercise focused only on ZKP, it exists in a context that has to resist nation state attackers."

Politely - that is IMHO wrong and a very dangerous mistake. In fact the implied assumption of empowerment as an impossibility is the very reason eIDAS 2.0 is already failing - it was deliberately designed to fail and remain non-compliant with GDPR.

It is complex and there can be many solutions - but when we start abandoning the minimum objectives and not even trying, we already lost.

It is both true that BBS+ belong to a class of crypto that could make real solutions, but also true that BBS+ is clearly immature.

It is - however - also true that we can build trustworthy identity and adapt the security requirements to the multi-stakeholder context in otherwise anonymous cyberspace. How we prevent linkability in the underlying infrastructure is an issue in itself, but cryptographically we can - also within the standards described in the report you co-authored (e.g. 5.2.2) etsi.org/deliver/etsi_tr/119400_119499/119476/01.01.01_60/tr_119476v010101p.pdf

This means that the by far most important aspect of eIDAS 2.0 is the right to challenge the ARF-version as it is clearly not going to deliver on minimum objectives.

https://user-images.githubusercontent.com/24465339/268291582-9e0ee337-3e42-41a4-b83a-c858c916c2d9.png

— Reply to this email directly, view it on GitHub https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework/issues/66#issuecomment-1721294702 , or unsubscribe https://github.com/notifications/unsubscribe-auth/AAHY7P5FV32VZYIWDBZ4EWDX2RKR5ANCNFSM6AAAAAAZPBKL3U . You are receiving this because you are subscribed to this thread. https://github.com/notifications/beacon/AAHY7P6BJXIRRMPDTKOECQ3X2RKR5A5CNFSM6AAAAAAZPBKL3WWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTTGTDPW4.gif Message ID: @. @.> >

[Sebastian-Elfors-IDnow]

ETSI has recently published the ETSI TR 119 476 technical report on selective disclosure (see https://www.etsi.org/deliver/etsi_tr/119400_119499/119476/01.01.01_60/tr_119476v010101p.pdf). This ETSI report describes in detail why and how IETF SD-JWT and ISO mDL MSO have been chosen as formats for selective disclosure of PIDs in the Type 1 configuration of the EUDI Wallet. The report was authored by Peter Altmann and me, and we are still open to receive feedback on it.

In a nutshell, the EU public sector will only accept SOG-IS approved cryptographic algorithms when issuing the PID for the EUDI Wallet Type 1 configuration, hence the choices of ISO mDL MSO and IETF SD-JWT. I can also agree with the arguments Paul Bastian and Peter Altmann have made previously.

However, the EUDI Wallet ARF allows for other cryptos and formats for Type 2 configurations of the EUDI Wallet, and here BBS+ and similar ZKP schemes could be of interest. So GSMA could focus on certifying hardware based solutions with BBS+ support, such as a SIM-cards with embedded BBS+ algorithms.

[wbl]

Are the mitigations being hypothesized actually going to be deployed and discussed in enough detail to be analyzed by the community? Does this include the use of blind signatures in issuance? The simple fact is without these mitgations issuers can correlate user behavior across any site they visit and show a credential to, and the selective disclosure's security properties are much more subtle than users think, to the point it would be better to not have it.

[OBIvision]

@Sebastian-Elfors-IDnow The ETSI report is a comprehensive and thorough work.

IMHO. The main problem with the report is that it fails to point to the basic fact that these claims and the ARF do not deliver on the core objective. Not even close.

Three specific issues:

The first and most critical issue is the assumption that the purpose is to establish identification. But identification dis-empower the citizens and this defeats the main objective which is establishing trustworthy identity for the transaction, i.e. not linkable identification, which would always be some variant of pseudonymity. The total absence of attention to network linkability is just further underlining the problem.

The reuse of keys is a nightmare as it establish dependency on key revocation schemes. Keeping accumulators up-to-date is bordering impossible, This is a particular problem for Camenisch-Lysyanskaya zkp proofs as there is no non-linkable use limitation. But the same problems goes for loss of Smartphones or FIDO devices as you end up having to lock-down the citizen as such. Worst case if any collection/sharing of biometrics is involved (which should be considered an absolute no-go).

The architecture is designed so issuance has to be for linkable identification keys meaning that issuers cannot be secure. In any serious model Verifiers should also become Issuers, i.e. you need to assume that Issuers are operating in the pseudonymous / non-linkable space.

Our general take - the W3C/VC zkp-space is clearly immature (because it is hard, complex and the toolbox is not covering the needs even if BBS+ was upgraded to e.g. match U-Prove features) and likely being almost ignored by public sector authorities that focus on identification and massive centralized profiling without any means to empower citizens. As such the entire process has turned into data retention by design inherently escalating a conflict with GDPR because pseudonymity as the default has not been pursued despite eIDAS article 5.2 and the obvious GDPR compliance obligation.

The report contain a very critical aspect in the acknowledgement of the importance of atomic disclosure applying pseudonymous PKI attribute certifications (e.g. 5.2.2). But it is not followed up especially on how to protect against the CA. We have suggested Trustworthy PKI as a general solution that will at the same time address many of the open problems with zkp if you build zkp on trustworthy anchors (i.e. pseudonymous and contextualized).

[OBIvision]

May I suggest a very simple test.

If ARF Type 1 does not support trustworthy anonymity and trustworthy pseudonymity (trustworthy anonymity with some data minimized/not backdoored data minimized accountability), then ARF is not compatible with GDPR (especially article 25).

This is clearly both technically possible and politically required so why is the ARF specification process not aiming for compliance?

Personally I would suggest trustworthy pseudonymity legally would be the default minimum rather than the present built-in data retention/surveillance model

[GSMA-EIG]

This thread has a lot of information to digest. I will first comment on the GSMA report, then I will comment on a few of the points raised.

The GSMA official response

I find the text rather uninformed. Just a few comments that may help with a potential future revision:

1. Technically enforced privacy does not exist. The best you can hope for is to increase the cost of correlation, and technical means is just one way. eIDAS 2.0 is not some theoretical exercise focused only on ZKP, it exists in a context that has to resist nation state attackers.
2. ZKP is not a technology, it is a property of a proof system. I remain unconvinced that the zero-knowledge property is important for eIDAS 2.0.
3. Could you clarify your adversarial assumptions? The ARF assumes trusted issuers for Type 1 (which does allow JSON-LD but mandates SD-JWT and mdoc-MSO). It is only for Type 2 attestations where issuer collusion is assumed a threat. As per the NL paper you link yourself (page 11), with the assumptions assumes for Type 1, batch issuance is a solution.
4. Verifiers do not receive any information about the user's wallet instance. The trust model assumes that it is the issuer who performs the necessary wallet checks.
5. BBS+ is years away from mature standardization. The response that ISO 20008-2 already standardized group signatures means nothing. I frankly get frustrated with claims that point to a mature standard that has nothing to do eIDAS 2.0. Sort of like how people point to the ISO 18013-5 standard claiming its mature for eIDAS when it is a device interface standard. Few things are as dangerous as using a mature solution in one domain in a new domain assuming that its use is mature there as well.

Then there are several questionable claims about ZKP and BBS+

7. The use of BBS+ does not mean you automatically can support any predicate / proof. The W3C VCDM application is a perfect example of this.
8. How can you claim scalability and efficient computation as benefits? Also what accumulator setup do you have in mind that allows for efficient revocation and that is extremely scalable?
9. Anonymous presentation of multiple attestations is not tied to BBS+ or ZKP.
10. Anonymous billing is relevant why?
11. "not only are ZKP able to perform unprecedented rich privacy preserving transactions, they also do so without any scalability, security nor ease of use issues" lol.

Then there are claims about the impact on the ARF.

12. How can you claim that privacy has no adverse impact on other aspects?
13. Bath issuance solves verifier collusion. Again adversarial assumptions matter.
14. What are the benefits of LD-proofs for eIDAS 2.0 Type 1, a context where issuers can agree on attribute names, where verifiers know the issuers, and where there is little need to model attestations as knowledge graphs.
15. Why would every configuration mandate the same level of privacy? This depends entirely on your adversarial assumption and how effective other privacy means (e.g., legal contracts) are at increasing the cost of profiling.
16. It is not the Toolbox's job to recognize ZKP, but to realize the proposed eIDAS 2.0 regulation.

With the above stated, perhaps what baffles me the most is that the ARF already allows for BBS+ and other ZKP friendly solutions. What more do you want?

Comments in this thread

a. Why is ISO/IEC 20008-2 relevant for eIDAS? b. In the NL report you link that mentions BBS+ as a valuable alternative (or rather mentions multimessage signatures as valuable) there are other points that clearly explains why BBS+ cannot be used. c. Formal proofs of security are just one consideration. Underlying hardness problems for instance is another. d. Any solution where predicates are computed in a way that requires the algebraic properties of the messages to be preserved in the signature is arguably far less agile than those that do not. e. If ECDSA is broken, I just sign my salted hashes using any other signature scheme. It is a simple parameter setting. f. There is absolutely no difference between using salted attribute digests and ZKP in terms of what PQC would mean. Just as a ZKP of knowledge of valid signature reveals nothing of the signature, there is no way an attacker can find the inputs to a salted attribute digest using only the digest. g. The EUDIW is presently not an HSM based solution so it does not matter if BBS+ can be HSM implemented. h. I am happy that BBS+ can be implemented in SIMs. What is needed is time. What we do not have is time. I welcome such solutions in eIDAS 4.0. i. Using the COVID-19 as an example is comparing apples to oranges. I know the people behind the adopted solution, and am very familiar with the work process that led up to that solution. eIDAS 2.0 and the EUDIW is entirely different. j. The ARF relies on widely available standards and maturity is a very tricky discussion. For instance, SD-JWT VCs are arguably not a mature standard but far more mature for use in identity ecosystems than is ISO 18013-5 or 23220. The ARF considers more things than just a simple standard in isolation. k. The ARF allows for use of BBS+ in Type 2. Have fun. l. While I am not paulbastian, JSON-LD requires the ability of a verifier do external referencing which is problematic in some cases, especially if non content addressable uris are used. m. The ARF does allow for JSON-LD in Type 1. It mandates SD-JWT. n. dids are not discussed nor likely to be discussed for Type 1. o. The EU is not the US. But again, the ARF allows for JSON-LD and BBS+. Just as the US gov links you sent allow for both SD-JWT and JSON-LD with BBS+. p. Claiming that BBS+ is the best candidate now to cater for the privacy needs in eIDAS 2.0 is a very narrow statement that does not consider the complex reality that is Member State issued identity. q. How does BBS+ provide scalable revocation?

GSMA Response: Here is our proposal to answer the related comments -

0. These comments include strong statements on the way privacy and security should be managed as part of eIDAS, in particular, the “adversarial assumption” that issuers can never collude (willingly or unwillingly) with anyone else. Is this post reflecting the official position of the eIDAS expert group? Have the “adversarial assumptions” for the EUDIW been publicly discussed? If not, which entities have defined them and have data protection authorities validated them? Until there are clear answers to these important questions, we prefer to adopt a principle of precaution whereby the used protocols allow us to protect privacy using the state-of-the-art privacy solutions. Let’s take 2 use case examples: e-voting: the issuer and verifier are the same, i.e. the State. We believe citizens would not be comfortable knowing that the State, however “certified” it is, was able to know what each citizen voted for. Their information being protected in an everlasting way seems extremely valuable. What should reasonable “adversarial assumptions” be for electronic voting systems? EUDIW should be set up to support electronic voting in the future. We would like to understand how “salted hash” solves this issue. +18: should it be considered type 1 or type 2? Should wallets hold multiple PIDs (one for type 1 and one for type 2)? There are situations where people need to be fully identified (as in « PID in clear ») e.g. for border checks, and situations where attributes are minimized, potentially to the point of being fully anonymized (e.g. for online voting or +18). We believe civil society acceptance needs such situations to be catered for independently of the VCs that are used including the PID or the driving license .
1. Privacy requires careful technical design, even if non-technical safeguards are also important. As described in the document, BBS+ has the following two properties that we term Everlasting Privacy when they are combined:
   • Perfect unlinkability: a message signed by BBS+ cannot be linked to the original VCs that were used to create it, even if verifiers and issuers collude or if the protocol is “broken” through the advent of quantum computing. One might think that preventing collusion from issuers is unnecessary e.g., because they’re certified. However, there is a risk that the exchanges of issuers become visible (let’s refer to SSL/TLS multiple past breaches); issuers could be hacked or would be exposed to the option to collude.
   • Perfect hiding : for any hidden attribute signed by BBS+ or used to generate a BBS+ based ZKP, no one will ever be able to identify the data that were used to generate it. It can be formally proven that BBS+ satisfies these two properties. We indeed share the goal of protecting against nation-state attackers. Yet we believe there is no reason to compromise privacy in order to achieve security. BBS+ achieves both. Is there a specific weakness of the BBS+ or BBS+ based ZKP vs e.g., ECDSA that makes them less prone to resist “nation-state attackers”?
2. ZKP (and specifically BBS+ ZKPs) are the most optimal way we know of today to ensure the best combination of security and data minimization as per GDPR.
3. The main difference is that we don’t assume that issuers would never collude. See 0 and 1.
4. Not sure what this means, could you clarify the context please?
5. According to our participating members at IETF, BBS+ does not seems to be “years away”.
6. (Numbering issue)
7. This is correct. However, BBS+ supports the following features with little effort : Selective Disclosure, Perfect Unlinkability and basic predicates like “range proofs”, “set membership proofs” and combination of such predicates using the logical operators « AND », « OR », or « NOT », which will cover most of envisioned use cases. In contrast, SD-JWT does not provide “unlinkability” in the broad sense of the term or even simple predicates like “range proofs” or “set membership proofs”.
8. We are claiming efficient computation against other anonymous credential with similar privacy properties like IDEMIX and similar complexity to ECDSA , because some of our members and contacts in the identity community have implemented it, including on SIM cards. The state of the art on accumulators provides detailed benchmarks showing that these techniques are now scalable (see for example the recent papers published at CT-RSA 2022 and ACM CCS 2022).
9. We don’t know of any other appropriate method for “anonymous presentation of multiple attestations” rather than with ZKP and anonymous signatures and we don’t know of any more efficient solution than using anonymous credentials schemes like BBS+. Is there any other suitable alternative with the same advantageous properties including unlinkability and everlasting privacy?
10. For the wallet ecosystem to be a sustainable one driving innovation and economic growth across a wide range of industry actors, it is important to allow the emergence of solid business models. This requires a way for the distribution of monetary value between the different actors of a transaction while respecting the core principles set out by the European Commission (in particular security and privacy / minimization).
11. We stand by these observations.
12. These are the findings of our analysis and above-mentioned implementations. Are there proven any adverse issues on the security of BBS+?
13. See 0
14. See 0
15. See 0. Our view is that people’s sovereign identities must not be dealt with as a commodity that can be replaced and managed on a risk-based approach. Risk should not be priced in identity like in a financial context. Money losses can get refunded whereas stolen personal information has irreversible effects. We would encourage a broader public debate about “adversarial assumptions” and whether privacy can be managed through legal contracts.
16. We believe that eIDAS 2.0 aims for EUDIW to deliver privacy, security and reach, hence we are raising these concerns about the Toolbox protocol selection.

”What more do you want ?” Our suggestions are listed at the end of the GSMA "eIDAS 2.0 and Privacy”.

a. BBS (the single attribute version of BBS+) is standardized in ISO/IEC 20008-2 (2013) as well as PS signatures (mentioned in the ETSI technical report you co-authored). With BBS, issuers can therefore issue VC which contains a single private attribute. These VC can be used by users to prove that they are over 18 e.g., to access a betting website, without revealing their birthdate or any other identifying certified data. So, ISO/IEC 20008-2 already standardized privacy-preserving signature schemes that could be used to issue Verifiable Credentials. b. Please could you detail these critical issues? c. The security of BBS+ relies on the well-studied q-SDH assumption. While the plausibility of this assumption might be questioned, we note that the situation is arguably better than ECDSA, for which no security proof based on computational assumptions are known. A very recent result (Limits in the Provable Security of ECDSA Signatures (iacr.org) ) tends to show that such proofs are very unlikely for ECDSA. d. Please could you detail the concern? e. If BBS is broken, any other anonymous credentials scheme (such as PS scheme) can be used. It is a simple parameter setting. Switching to any other signature scheme using SD-JWT is another option. The advantage of this approach i.e. using BBS in the first place and only switching to SD-JWT in case BBS is broken is that even if BBS+ is compromised the privacy of the users will still be preserved, given BBS+ Everlasting Privacy. f. Yes, however we believe the issue lies in achieving unlikability. Indeed, beyond what we mentioned in 7., salted hashes don’t apply to signatures, but only to attributes. With salted hashes users can be tracked through their signatures. g. Does “the EUDIW” “solution” mean the current EUDIW Reference implementation? h. We agree about the urgency. However there is a real risk that eIDAS 2.0 may be flagged as an invasion of privacy and accused of providing inadequate protection if not designed carefully, with privacy in mind. This would delay mass adoption.
i. They’re certainly two different things. We mean that innovative solutions can be industrialised and adopted quickly with political will. j. See 0. Which criteria is taken into account? We note your comment on ISO/IEC 18013-5 and 23220 being less mature, indeed 23220 is not out of draft status; yet they are explicitly mentioned as standards to be applied in the ARF 1.1. k. See 0. Our objective is to foster privacy as a whole for eIDAS to enable citizens to use their PID in a minimized, secure and convenient way. l. We need more information to discuss this further.

m. We suggest clarifying this further in the ARF Figure copied here.
n. See 0. Why should there be a difference between type 1 and 2 on privacy? o. We do not understand that the ARF allows JSON-LD and BBS+ on type 1 (see m). p. This lacks justification, especially considering GDPR; is this a formal conclusion of the eIDAS Expert Group? q. BBS+ provides scalable revocation by using accumulators. See 8.

There are still a few points that we did not understand. Whilst we recommend involving the experts from relevant standard bodies, we would be happy to discuss our understanding of the state-of-the-art protocols and believe such discussion should include privacy stakeholders for instance via the EDPB.

[GSMA-EIG]

ETSI has recently published the ETSI TR 119 476 technical report on selective disclosure (see https://www.etsi.org/deliver/etsi_tr/119400_119499/119476/01.01.01_60/tr_119476v010101p.pdf). This ETSI report describes in detail why and how IETF SD-JWT and ISO mDL MSO have been chosen as formats for selective disclosure of PIDs in the Type 1 configuration of the EUDI Wallet. The report was authored by Peter Altmann and me, and we are still open to receive feedback on it.

In a nutshell, the EU public sector will only accept SOG-IS approved cryptographic algorithms when issuing the PID for the EUDI Wallet Type 1 configuration, hence the choices of ISO mDL MSO and IETF SD-JWT. I can also agree with the arguments Paul Bastian and Peter Altmann have made previously.

However, the EUDI Wallet ARF allows for other cryptos and formats for Type 2 configurations of the EUDI Wallet, and here BBS+ and similar ZKP schemes could be of interest. So GSMA could focus on certifying hardware based solutions with BBS+ support, such as a SIM-cards with embedded BBS+ algorithms.

GSMA Response:

We have detailed our comments on the evaluation criteria and on the detailed assessment and conclusions of the reports, as part of GSMA recent Liaison Statement towards ETSI on the need for a revised analysis of the privacy aspects in the ETSI TR 119 476 V1.1.1: https://www.gsma.com/gsmaeurope/resources/gsma-eig-to-etsi-liaison-statement/

[francis-pouatcha]

ETSI has recently published the ETSI TR 119 476 technical report on selective disclosure (see https://www.etsi.org/deliver/etsi_tr/119400_119499/119476/01.01.01_60/tr_119476v010101p.pdf). This ETSI report describes in detail why and how IETF SD-JWT and ISO mDL MSO have been chosen as formats for selective disclosure of PIDs in the Type 1 configuration of the EUDI Wallet. The report was authored by Peter Altmann and me, and we are still open to receive feedback on it.

I learned a lot from reading through this document. I genuinely appreciate the efforts of the authors.

I found the concept of Atomic Attributes (section 4.4.4) quite intriguing. However, I would have preferred the introduction of a concept for Single Use VC (with predefined use-case based attribute set). Combined with Batch Issuance and the idea of a Unique Holder Key per VC, this could achieve a high degree of unlinkability.

There seems to be much more that could be done to prevent linkability, watch network attributes, credential data, signature timestamp, you name it...

[Sebastian-Elfors-IDnow]

All,

Please note that we will gather feedback on ETSI TR 119 476 v1.1.1 until 2023-10-13. So 2023-10-13 is the deadline for comments that will be considered for the next revision of ETSI TR 119 476.

[francis-pouatcha]

All,

Please note that we will gather feedback on ETSI TR 119 476 v1.1.1 until 2023-10-13. So 2023-10-13 is the deadline for comments that will be considered for the next revision of ETSI TR 119 476.

How do we provide feedback? here? I did not find any reference to a feedback process in the document. I might have missed it.

[nicobao]

When it comes to privacy vs security, like with a product, it's important to go back to the actual use-cases to determine the requirements.

As a European citizen, I feel conflicted about the idea that a bunch of cryptographic identifiers, uniquely identifying me to my issuers, will be shared to various verifiers. I understand that verifiers cannot correlate my data - but the issuer can. Even if the verifier doesn't want to communicate with the issuer, the verifier can experience cyber-attacks and data leaks.

So long as the verifiers remains official government-based institutions, I'm relatively fine with it because those institutions already hold sensitive data and share data with each other. Besides, Verifiable Credentials in general and security-centric VC such as SD-JWT VCs in particular provide nice protections against identity theft.

But I would definitely not feel comfortable if a random company requests my digital ID in that context, labeling it as "private" because of a deceptive perception of privacy through selective disclosure. In that context, it is NOT private, as the issuer (government here) could sneak in and know what I did with that company. So long as the issuer is concerned, this is not private at all. You trust as a citizen that this company will not make this verifiable data available to the public institutions that issued you the credentials. Remember that we introduce cryptographic verifiability. Your data will be infinitely more valuable and precise than ever before with web forms. I am worried that companies that normally don't require KYC would start doing so because of this deceptive perception of privacy.

In my opinion, we can live with multiple type of credentials for multiple use-cases for now. SD-JWT is fine for security-focused requirements such as when verifiers are existing official institutions (or related, such as banks), already doing KYC (is that "Type 1"?). But we need privacy to be the priority for the other verifiers: we need BBS+ credentials. One day, when BBS+ is more mature (revocation scalability, official HSM support), we can probably merge the two, but probably not now.

So many previously unimaginable products, unsolvable problems and impossible use-cases become possible thanks to arbitrary ZKP and to complete uncorrelatability, especially to the issuer. ZKorum is just one example of it. ZKorum makes (BBS+) Verifiable Credentials speak via verified yet anonymous discussions, polls, and even (non critical) votes. What if we could have a social network where verified (nationality, diploma...etc) yet anonymous European Citizens (anonymous even to the social network and to the issuers such as governments) could discuss hot political and sensitive topics? That is possible on ZKorum if Europe starts issuing BBS+ credentials. Not possible with SD-JWT.

For a sneak peek at features that BBS+ unlocks, have a look at the Dock's crypto-wasm-ts library (cc @docknetwork @lovesh)

[wbl]

ETSI TR 119 476 V1.1.1 isn't the problem.

The problem is the EURID ARF doesn't say "we issue a bunch of single use credentials, and here's the considerations in issuing them" or "here are the privacy goals".

[Sebastian-Elfors-IDnow]

All, Please note that we will gather feedback on ETSI TR 119 476 v1.1.1 until 2023-10-13. So 2023-10-13 is the deadline for comments that will be considered for the next revision of ETSI TR 119 476.

How do we provide feedback? here? I did not find any reference to a feedback process in the document. I might have missed it.

Please add your feedback to this thread at this forum. We will consider all comments that have been entered in this thread until 2023-10-13, after that we will we initiate the update process of ETSI TR 119 476.

[Sebastian-Elfors-IDnow]

When it comes to privacy vs security, like with a product, it's important to go back to the actual use-cases to determine the requirements.

As a European citizen, I feel conflicted about the idea that a bunch of cryptographic identifiers, uniquely identifying me to my issuers, will be shared to various verifiers. I understand that verifiers cannot correlate my data - but the issuer can. Even if the verifier doesn't want to communicate with the issuer, the verifier can experience cyber-attacks and data leaks.

So long as the verifiers remains official government-based institutions, I'm relatively fine with it because those institutions already hold sensitive data and share data with each other. Besides, Verifiable Credentials in general and security-centric VC such as SD-JWT VCs in particular provide nice protections against identity theft.

But I would definitely not feel comfortable if a random company requests my digital ID in that context, labeling it as "private" because of a deceptive perception of selective disclosure. In that context, it is NOT private, as the issuer (government here) could sneak in and know what I did with that company. So long as the issuer is concerned, this is not private at all. You trust as a citizen that this company will not make this verifiable data available to the public institutions that issued you the credentials. Remember that we introduce cryptographic verifiability. Your data will be infinitely more valuable and precise than ever before with web forms. I am worried that companies that normally don't require KYC would start doing so because of this deceptive perception of privacy.

In my opinion, we can live with multiple type of credentials for multiple use-cases for now. SD-JWT is fine for security-focused requirements such as when verifiers are existing official institutions (or related, such as banks), already doing KYC (is that "Type 1"?). But we need privacy to be the priority for the other verifiers: we need BBS+ credentials. One day, when BBS+ is more mature (revocation scalability, official HSM support), we can probably merge the two, but probably not now.

So many previously unimaginable products, unsolvable problems and impossible use-cases become possible thanks to arbitrary ZKP and to complete uncorrelatability, especially to the issuer. ZKorum is just one example of it. ZKorum makes (BBS+) Verifiable Credentials speak via verified yet anonymous discussions, polls, and even (non critical) votes. What if we could have a social network where verified (nationality, diploma...etc) yet anonymous European Citizens (anonymous even to the social network and to the issuers such as governments) could discuss hot political and sensitive topics? That is possible on ZKorum if Europe starts issuing BBS+ credentials. Not possible with SD-JWT.

For a sneak peek at features that BBS+ unlocks, have a look at the Dock's crypto-wasm-ts library (cc @docknetwork @lovesh)

Thanks for your feedback.

The ARF is bound to SOG-IS approved cryptographic algorithms for EU public sector use cases, hence the specification that Type 1 configurations of the EUDI Wallet require ISO mDL MSO and IETF SD-JWT for selective disclosure. This comes with the operational cost of batch-wise issuance of MSOs and SD-JWTs, and caters for verifier unlinkability (but not for issuer unlinkability).

As regards to the digital identifiers: The eIDAS2 proposals by the EU Council and EU Parliament suggest to remove the "unique identifier" from the EUDI Wallet and replace this with record matching of selected attributes. That is a step in the right direction, since it will then be possible for the user to selectively disclose attributes, which can be matched at the relying party.

Please also note that EUDI Wallets of Type 2 configurations allow for the more innovative multi-message signature schemes (such as BBS+ and CL-signatures) and proofs for arithmetic circuits (such as zk-SNARK and Bulletproofs).

Thanks also for the recommendation about ZKorum. We'll investigate that for the next revision of ETSI TR 119 476.

[OBIvision]

@Sebastian-Elfors-IDnow Problem is that the SOG-IS is essentially overriding fundamental rights and undermining both security, markets and the overall economy with their restrictive dictate. If it is not unlinkable - except for deliberate contextual choices and necessary requirements - both towards issuers, relying parties and infrastructures as such it is data retention by design.

We have known pseudonymous signatures for decades and both eIDAS (art 5 and 24) and GDPR (art 25 and 32) make it mandatory must-carry, but SOG-IS ignore this making it a regulatory override with little or no democratic justification.

[ryanbnl]

Disappointing.

As having I/RP unlinkability as the default operating mode for all cases - specifically including public sector - is vital, at least if you have any kind of vision or foresight.

[francis-pouatcha]

Let Stop Talking Issuer Unlinkability The idea of issuer unlinkability does not make sense. No matter the type of technology in use (BBS+, CL, SD-JWT). If a issuer attests (producing a VC):

• Verifier want to trust the issuer so he can accept the VC: so verifier must know issuer.
• Issuer and the verifier both know the binding key. Sufficient for the linking.

Ho do we prevent this to happen? Not with existing tech!

Event if we provide issuer anonymity pools (ZK-World), the set of issuers will be limited enough for intentional I/RP linking to occur.

Therefore is it better to stop it and focus on Verifier Unlinkability.

[francis-pouatcha]

Concept of HW-defined Secure Environment is Misleading for Privacy Mandating any type of hardware bound cryptographic key marks the end of unlinkability. Therefore reference to TEE, SE, HSM, etc... shall be better defined with more precision and clarity with respect to their purpose.

Unless somebody can explain how unlinkable presentations (VP) can be produced from those environments.

[nicobao]

Let Stop Talking Issuer Unlinkability The idea of issuer unlinkability does not make sense. No matter the type of technology in use (BBS+, CL, SD-JWT). If a issuer attests (producing a VC):

• Verifier want to trust the issuer so he can accept the VC: so verifier must know issuer.
• Issuer and the verifier both know the binding key. Sufficient for the linking.

Ho do we prevent this to happen? Not with existing tech!

Event if we provide issuer anonymity pools (ZK-World), the set of issuers will be limited enough for intentional I/RP linking to occur.

Therefore is it better to stop it and focus on Verifier Unlinkability.

I disagree with you on the two aspects of your post:

• "issuer unlinkability is technically impossible"
• "issuer unlinkability is not important/useful and is not worth investing in"

Clarifying what "issuer unlinkability" means

Of course, the verifier must know that a credential comes from a specific issuer, otherwise there is no point.

The goal is for the verifier to know a Verifiable Presentation was created using Verifiable Credentials from a specific set of Issuers BUT without receiving a Holder-specific cryptographic value that the Issuer know about. So that the verifier knows it comes from the issuer, but without knowing from which holder exactly.

"Issuer unlinkability is technically impossible"

Well! It is already being developed at ZKorum using Dock's (BBS+) Anonymous Credentials under the hood.

With BBS+, Verifiable Presentations do not need to contain the traditional user's DID signature.

A BBS+ Anonymous Credential contains one or more attributes signed by the issuer; attributes and the signature together make up the credential. Anonymous credentials allow to hide any number of attributes and the signature (always) while proving the knowledge of the signature by the issuer (zero-knowledge proof).

Therefore, verifier can verify the Presentation by being sure it comes from the Issuer without having the information about which credential it is exactly: that means the verifier does not know from which holder it comes from exactly.

On top of that, users may generate anonymous pseudonyms (Pedersen commitments) so that the verifier can uniquely identify users. It helps with moderation, spam prevention and DDoS attacks mitigation.

Obviously, I'm not saying this is perfect, there are probably some flaws, I am happy if you can point them out and help the community to build privacy!

"Issuer unlinkability is not important/useful and is not worth investing in"

I don't know for you but I don't want my government to know everything I am doing in my life.

I think it is important to remain aware that one of the main difference between a democracy and a totalitarian country is the amount of data and control the authorities have over their citizens.

Democracies purposingly refuse to know too much, because that would give them too much power.

No privacy = no freedom

If we expect Verifiable Credentials to become pervasive in the world, and be used by much more verifiers than the official ones of today, we should expect at least the same amount of privacy we get today.

Today, most shops don't require KYC, and those who do DO NOT record an unforgable cryptographic identifier that can forever link you with the actions you've done.

Today the organizations that require IDs (verifiers) are usually kinda official, so issuer unlinkability isn't much of a problem for them. But what if your random company now requires your ID for using their service because they think it is private? Well no, in democracies, people in their right mind will not accept. So, wide-adoption will (hopefully) not occur. Wide adoption can only occur with issuer unlinkability, because citizens don't want (and should not want) Big Brother to know every little thing they do in life.

[francis-pouatcha]

SD-JWT is Simple but needs Usage Instructions SD-JWT is simple and can provide RP-Unlinkability if used the right way.

• batch issuance
• single use credential with unique binding key. After selectively disclosing a VC, we discard it.
• no issuance timestamp
• valid in (Week-1, Month-2, Year 2023 -> no timestamp)
• expires (End of Week, Month, Year -> no timestamp)
• revocation pools (non-membership proofs)

Everything else has to be done with unlinkability in mind...

[francis-pouatcha]

I disagree with you on the two aspects of your post:

• "issuer unlinkability is technically impossible"
• "issuer unlinkability is not important/useful and is not worth investing in"

Issuer unlinkability is very important to me. But the misleading technical discussions occurring here do not address the point.

Clarifying what "issuer unlinkability" means

Of course, the verifier must know that a credential comes from a specific issuer, otherwise there is no point.

The goal is for the verifier to know a Verifiable Presentation was created using Verifiable Credentials from a specific set of Issuers BUT without receiving a Holder-specific cryptographic value that the Issuer know about. So that the verifier knows it comes from the issuer, but without knowing from which holder exactly. This won't help unlinkability is issuer and verifier work together on linking back.

"Issuer unlinkability is technically impossible"

Well! It is already being developed at ZKorum using Dock's (BBS+) Anonymous Credentials under the hood.

Unlinkability does not end at blinding signature. Even in voting use case additional data content promote linkability. What about the IP address of the voting citizen, the submission timestamp, the camera at the voting site?

With BBS+, Verifiable Presentations do not need to contain the traditional user's DID signature.

A BBS+ Anonymous Credential contains one or more attributes signed by the issuer; attributes and the signature together make up the credential. Anonymous credentials allow to hide any number of attributes and the signature (always) while proving the knowledge of the signature by the issuer (zero-knowledge proof). We are too focussed on technical aspects. Before we look at BBS+ or SD-JWT, let analyze some real use cases, and we will see event the best ZK-Tech will not prevent linkability.

Therefore, verifier can verify the Presentation by being sure it comes from the Issuer without having the information about which credential it is exactly: that means the verifier does not know from which holder it comes from exactly.

On top of that, users may generate anonymous pseudonyms (Pedersen commitments) so that the verifier can uniquely identify users. It helps with moderation, spam prevention and DDoS attacks mitigation.

• If you want to uniquely identify a user@verifier, per verifier identity key-pair sounds simpler. This shall not be the binding key!
• In some cases you don't want to correlate single presentations sent to the same verifier. Then you do not add the user@verifier signature to the presentation. Recall that use case analysis will reveal lot more to do to prevent content & metadata based linkability.

  Obviously, I'm not saying this is perfect, there are probably some flaws, I am happy if you can point them out and help the community to build privacy!

  "Issuer unlinkability is not important/useful and is not worth investing in"

  I don't know for you but I don't want my government to know everything I am doing in my life.

There is better way to achieve this, than having government issue credentials and technically try to blind them.

I think it is important to remain aware that one of the main difference between a democracy and a totalitarian country is the amount of data and control the authorities have over their citizens.

Yes, we all know this and I assume that is why many of us are here!

Democracies purposingly refuse to know too much, because that would give them too much power.

No privacy = no freedom

If we expect Verifiable Credentials to become pervasive in the world, and be used by much more verifiers than the official ones of today, we should expect at least the same amount of privacy we get today.

Today, most shops don't require KYC, and those who do DO NOT record an unforgable cryptographic identifier that can forever link you with the actions you've done.

Today the organizations that require IDs (verifiers) are usually kinda official, so issuer unlinkability isn't much of a problem for them. But what if your random company now requires your ID for using their service because they think it is private? Well no, in democracies, people in their right mind will not accept. So, wide-adoption will (hopefully) not occur. Wide adoption can only occur with issuer unlinkability, because citizens don't want (and should not want) Big Brother to know every little thing they do in life.

These are the problems we are trying to solve here. Let focus on real use cases and how to implement them in a privacy preserving way. First workflow and data, then the blinding techniques.

[nicobao]

I disagree with you on the two aspects of your post:

• "issuer unlinkability is technically impossible"
• "issuer unlinkability is not important/useful and is not worth investing in"

Issuer unlinkability is very important to me. But the misleading technical discussions occurring here do not address the point.

Clarifying what "issuer unlinkability" means

Of course, the verifier must know that a credential comes from a specific issuer, otherwise there is no point.

The goal is for the verifier to know a Verifiable Presentation was created using Verifiable Credentials from a specific set of Issuers BUT without receiving a Holder-specific cryptographic value that the Issuer know about. So that the verifier knows it comes from the issuer, but without knowing from which holder exactly.

This won't help unlinkability is issuer and verifier work together on linking back.

It does help, because the verifier does not receive a cryptographic identifier that the issuer can use to link back to the holder's identity. So even if the issuer and the verifier collude, it doesn't matter: privacy is in the holder's hand entirely.

"Issuer unlinkability is technically impossible"

Well! It is already being developed at ZKorum using Dock's (BBS+) Anonymous Credentials under the hood.

Unlinkability does not end at blinding signature. Even in voting use case additional data content promote linkability. What about the IP address of the voting citizen, the submission timestamp, the camera at the voting site?

That's true, we're only addressing the tip of the iceberg with application-level unlinkability. Without it though, nothing can work.

For transport-level unlinkability, there are decentralized proxy or VPN, aka mixers such as Tor or more recently Nym or HOPR which are under active development.

For timestamp, it's a problem I address in the link I sent above. We must "schedule-send" votes/poll responses whenever enough people have registered for it. Note that this protocol can be simplified to apply to arbitrary post and data, not just votes or polls.

No need for camera, we're talking online applications.

With BBS+, Verifiable Presentations do not need to contain the traditional user's DID signature.

A BBS+ Anonymous Credential contains one or more attributes signed by the issuer; attributes and the signature together make up the credential. Anonymous credentials allow to hide any number of attributes and the signature (always) while proving the knowledge of the signature by the issuer (zero-knowledge proof). We are too focussed on technical aspects. Before we look at BBS+ or SD-JWT, let analyze some real use cases, and we will see event the best ZK-Tech will not prevent linkability.

Therefore, verifier can verify the Presentation by being sure it comes from the Issuer without having the information about which credential it is exactly: that means the verifier does not know from which holder it comes from exactly.

On top of that, users may generate anonymous pseudonyms (Pedersen commitments) so that the verifier can uniquely identify users. It helps with moderation, spam prevention and DDoS attacks mitigation.

• If you want to uniquely identify a user@verifier, per verifier identity key-pair sounds simpler. This shall not be the binding key!
• In some cases you don't want to correlate single presentations sent to the same verifier. Then you do not add the user@verifier signature to the presentation. Recall that use case analysis will reveal lot more to do to prevent content & metadata based linkability.

I don't understand what you mean, could you rephrase?

Obviously, I'm not saying this is perfect, there are probably some flaws, I am happy if you can point them out and help the community to build privacy!

"Issuer unlinkability is not important/useful and is not worth investing in"

I don't know for you but I don't want my government to know everything I am doing in my life.

There is better way to achieve this, than having government issue credentials and technically try to blind them.

I am assuming the way you think about is traditional top-down vote with different authorities responsible for different parts of the flow. That's a very "official" use-case for verifying credentials in a standard top-down physical voting scheme. That's not what I am addressing. I address bottom-up polling/posting as well as non-critical digital voting.

I think it is important to remain aware that one of the main difference between a democracy and a totalitarian country is the amount of data and control the authorities have over their citizens.

Yes, we all know this and I assume that is why many of us are here!

Then why do you propose giving up on one of the main value that verifiable credentials brings (privacy)? The line is slim between creating a tool for liberating free expression and creating a tool for controlling what everybody does.

Democracies purposingly refuse to know too much, because that would give them too much power.

No privacy = no freedom

If we expect Verifiable Credentials to become pervasive in the world, and be used by much more verifiers than the official ones of today, we should expect at least the same amount of privacy we get today.

Today, most shops don't require KYC, and those who do DO NOT record an unforgable cryptographic identifier that can forever link you with the actions you've done.

Today the organizations that require IDs (verifiers) are usually kinda official, so issuer unlinkability isn't much of a problem for them. But what if your random company now requires your ID for using their service because they think it is private? Well no, in democracies, people in their right mind will not accept. So, wide-adoption will (hopefully) not occur. Wide adoption can only occur with issuer unlinkability, because citizens don't want (and should not want) Big Brother to know every little thing they do in life.

These are the problems we are trying to solve here. Let focus on real use cases and how to implement them in a privacy preserving way. First workflow and data, then the blinding techniques.

Posting, voting and responding to polls anonymously and yet in a verified way is a real use-case. TeamBlind is an example that there is a demand for such online forum. But TeamBlind:

• relies on weak privacy guarantees: users must trust them and their infrastructure obfuscation
• uses email verification to organize users into communities, which is not as granular and official as Verifiable Credentials

With BBS+ credentials and issuer unlinkability, we can go further. What if we had a forum where every verified European Citizens could anonymously discuss the current state of the EU Digital Identity Wallet? Not only the small community of world experts here on GitHub, but also the targeted users - the European Citizens? Today it is not possible without top-down polls that only very few people respond to, and social network don't do KYC so we don't know who said what. This will be possible on ZKorum if the EU issues BBS+ credentials. Users could not only prove they are Europeans but also prove their credentials such as diploma or work field, because the relevance of the opinion of someone on a topic often depends on the person's knowledge and experience in the field. We could have all that, while preserving privacy.

Without issuer unlinkability (SD-JWT Credential for example), the above forum wouldn't be private, because the governments would know which citizen said what.

Again the technique exposed above can be used for arbitrary data, not just posting, polls or votes.

Thanks to issuer unlinkability we can allow for any applications to segregate user account with the other data the user generates. Nobody can link the user data to the user account yet we know it is verified coming from some kind of community. That's a disruptive innovation that makes impossible use-cases possible and create a new market for a new generation of digital products.

Note that like I said in my first post, I am not against Europe issuing SD-JWT credentials, as I understand that more official use-cases involving official verifiers have heavier requirements on security and weaker requirements on privacy. Those requirements focus mainly on the identity theft protection aspect of Verifiable Credentials. Even though I am convinced the requirements on privacy for those use-cases should be higher, I can accept that the current technology status requires trade-offs. For now, I think it is fine that the two types of Credentials co-exists, so long as the privacy guarantees of both types of credentials are well-understood and that the usage of SD-JWT credentials remains segregated to verifiers that are regulated organizations already requiring KYC today.

[wbl]

SD-JWT is Simple but needs Usage Instructions SD-JWT is simple and can provide RP-Unlinkability if used the right way.

* batch issuance

* single use credential with unique binding key. After selectively disclosing a VC, we discard it.

* no issuance timestamp

* valid in (Week-1, Month-2, Year 2023 -> no timestamp)

* expires (End of Week, Month, Year -> no timestamp)

* revocation pools (non-membership proofs)

Everything else has to be done with unlinkability in mind...

Does the ARF say these things have to be done that way? The SD-JWT draft in the IETF does not, and I can't find it in the ARF. Then there's the issue of binding keys to enclaves to prevent lifting. That's a unique identifier that users might not realize is unique when told what is being revealed from the credential.

Furthermore it isn't clear that issuer tracking can be excluded from the Web threat model. Especially when we see proposals for age tracking, the temptation is to use a selective reveal of age. Unfortunately websites likely to implement age restrictions are also sensitive ones where the government may in the future want to determine who visited them. Also the issuers of these credentials might not be the government directly, or may be compromised by other parties.

This isn't the only privacy leak on the web. But we can't close any of them if every time people point to others and say "that's worse".

[OBIvision]

I think this thread clearly document that ARF is nowhere near providing what is claimed, i.e. "Citizen in control of personal data".

IMHO among other reasons because the SOG-IS has failed to understand that of course public sector services should be upgraded to pseudonymous instead of merely "trusted" to achieve anything resembling a democratic structure where the state does not accumulate personal data on citizens into evermore invasive dossiers. Repeat - IMHO SOG-IS is clearly not up-to-date and still discuss and insist on some obsolete thinking on persistent unique identifiers. They are part of the problem and haven't even caught up to where we were 10 years ago New Digital Security Models}.

So what is critically important is to avoid monopolization around immature "ARF wallet definition" in eIDAS - we need a right to challenge and upgrade to better structures according to the GDPR state-of-the-art principle to avoid some technical committee overriding fundamental rights without being accountable to law or elected to regulate. I foresee the present models to be rejected by e.g. the German Bundesverfassungsgericht.

When that is said, two aspects deserves pointing out. 1) Complexity is maximal and making a one-side-fits-all are unlikely to give justice to the multiplicity of requirements. More often than not some technical models is claimed to solve a problem without considering the damages to other aspects. E.g. in CitizenKey we do not accept revocation but work with graceful degradation instead - simply because enabling revocation create nasty unresolved problems. Another aspect is that most designs do not take into account the problems of combining credentials from multiple sources with integrity without creating linkability.

2) We can get these things right, but we should probably NOT assume some standardized one-side-fits-all magic solution - because even if we could it would be obsolete before it was rolled out. This field moves much faster and we need to design for continuous change to remain relevant.

[ryanbnl]

Given that the EP just voted against banning state spyware and the current obsession with unworkable regulation such the "chat control' rules it is prudent to do everything to ensure that EUDI doesn't become a tool to meet those nefarious ends.

If the specifications have a weakness which would allow otherwise avoidable tracking it will absolutely be abused. Thus the specifications should exclude such weaknesses now, at a time when it is cheap and easy to do so.

There's a risk that technologists will rally against the entire idea and combined with the usual vendor incompetence it'll be eIDAS 1.0 v2.

[francis-pouatcha]

@nicobao With BBS+ credentials and issuer unlinkability

With my modest understanding of blinded signature, i still can not figure out how BBS+ (and associated techniques) guaranty issuer unlinkability. I am missing a simple, but concrete use case in wich:

• holder is known to issuer but receives blinded credentials
• holder is known to verifier (physically) but presentation is anonymous
• and we can not link issued and presented credentials.

[francis-pouatcha]

On top of that, users may generate anonymous pseudonyms (Pedersen commitments) so that the verifier can uniquely identify users. It helps with moderation, spam prevention and DDoS attacks mitigation.

• If you want to uniquely identify a user@verifier, per verifier identity key-pair sounds simpler. This shall not be the binding key!
• In some cases you don't want to correlate single presentations sent to the same verifier. Then you do not add the user@verifier signature to the presentation. Recall that use case analysis will reveal lot more to do to prevent content & metadata based linkability.

I don't understand what you mean, could you rephrase?

I am referring to the unique identification of a user by a verifier. The simples way to proceed with this is to have user maintain an identity key per verifier. Showing proof of possession of both credential key and user identity key binds the user (holder) to the attested attribute.

[francis-pouatcha]

SD-JWT is Simple but needs Usage Instructions SD-JWT is simple and can provide RP-Unlinkability if used the right way.

* batch issuance

* single use credential with unique binding key. After selectively disclosing a VC, we discard it.

* no issuance timestamp

* valid in (Week-1, Month-2, Year 2023 -> no timestamp)

* expires (End of Week, Month, Year -> no timestamp)

* revocation pools (non-membership proofs)

Everything else has to be done with unlinkability in mind...

Does the ARF say these things have to be done that way? The SD-JWT draft in the IETF does not, and I can't find it in the ARF. Then there's the issue of binding keys to enclaves to prevent lifting. That's a unique identifier that users might not realize is unique when told what is being revealed from the credential.

Furthermore it isn't clear that issuer tracking can be excluded from the Web threat model. Especially when we see proposals for age tracking, the temptation is to use a selective reveal of age. Unfortunately websites likely to implement age restrictions are also sensitive ones where the government may in the future want to determine who visited them. Also the issuers of these credentials might not be the government directly, or may be compromised by other parties.

This isn't the only privacy leak on the web. But we can't close any of them if every time people point to others and say "that's worse".

Neither ARF nor recommended techniques (SD-JWT, BBS+, CL, ...) emphasize on those details. This is why we are using this github channel to send back feedback to eIDAS team.

[nicobao]

@nicobao With BBS+ credentials and issuer unlinkability

With my modest understanding of blinded signature, i still can not figure out how BBS+ (and associated techniques) guaranty issuer unlinkability. I am missing a simple, but concrete use case in wich:

• holder is known to issuer but receives blinded credentials
• holder is known to verifier (physically) but presentation is anonymous
• and we can not link issued and presented credentials.

Blinding credential is orthogonal to issuer unlinkability. (Blinded credential is only useful in my case for generating an anonymous pseudonym that is always the same over time, a requirement for counting unique respondents to poll responses, and for spam prevention.)

BBS+ achieves issuer unlinkability by using something called "Schnorr signatures". There is one signature per attribute in the credential.

The Issuer knows and trusts the Holder and the Holder knows and trusts the Issuer. That's always the case with Verifiable Credentials.

The Holder does not need to be known to the Verifier physically, though it's not problematic. Generally speaking, they don't interact physically, at least not for my use-cases.

When the Holder digitally presents a Verifiable Presentation to the Verifier, the Holder doesn't show the Schnorr signatures directly, but instead the Holder shows a proof of knowledge of these signatures.

The Verifier receives these proofs, verifies them, and is convinced that the Holder has a valid credential without having the information of the actual signatures.

Because the Verifier doesn't have the signatures themselves, the Verifier does not have data that the Verifier could give to the Issuer and ask for the real identity of the Holder (issuer non-correlability).

Also the proofs themselves are unique each time a Verifiable Presentation is created, so Verifiers cannot correlate proofs between each other as well.

No DID is ever necessary on the Holder side, so no unique identifier here as well.

I hope it is more clear, don't hesitate if you have questions.

EDIT:

I am referring to the unique identification of a user by a verifier. The simples way to proceed with this is to have user maintain an identity key per verifier. Showing proof of possession of both credential key and user identity key binds the user (holder) to the attested attribute.

As exposed above, no Holder DID is involved in Holder-Verifier interaction with BBS+. I believe that's what you call identity and credential key. But we still need the Holder to provide some kind of unique identifier to the Verifier side to count responses to a poll or vote, to allow users to create an "anonymous profile" based off their BBS+ Anonymous Credentials, and to implement moderation/spam mitigation mechanisms.

That's when Pseudonyms come into play. Pseudonyms are Pedersen commitments based on attributes of the BBS+ Credentials and/or on a secret value generated directly on the Holder's device and never shared to anyone else. This is a little bit technical, so I encourage you to read through the documentation I sent you above (from crypto-wasm-ts repo and from the ZKorum organization). Don't hesitate to ask questions, I am happy to respond further, but maybe outside this thread so we don't spam others. You can DM me on any social network linked on my GitHub, or even better you can open an issue at https://github.com/zkorum/zkorum/issues so anyone interested can get involved.

[OBIvision]

@nicobao With BBS+ credentials and issuer unlinkability

With my modest understanding of blinded signature, i still can not figure out how BBS+ (and associated techniques) guaranty issuer unlinkability. I am missing a simple, but concrete use case in wich:

* holder is known to issuer but receives blinded credentials

* holder is known to verifier (physically) but presentation is anonymous

* and we can not link issued and presented credentials.

Politely. You are forgetting that

1) the holder do not need to be "known" to the issuer - he can be pseudonym and thus data locked to the purpose (as data should be). Problem is that the ARF only assume Issuers that identify citizens, not even minimum security here.

2) there are many situation where person-to-person can (e.g. your neighbors teenager sitting at the checkout in the supermarket) or will/should (e.g. treating staff in hospitals) involve identification, but where the critical aspect is to avoid identification in systems/collecting personal data. People forgive/forget and personal memory is hard to search - it is the digital collection of personal data as result of identification that destroy rights and society fundamentals.

3) presented credentials can and should be able to be reused in the new context together with new data created.