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 (#66 (comment) ) or not possible to implement (#66 (comment) ) .

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.

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

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.

I have a reasonable understanding of ec-crypto and Schnorr signatures. Months ago, I documented my understanding of schnorr on my github for non crypto folks. After reading thru the BBS IETF draft, i still do not understand how you use the schnorr arithmetic to achieve issuer unlikability.

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

Issuer and verifier know the content of the disclosed credentials. Hopefully there is not enouth entropy in the credential data to achieve linkability at content level.

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.

From reading the spec, this proof looked too complex to me, I really did not understand the math. It shall be simple enough to show common folk that there is no backdoor.

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.

I could understand that BBS+ allows Holder to present a proof on knowledge of a valid signature, without disclosing that signature. What i am missing everywhere is de definition of a valid signature. Can i really conclude a signature valid without knowing the issuer or the pool of issuers? We do need real use cases to move forward here.

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

I many use cases, the attribute data themself will contain enough entropy to help issuer/verifier linkability.

...

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.

A unique identifier is a unique identifier. spam mitigation implies linkability. The more we link at verifier side, the easier it is to link back at issuer.

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.

Pseudonyms are unique identifiers!

Thank for the hint on zkorum. I will try to allocate some reading time to it.

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

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.

We need real use cases. In most of them, holder will be known to issuer.

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.

Without being too ideological, i still do believe issuer unlinkability can not yet be solved with technology, as we don't have enough visibility on the extent of possible use cases. This is why EU technical standards will for the mean time foresee some sort of supervision/accreditation of issuers.

[nicobao]

@francis-pouatcha that's the last time I respond here, because I am worried of spamming others, as we're gradually drifting off-topic. Nevertheless, feel free to reach out in the ZKorum monorepo directly.

I have a reasonable understanding of ec-crypto and Schnorr signatures. Months ago, I documented my understanding of schnorr on my github for non crypto folks. After reading thru the BBS IETF draft, i still do not understand how you use the schnorr arithmetic to achieve issuer unlikability.

I think the problem here is our definition of issuer unlinkability differs. Issuer unlinkability doesn't mean not knowing that a Verifiable Presentation comes from a Credential that was issued by an Issuer. It means if the Verifier gives the Presentation to the Issuer, the Issuer will not know from which Holder exactly it comes from.

Issuer and verifier know the content of the disclosed credentials. Hopefully there is not enouth entropy in the credential data to achieve linkability at content level.

[...]

I many use cases, the attribute data themself will contain enough entropy to help issuer/verifier linkability.

That's a good point, but there are solutions. I address the problem here: zkorum/zkorum#6 (part on the "American Student").

From reading the spec, this proof looked too complex to me, I really did not understand the math. It shall be simple enough to show common folk that there is no backdoor.

Hmm, I am pretty sure it is well understood. Many things we use in life are only understood by a bunch of experts and it's fine!

I could understand that BBS+ allows Holder to present a proof on knowledge of a valid signature, without disclosing that signature. What i am missing everywhere is de definition of a valid signature. Can i really conclude a signature valid without knowing the issuer or the pool of issuers? We do need real use cases to move forward here.

Again, the same problem with the definition of issuer unlinkability. Of course the Verifier knows and trusts the Issuers, and knows the Presentation comes from some Issuer, it's wanted! The issue we solve is Holder privacy in the hands of the Holder: no need to trust that Issuers and Verifiers don't collude. And in my case, Verifiable Presentations are public data, so it's even worst. No need for collusions: without issuer unlinkability, Issuers could just get the public Verifiable Presentations from the forum and know who said what.

A unique identifier is a unique identifier. spam mitigation implies linkability. The more we link at verifier side, the easier it is to link back at issuer.

Pseudonyms are unique identifiers!

You've not read the documentation I linked, that's why you say that ;)
As I hinted in previous posts, pseudonyms are created from a 32 bytes long secret value generated directly on the Holder side.
A Pseudonym is a Pedersen commitment. It sort of behaves like a hash. Knowledge of the pedersen commitment does not allow for guessing the pre-image, yet it's deterministic: you'll always get the same pseudonym from the same inputs.
ZKorum is able to "register" a ~unique "secret value" by issuing it to the forum user via an attribute of a Blinded Credential.
For more info, check out the links I sent. I am happily awaiting your concerns on a ZKorum issue!

Thank for the hint on zkorum. I will try to allocate some reading time to it.

Thank you for taking time for it. We will release the closed alpha by the end of the year and have a whole University as our first users.

