Topic V: PID rulebook

[phin10]

Welcome to the discussion on the PID rulebook, part of the ongoing development of the Architecture and Reference Framework (ARF) for the European Digital Identity (EUDI) Wallet.

This discussion is based on the document Topic V - PID rulebook.

Currently, W3C VCDM 1.1 is referenced in the implementing acts, though it is understood to be a placeholder pending a final technical decision. This is because, in its current form, VCDM 1.1 remains an incomplete framework, lacking the necessary specifications to fully support the implementation of an EUDI Wallet.

To finalize the list of requirements and related technical specifications for implementing the PID based on the current ARF approach which envisions issuing the PID in two formats:

• ISO/IEC 18013 series format, required for proximity scenarios.
• JSON-based format, better suited for online scenarios.

It is essential to fully define this second format by detailing all relevant aspects.

A clear and well-defined set of requirements and technical specifications for these components is crucial to accurately describe the PID and provide implementers with a robust framework for developing Wallet solutions.

In the current ARF, the decision leans toward adopting JWT-like Simple Attestations, which offer a simpler and widely compatible format, complemented by the SD-JWT-VC draft, but still several details are missing. Ongoing discussions emphasize the need to balance flexibility, interoperability, and security while avoiding unnecessary complexity.

This discussion is part of a structured process to refine and complete the ARF, with your input playing a vital role. We invite you to share your comments, insights, and suggestions here. Your contributions will be carefully reviewed and considered as we work towards the next version of the ARF, which will incorporate updates on this topic.

Thank you for participating in this important conversation.

[AEPDmbeltran]

On behalf of the Spanish Data Protection Authority (AEPD)

The attached document contains our comments on this topic.

topicV AEPD response.pdf

Thank you very much for this opportunity to contribute to this important discussion.

[joelposti]

Including embedded disclosure policies in the PIDs could further enhance user control. We advise explicitly defining HLRs concerning these policies in the PID rulebook.

This is something that I, as a representative of DVV (the Finnish Digital and Population Data Services Agency), have thought about as well. The current European Digital Identity Regulation does not say that a PID has to contain an embedded disclosure policy. There is a sentence about this in ARF section 6.6.3.4 Wallet Unit evaluates disclosure policy embedded in attestation, if present:

Note that the [European Digital Identity Regulation] does not contain a requirement for PIDs to be able to contain an embedded disclosure policy, but only for QEAAs and PuB-EAAs.

This is perhaps open to debate whether a PID can contain an embedded disclosure policy even though it is not required.

[phin10]

@AEPDmbeltran, thank you for your input to the discussion on topic V. Please find below the response of the @eu-digital-identity-wallet/arf-writers:

AEPD: The paper says that “privacy is a critical concern, especially regarding how attestation data is shared and verified”. As we have done in the past, we advise being as explicit as possible when making privacy considerations and setting out the associated requirements. It would be better to say “privacy is a critical concern, especially regarding how attestations are issued, stored, presented+verified and revoked”. Not all attestation data sharing involves the same technologies, protocols, responsibilities or risks.

Response: Partially accepted. We modified the text to “Privacy is a critical concern, especially regarding how attestation data is presented and verified”.

AEPD: As we have done on other occasions in the past, we wonder whether it would be possible to mention data protection in the ARF instead of privacy, as this would allow for explicit discussion of compliance issues (principles and requirements included in the GDPR). Considering privacy concerns in the ARF in a generic way does not guarantee that following this architecture would allow compliance with the GDPR, but considering data protection principles and requirements does.

Response: Please provide us with concrete text modification proposals.

AEPD: The discussion about isolated selective disclosure is not required if ZKP is used by default (ensuring selective disclosure given the HLR defined in topic G). But if ZKP is used by default, changes in attestation formats will likely be required (topic G: fields, metadata), and this will have implications for this PID rulebook. As has happened in the past, it is not easy to move forward in discussing some topics without knowing the decisions made for others.

Response: We provide more details on ZKP in topic G. If necessary, modifications to the PID rulebook will be considered then.

AEPD: We agree with “To ensure interoperability in the EUDI Wallet, it is crucial that we do not allow open-ended choices or support multiple, competing attestation models beyond a strict minimum”. But we are curious about the rationale supporting “Adding a third or more attestation models would introduce significant risks”. Why exactly two is the maximum number of formats that can be allowed? We have advised in the past to clearly differentiate between 1) use cases in which the user must identify themself to the Relying Party (perform identity verification) and 2) use cases in which the user must not identify themself to the Relying Party. A third attestation format allowing Anonymous Credentials, by design, would mitigate most of the data protection and privacy risks we are discussing in all the topics, avoiding adding such privacy as an “artificial” layer over formats that are not designed to guarantee properties such as unlikability, at least this could be considered for use cases within the group 2.

Response: Currently, there is no such attestation format that can be used with the EUDI wallet. We provide more details on ZKP in topic G.

AEPD: We advise explicitly addressing data subject rights within the PID rulebook. This could involve elaborating on how individuals can exercise their rights (access, rectification, erasure, etc.) in relation to the data included in these attestations, specifying procedures for data subjects to access and control their information held within issuers or including provisions on data portability.

Response: These are out of scope of topic V, these will be discussed in topics L, M and N.

AEPD: Including embedded disclosure policies in the PIDs could further enhance user control. We advise explicitly defining HLRs concerning these policies in the PID rulebook.

Response: EDP will be defined in PID issuer metadata. The contents of these policies are out of scope of Topic V.

