All PID formats MUST explicitly define a pseudonym version

[OBIvision]

Description

Basic trustworthy security has to start with a pseudonymous PID

A pseudonymous PID involves the two main security models - trustworthy anonymity and trustworthy pseudonymity. The difference between the two is if an accountability proof/credential has been added in the customization process.

Trustworthy Anonymity involved PID keys relying parties can trust but only for services that do not require accountability - e.g. healthcare research, simple age verification, access to political media, military/national security applications etc.

Trustworthy pseudonymity or just Trustworthy Security involves all security context compliant to eIDAS that DO NOT create "identified or identifiable" personal data except for a data minimized accountability process where e.g. a judge limited by the necessity criteria can determine guilt before sentencing de-anonymization.

User Story

Any citizen: The user can be any citizen in any use case
Trustworthy security: The agenda is to empower the citizens
Goal: Avoid creating the security risk / GDPR, market and Cybersecurity compliance.

Almost all present user stories represent untrustworthy models where either some gatekeeper entity are in control of personal data that should not have been created in the first place. You cannot resolve the problem as an add-on if the transaction is built on "trusted anchors" and leaking personal data upfront.

Acceptance Criteria

The basic acceptance criteria is that infrastructure SHOULD NOT be able to determine if two transaction are with the same or two different citizens with the same group credentials (e.g. citizenship/jurisdiction).

This is a MINIMUM REQUIRED SECURITY measure to ensure the technical specification comply with the eIDAS regulation enforcing a technical block on pseudonymity that is explicitly allowed and preferably required unless explicit contextual legal reasons prevent this by eIDAS.

This is a MINIMUM REQUIRED SECURITY measure as GDPR dynamic require adaptation of state-of-the-art data minimization according to the necessity principle and eIDAS 2.0 acknowledge pseudonymity in electronic signatures in par with electronic signatures incorporating persistent identifiers such as e.g. name or national id numbers.

Customization to the specific security context is then an add-on process.

The main requirement is the ARF upgrade to explicitly support pseudonymity in all PID formats in order NOT to hardcode dependency on "trusted parties" (by definition not trustworthy design) and security weaknesses such as dependency on key revocation in the basic structures. An alternative to key revocation schemes is e.g. graceful degradation.

Group credentials can be used to separate between legitimate transactions and attacks in such a way that the cybersecurity counter-measures can be established and activated WITHOUT exposing citizens to harm.

Scenario 1: Basic network access

The citizen client either generate a new pseudonymous PID with a QSCD, or cryptographically derive a new pseudonymous PID from cryptographic proofs (e.g. zero-knowledge or as the German Id Card have been able to for almost two decades).

Notice that CA certification of the pseudonymous PID can both occur centrally at the CA and decentralized in the QSCD.

[jinza]

It is not necessary to explicitly support pseudonymy in all PID formats.
PIDs should be represented according to national identification formats, which may vary from country to country. When the user needs to give some information to "informed parties" (also known as "relying parties") in a way that does not disclose the information included in the PID, there are several options, such as "attestations" with pseudonymity information or attestations based on "zero knowledge proofs".

[OBIvision]

It is not necessary to explicitly support pseudonymy in all PID formats. PIDs should be represented according to national identification formats, which may vary from country to country. When the user needs to give some information to "informed parties" (also known as "relying parties") in a way that does not disclose the information included in the PID, there are several options, such as "attestations" with pseudonymity information or attestations based on "zero knowledge proofs".

Politely, this is not even beginning to resolve the need. A ZK-model cannot replace a qualified unlinkable signature as it cannot support digital transactions. Long list of problems.

Furthermore - reuse of data from an unlinkable session require RPs to act as Unlikable Issuers.

[OBIvision]

When the user needs to give some information to "informed parties" (also known as "relying parties") in a way that does not disclose the information included in the PID,

The issue is not about "give some information", but construction a full new non-linkable identity for every single transaction.
If the client holds credentials that would need revocation in cases of theft/loss or other transfer of credential control, the structure would be vulnurable.

The default should be pseudonymous and linkable persistent identification the exception.

[OBIvision]

PIDs should be represented according to national identification formats, which may vary from country to country.

Indeed. National identity differs - but you cannot call yourself a democracy if you force citizens to always expose themselves in digital transactions. Pseudonymous PID is a necessary precondition for democracy.

Start with something as basic as freedom of speech. If you cannot access political media without feeding political profiling and you can only express yourself identified (i.e. restricted to what is compatible with your job) even such fundamental rights are subdued.

[OBIvision]

It is not necessary to explicitly support pseudonymy in all PID formats. PIDs should be represented according to national identification formats, which may vary from country to country. When the user needs to give some information to "informed parties" (also known as "relying parties") in a way that does not disclose the information included in the PID, there are several options, such as "attestations" with pseudonymity information or attestations based on "zero knowledge proofs".

Politely, disagree entirely,

1. zero-knowledge proofs may eventually grow mature are not even close in the "verified credential" version.
2. There are many aspect that are not handles by Zero-knowledge proofs, e.g. conditional disclosure.

We need to make empowerment the default or the entire eIDAS 2.0 will fail.

[digeorgi]

Thank you for your input and further comments, which we have read with interest. The topic of pseudonymous or anonymous authentication is an important one and discussions on it are still ongoing. The same applies to linkability and the potential use of Zero-Knowledge Proofs.

Regarding pseudonyms: We are evaluating different options with the Member States, such as FIDO WebAuthn. We would welcome detailed proposals for other methods from you as well.

Regarding linkability: The formats for attestations that are currently proposed in ARF are ISO/IEC 18013-5 and SD-JWT VC. We are aware that these formats do not protect against an issuer colluding with relying parties. Again, we would welcome detailed proposals for alternative (signature) formats that do not have this limitation.

In both cases it is important, however, that such proposals are readily implementable. For example, they must use cryptographic algorithms that are approved by SOG-IS and are implemented widely on WSCDs currently available to mobile phones.

This issue will be converted into a Discussion to allow for further elaboration. We are looking forward to your further contributions.

[ad-Orange]

@digeorgi
You say you want to have a « discussion » to « allow for further elaboration » but we have posted a proposal « Regarding unliinkability » that « use cryptographic algorithms that are approved by SOG-IS and are implemented widely on WSCDs currently available to mobile phones » almost a month ago. I am yet to see an answer or even any sort of feedback to it…
Do you have any rational way to explain this situation ?

[OBIvision]

Description

Basic trustworthy security has to start with a pseudonymous PID

The PID-rulebook as-is cannot support trustworthy security. Simple as that.

A simple problem of many - any RP will generate data that can and must be able to be reissued, i.e. where the RP act as Issuer.
But as as all Trustworthy Identities have to be unlinkable, so is the enrollment with the RP - meaning that they cannot issue a non-pseudonym PID as they simple do not and should not have access to the data.

it seems increasingly clear from the writing on pseudonyms and unlinkability that the ARF is ignoring the very purpose of eIDAS 2.0 making the technical implementation non-compliant with the content and purpose of regulation.
ZK-proofs are not going to save the day.