Without being too ideological, i still do believe issuer unlinkability can not yet be solved with technology, as we don't have enough visibility on the extent of possible use cases. This is why EU technical standards will for the mean time foresee some sort of supervision/accreditation of issuers.

The above forum is not ideological, it's getting real! And it does require issuer unlinkability.

[OBIvision]

@francis-pouatcha

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.

We need real use cases. In most of them, holder will be known to issuer.

Actually - every single application except the root national structure SHOULD DEFAULT be pseudonymous and where possible anonymous according to GDPR as a way to operational data minimization. It is not even optional - see e.g. GDPR article 23 which do not make it possible to exclude the data minimization requirement in e.g. article 25 in national law.

It is a basic problem in ARF that all use cases are assuming the purpose is linkable identification/linkable issuance incorporating keys or credentials (e.g. name) establishing linkability. It should be the exception according to the GDPR state-of-the-art principle.

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.

Without being too ideological, i still do believe issuer unlinkability can not yet be solved with technology, as we don't have enough visibility on the extent of possible use cases. This is why EU technical standards will for the mean time foresee some sort of supervision/accreditation of issuers.

That is deeply ideological as it - IMHO illegally - enforce data retention on Issuers. It simply means that some bad technical standard established without political oversight are in conflict with the EU Treaty itself trying to override fundamental rights.

The consequence is enforcing digital architectures without internal security in Issuer applications as all data are inherently linkable across transactions. This was one of the main topics of my invited talk on state-of-the-art at EDPS Workshop on Digital Identity.

[OBIvision]

@nicobao

I think the problem here is our definition of issuer unlinkability differs. Issuer unlinkability doesn't mean not knowing that a Verifiable Presentation comes from a Credential that was issued by an Issuer. It means if the Verifier gives the Presentation to the Issuer, the Issuer will not know from which Holder exactly it comes from.

Without forcing a link to BBS+ as this is a about general requirements, issuer non-linkability is a bigger topic related to maintaining integrity when mixing credentials from multiple non-linkable sources in selective disclosure towards a new context.

It is also about the issuance process as a dependency on reusing keys across multiple issuances 1) establish linkability and 2) establish a dependency on key revocation.

[francis-pouatcha]

@nicobao

@francis-pouatcha that's the last time I respond here, because I am worried of spamming others, as we're gradually drifting off-topic. Nevertheless, feel free to reach out in the ZKorum monorepo directly.

I would rather stay here, as the purpose of this discussion is to contribute to the ETSI TR 119 476 technical report on selective disclosure

BTW:
For clarification, I am a full privacy advocate, and I do not support issuer linkability in any form.

I have no affiliation to SD-JWT and do have objective discussions on SD-JWT weaknesses with others in other forums. Obvious issuer linkability is one of those.

I also do have nothing against BBS+. I feed off crypto-algorithms and as soon a I understand the math, I will document it for mortals.

Neither am I defending the ARF in it current form.

It is a shame there is only one reaction on my critic on HW-defined Secure Environment and Privacy above. Not event the ack of @Sebastian-Elfors-IDnow that request comments on the ETSI document.

If this forum is for advertising products, fighting for adoption of own technologies, European Tech will fail again!

...
From reading the spec, this proof looked too complex to me, I really did not understand the math. It shall be simple enough to show common folk that there is no backdoor.

Hmm, I am pretty sure it is well understood. Many things we use in life are only understood by a bunch of experts and it's fine!

This is not true! The world has witnessed a lot of backdoors in used and not well understood crypto over the years. We want to keep these risks at their lowest.

Some technologies like pairing, zk circuits do not have enough academical contributions on their formal analysis to be considered safe for the commons now. With time things will look different as lot of contribution from crypto networks is pushing for adoption. On the other hand, schnorr on the other side is simple and straight forward. But in the EC-world, the curve used also matters. BBS+ seems to be a combination of all of those, and it has to presented as such to the audience here.

DeFi/Crypto networks are being hacked every weekend!!! This shall send us great signals on complexity.

...

A unique identifier is a unique identifier. spam mitigation implies linkability. The more we link at verifier side, the easier it is to link back at issuer.
Pseudonyms are unique identifiers!

You've not read the documentation I linked, that's why you say that ;) As I hinted in previous posts, pseudonyms are created from a 32 bytes long secret value generated directly on the Holder side. A Pseudonym is a Pedersen commitment. It sort of behaves like a hash. Knowledge of the pedersen commitment does not allow for guessing the pre-image, yet it's deterministic: you'll always get the same pseudonym from the same inputs. ZKorum is able to "register" a ~unique "secret value" by issuing it to the forum user via an attribute of a Blinded Credential. For more info, check out the links I sent. I am happily awaiting your concerns on a ZKorum issue!

