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

[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: https://github.com/zkorum/zkorum/issues/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.