[OBIvision]

A third attestation format allowing Anonymous Credentials, by design, would mitigate most of the data protection and privacy risks we are discussing in all the topics, avoiding adding such privacy as an “artificial” layer over formats that are not designed to guarantee properties such as unlikability, at least this could be considered for use cases within the group 2.
Response: Currently, there is no such attestation format that can be used with the EUDI wallet. We provide more details on ZKP in topic G.

The request is valid and the answer untrue. There is a third option which would be pareto optimal.

1. A PKI CA can today certify a Pseudonym Certificate (pseudonym PID). That would be what is called and standardised as an atomic credential. Such a credential would be already much better when we talk e.g. Schrems II as control of linkability would stay domestic / not in cloud.

2. This model can be upgraded through using a dedicated smartcard device acting as a satellite certification on behalf of the CA to prevent CA/Issuer linkability.

When so the issue of linkability become a specific issue of added credentials or proofs to customized to the specific need.
This atomic credential model was described at the EDPS Workshop on Digital Identity 2022 using WebAuthn pseudonyms as proof of state-of-the-art merely adding on-card certification / issuance of a Qualified Unlinkable PID.
https://www.edps.europa.eu/system/files/2022-07/03_-_stephan_engberg_-_edps_trustworthy_pki_engberg_20220622_en_0.pdf

This model is already standardized and simple to apply. It does however require strong clients to protect the keys.

It is noteworthy that this is not only about "privacy" or "data protection". E.g.

• avoiding reuse of identity
• eliminating the need for revocation
• creating a structure that can easily establish unlikable interoperability and integrity across issuers
• establishing a cryptographic witness supporting e.g. Data Portability even from credentials only related to unlinkable RP

represent just a few of the many security upgrades possible. Every single Use Case presently described for the ARF/Wallet could be upgraded to Qualified Unlinkable - and thus according to GDPR article 25, 32 and 35 MUST be.

[ad-Orange]

Data protection considerations
We deem it very strange that in chapter 5, the only ZKP technologies that are taken into account are of the “Proofs for arithmetic circuits (programmable ZKPs)” kind whereas the “Multi-message signature schemes”, including BBS# are not mentioned at all, whereas:

• BBS# is also leveraging ECDSA for holder binding which is a SOG-IS protocol. It can also use ECSDSA (which is also SOG-IS) but it is not as widely used.
• We’re not completely sure how much EU regulations should make themselves dependant on NIST, BBS# was indeed featured on a NIST workshop
• It matches all the deterministic requirements listed in topic G (in particular Req 9: all the “additional communication or information” cannot “be used to track or link User activity during, before, or after proof generation”) given the use of OIP tokens
• No public (or private, to our knowledge) security or privacy issue of BBS# has been reported
• Its core technology dates back to 2016
• BBS# privacy and security features were proven in the “BBS# protocol” document and confirmed in a recently released preprint
• It is already partially deployed in some commercial services

We think that chapter 5 should not reinstate the same debates already happening in Topic G and in any case, if the technologies shall be listed again, then please add BBS# and the papers referenced above.

We also think that privacy being a critical concern for eIDAS, the provision should be that “whatever it takes” will be done to update (optimally and pragmatically) the chosen technical specifications (or add new ones if necessary) to ensure the necessary data protection once a suitable ZKP scheme will have been decided upon (which should be soon given the timing constraints).

[OBIvision]

This discussion is based on the document Topic V - PID rulebook.

The PID rule-book is non-compliant with both the unlinkability requirement, NIS2 on state-of-the-art, basic needs for market competition to function on a fair basis and fundamental privacy regulation.

The main issues is that the rulebook exclude Pseudonym PIDs which means that the EU Commission - through preventing member states or new innovation upgrading structures from issuing unlinkable root identities or anchors - define EU as a surveillance-only domain as any anchor-point is assumed to be linkable. This was explicitly rejected as part of eIDAS 2.0 regulation process, yet re-introduced through non-compliant technical structures.

This problem CANNOT be resolved with zk-proofs as they are nowhere mature to establish a full identity suitable for engaging in transactions on equal basis as linkable identifikation identity. An additional problems is that this render smartphone-based wallets vulnurable as there is no way to procted data or structures from code change in the softkey-space or sidechannel surveillance.

The implication is inherent failure of eIDAS 2.0 as the technical implementation does NOT provide what was intended or needed for citizens to engage in basic transactions without creating linkable personal data.

Further notes:
Pseudonym PIDs are an addition to non-pseudonym PIDs as a pseudonym PID can be derived form a non-pseudonym PID or a non-pseudonym PID can be established through combining a pseudonym PID with linkable identifikation / proof of suitable attributes.

A pseudonym PID as an anchor MAY require additional transaction requirements to establish accountability, i.e. ex-ante deposited conditional means for e.g. a judge to establish link to a non-pseudonym PID. This should be limited in time for other than the citizen himself.

A pseudonym PID as an anchor MAY require additional transaction requirements to establish linkability across pseudonym PID, i.e. ex-ante deposited conditional means for e.g. a judge to establish link from a non-pseudonym PID to issued pseudonym-PID in such as way that such a link cannot be established without the judge intervention. This should be limited in time for other than the citizen himself.

Issuance of a Pseudonym PID can occur as a basic CA operation or in other qualified secure privacy-preserving ways which could involve e.g. WSCD/QCSD.

This is an absolute minimum with no known workarounds.