Keeping this at a non expert level, as long as pseudonyms allow the verifier to identify the holder, they are together characterized a unique identifier in the context of that verifier. No tech will help here! There is no need to guess pre-images when i can correlate on the commitments.

Thank for the hint on zkorum. I will try to allocate some reading time to it.

Thank you for taking time for it. We will release the closed alpha by the end of the year and have a whole University as our first users.

I navigated the project. Great one. Great idea. And I do understand the absolute need of ZKorum. And this is neutral and not publicity for ZKorum either, as I have no affiliation to it.

...

Without being too ideological, i still do believe issuer unlinkability can not yet be solved with technology, as we don't have enough visibility on the extent of possible use cases. This is why EU technical standards will for the mean time foresee some sort of supervision/accreditation of issuers.

The above forum is not ideological, it's getting real! And it does require issuer unlinkability.

I do believe you. But I think we all massively underestimate the effort needed to achieve real issuer unlinkability.

[Sebastian-Elfors-IDnow]

@nicobao

@francis-pouatcha that's the last time I respond here, because I am worried of spamming others, as we're gradually drifting off-topic. Nevertheless, feel free to reach out in the ZKorum monorepo directly.

I would rather stay here, as the purpose of this discussion is to contribute to the ETSI TR 119 476 technical report on selective disclosure

BTW: For clarification, I am a full privacy advocate, and I do not support issuer linkability in any form.

I have no affiliation to SD-JWT and do have objective discussions on SD-JWT weaknesses with others in other forums. Obvious issuer linkability is one of those.

I also do have nothing against BBS+. I feed off crypto-algorithms and as soon a I understand the math, I will document it for mortals.

Neither am I defending the ARF in it current form.

It is a shame there is only one reaction on my critic on HW-defined Secure Environment and Privacy above. Not event the ack of @Sebastian-Elfors-IDnow that request comments on the ETSI document.

If this forum is for advertising products, fighting for adoption of own technologies, European Tech will fail again!

...
From reading the spec, this proof looked too complex to me, I really did not understand the math. It shall be simple enough to show common folk that there is no backdoor.

Hmm, I am pretty sure it is well understood. Many things we use in life are only understood by a bunch of experts and it's fine!

This is not true! The world has witnessed a lot of backdoors in used and not well understood crypto over the years. We want to keep these risks at their lowest.

Some technologies like pairing, zk circuits do not have enough academical contributions on their formal analysis to be considered safe for the commons now. With time things will look different as lot of contribution from crypto networks is pushing for adoption. On the other hand, schnorr on the other side is simple and straight forward. But in the EC-world, the curve used also matters. BBS+ seems to be a combination of all of those, and it has to presented as such to the audience here.

DeFi/Crypto networks are being hacked every weekend!!! This shall send us great signals on complexity.

...

A unique identifier is a unique identifier. spam mitigation implies linkability. The more we link at verifier side, the easier it is to link back at issuer.
Pseudonyms are unique identifiers!

You've not read the documentation I linked, that's why you say that ;) As I hinted in previous posts, pseudonyms are created from a 32 bytes long secret value generated directly on the Holder side. A Pseudonym is a Pedersen commitment. It sort of behaves like a hash. Knowledge of the pedersen commitment does not allow for guessing the pre-image, yet it's deterministic: you'll always get the same pseudonym from the same inputs. ZKorum is able to "register" a ~unique "secret value" by issuing it to the forum user via an attribute of a Blinded Credential. For more info, check out the links I sent. I am happily awaiting your concerns on a ZKorum issue!

Keeping this at a non expert level, as long as pseudonyms allow the verifier to identify the holder, they are together characterized a unique identifier in the context of that verifier. No tech will help here! There is no need to guess pre-images when i can correlate on the commitments.

Thank for the hint on zkorum. I will try to allocate some reading time to it.

Thank you for taking time for it. We will release the closed alpha by the end of the year and have a whole University as our first users.

I navigated the project. Great one. Great idea. And I do understand the absolute need of ZKorum. And this is neutral and not publicity for ZKorum either, as I have no affiliation to it.

...

Without being too ideological, i still do believe issuer unlinkability can not yet be solved with technology, as we don't have enough visibility on the extent of possible use cases. This is why EU technical standards will for the mean time foresee some sort of supervision/accreditation of issuers.

