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.