jinza
commented
10 months ago 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
digeorgi
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.