The above forum is not ideological, it's getting real! And it does require issuer unlinkability.

I do believe you. But I think we all massively underestimate the effort needed to achieve real issuer unlinkability.

Dear @francis-pouatcha (and the rest who comment in this thread),

Thanks for all your feedback and comments on ETSI TR 119 476, the ARF, and ZKP schemes in general.

We are following the discussion in this thread, but it is not possible to comment on all statements on a regular basis. So far we have received comments in this thread, by email, LinkedIn and other channels that exceed 100 pages. When the deadline for comments ends on October 13, we will compile all feedback, analyze it, and present the suggested changes to ETSI ESI, which will form the basis for the next revision of ETSI TR 119 476.

Kind regards,
Sebastian

[cyberphone]

May I as a genuine party-pooper present some real-world observations?
In order to interact with any kind of service you typically have provide your e-mail address and/or mobile phone number; both representing a GUID (Globally Unique Identifier).

The we have the use-cases. How is tax collection supposed to be carried out if the tax department does not have your "dossier"?

That Microsoft never managed to do anything useful with their investment in Uprove, indicates that market acceptance is not yet a reality.

[wbl]

@cyberphone Age verification is an example where the information being exchange is not inherently identifying

[cyberphone]

@wbl Right, in scenarios where you don't have a "relation" with a service provider, the mentioned issue doesn't apply. These use cases are though not particularly common.

[OBIvision]

May I as a genuine party-pooper present some real-world observations?

You mean off-topic.

The only relevant aspect is that U-Prove is of the same crypto-family as BBS (e.g. no dependence on key revocation) and U-Prove has a lot more needed functionality than is standardized withing BBS.

It does not change the fact that constructing identity in all U-Prove/VC turned out to be quite hard especially if you want an open market with many issues, relying parties and technology providers.

In order to interact with any kind of service you typically have provide your e-mail address and/or mobile phone number; both representing a GUID (Globally Unique Identifier).

You are clearly confusing the ability to reference, communicate and indirectly ensure integrity with means for identification. These are two entirely different issues but always at the application layer.

The we have the use-cases. How is tax collection supposed to be carried out if the tax department does not have your "dossier"?

Law makers in general tend to forget the implications on implementation when they make complex rules (e.g. marginal tax rates require knowledge of total income and deductions), but we can make taxation as secure as we want to.

If we validate trustworthy at source, we can make trustworthy taxation that do not need to know details. See e.g. this Danish Government report on training government officials even in complex cases
https://blog.privacytrust.eu/public/Reports/NewDigitalSecurityModels.pdf

That Microsoft never managed to do anything useful with their investment in Uprove, indicates that market acceptance is not yet a reality.

You can make al sorts of assumptions on what didn't happen. Personally I would suggest BigTech would never bite their own profit interests so they are the worst to provide security for society - only second to state bureaucracy. Microsoft twisted U-prove for MS interests (e.g. Card Space even though better than "One Wallet to rule them All" and choice of C#)

But the real reason was timing as the client-side technologies such as smartcards hadn't matured - and timing/paradigm as the depth of the problems hadn't matured in the institutional space. E.g. GDPR (2018) and eIDAS (2016) only emerged after Microsoft abandoned the effort and the main people either left (Stefan Brands and Caspar Bowden) or died (Kim Cameron). EU regulatory process certainly miss Caspar Bowden.

[OBIvision]

@wbl Right, in scenarios where you don't have a "relation" with a service provider, the mentioned issue doesn't apply. These use cases are though not particularly common.

People have relations with people - not with providers, even through you might have with specific people at providers (e.g. doctor, teacher, etc). Providers would like to see you as a relation in order to "manage" you for their profit - which is why technology needs to ensure maintaining a distance is both possible and default even if providers offer e.g. loyalty bonus pricing.

[cyberphone]

I'm just saying that the unlinkability of BBS and similar technologies seems to be at odds with the way we are currently communicating with service providers and people.

[OBIvision]

I'm just saying that the unlinkability of BBS and similar technologies seems to be at odds with the way we are currently communicating with service providers and people.

You are describing a problem that crypto is trying to solve, not a property that we should maintain. Presently markets don't work because consumers are reduced to products and all the power is on providers side.

[digeorgi]

Thank you for the insightful discussion and feedback.
The item has been transferred in the "Discussions" as it is not considered an issue. The topics discussed in "Discussions" will be considered in the next versions of the ARF.