Topic A: Privacy risks and mitigations

[skounis]

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

This discussion is based on Topic A: Privacy Risks and Mitigations discussion paper.

The paper provides background information, context, and initial proposals for mitigating privacy risks associated with tracking and tracing in the EUDI Wallet ecosystem. The paper explores challenges such as:

• Risks to user privacy, particularly those arising from collusion between Relying Parties or between a Relying Party and an Attestation Provider.
• Existing countermeasures in the ARF and their limitations.
• Potential technical solutions, including Zero-Knowledge Proofs (ZKP), and organizational measures to address these risks.

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.

[jurajsarinay]

Can you think of other approaches to mitigate the threat of tracking (within the context of the currently specified attestation formats)?

Confidential computing.

The systems of any reasonable relying party should be programmed to discard all the "unique elements" after verifying attestations. There is a risk that some relying parties might not do so. Let us leave them no choice then. Make relying parties perform the sensitive computations within an appropriately programmed secure enclave.

The wallet would present a credential only to a trusted SGX enclave after a successful remote attestation. The enclave would verify the credential and only report the validity and the disclosed attributes to the "untrusted" surrounding code. The relying party would never get to access the unique elements than can be used for tracking, this would be enforced by CPU hardware.

One would have to restrict what software & hardware the relying parties use. This is not entirely unfair, wallet users will have little choice, too.

Secure enclaves get you pseudonyms and privacy friendly revocation "for free".

[sander]

With the current Regulation text, is it possible to legally impose such restrictions on Relying Parties? If not, could the ARF still be a tool to encourage meeting such requirements, for example by providing “ARF v1.7-compliant” RPs with more opportunities than non-compliant RPs? I believe a similar discussion was held with regard to requiring RPs to use a QSCD or secure cryptographic device to protect their certificates.

[joelposti]

A property of these attestation formats is that every attestation that is presented to a Relying Party contains a number of elements having a unique value. These elements include:

• The salt of every attribute that is presented,
• The hash values of all attributes, that were signed by the Attestation Provider,
• The attestation identifier or index used for revocation purposes (if applicable),
• The attestation public key used for device binding and User binding,
• The value of the Attestation Provider signature.

Another set of correlators in addition to the ones listed in the discussion paper (cited above) are the sealing and validity timestamps. In the mdoc PID those would be the signed, validFrom and validUntil timestamps in the issuerAuth[2].validityInfo object, and in the SD-JWT VC PID the iat, nbf and exp timestamps. If those timestamps are granular and identical enough between presentations, the relying party can either pinpoint the user or at least narrow down the list of previously seen users to a smaller group of users whose timestamps are within some small time window.

These correlating timestamps and/or other correlators in the above list combined with the user IP (in the case of remote presentation flow) and user's behaviour in the RP's service gives the RP a good idea of who the user is.

[sander]

Thank you for sharing these considerations. These have been an important driver for the work on #282.

Note that the saw-tooth model for once-only values along with the fallback to a reduced-privacy multiple-use value has been deployed at scale in the Signal X3DH protocol (one-time prekeys and signed prekeys).

I will post my feedback about discussion paper A version 0.5 in several comments, to facilitate follow-up.

[sander]

Regarding the second point above: An Attestation Provider can employ at
least four different methods to achieve this: […]

Wallet Providers, PID Providers and Attestation Providers may be overwhelmed by the presented options. Consider recommending the simplest method A as a sane default. This can be combined well with the first revocation method: only issue short-lived attestations having a validity period of 24 hours or less.

[sander]

Drawback 2 of method A is a more general issue: Wallet Providers, PID Providers and Attestation Providers should perform proper capacity management based on the forecasted use of their products and on the characteristics of their infrastructure.

There is no need for the ARF to prescribe a particular model here: just like with other infrastructure, providers will develop best practices. At least for QEAA Providers, their terms and conditions may limit the amount of attestations issued within a certain subscription period. Wallet Providers, PID Providers or PuB-EAA Providers may do the same or have some fair-use policy.

In the provider’s capacity management, a common infrastructure bottleneck is the provider’s QSCD. See sander/hierarchical-deterministic-keys#1 for a proposal to eventually optimise this. Such optimisation may become necessary especially once providers need to start applying post-quantum cryptography for their signatures or seals.

[sander]

To the maximum extent possible, Wallet Providers, PID Providers, and Attestation Providers SHALL ensure that Users do not notice which of the methods referenced in requirement 3 is used for their PIDs, attestations, or WUAs, and that Users will not be involved in managing the re-issuance of new attestations.

This proposed requirement seems good for UX in general, but the user does have the right to know what implications a provider’s policy may have for their privacy. Consider requiring a Wallet Provider to inform the user in general about the linkability risks, and to enable the user to figure out the details of a specific attestation or request if they want.

[sander]

Wherever the proposed requirements state “the value of the Attestation Provider signature”, it should be “the representation of the Wallet/PID/Attestation Provider signature or seal”.

[sander]

When receiving a PID, attestation, or WUA a Relying Party Instance SHALL discard the values of all unique elements, including at least the ones mentioned in requirement 1 above, as soon as they are no longer needed. The Relying Party Instance SHALL NOT communicate these values to the Relying Party or to any other party in the EUDI Wallet ecosystem."

This proposed requirement seems disproportional. There are valid use cases for a Relying Party to persist a PID/attestation/WUA with the disclosed attributes, in such a way that they themselves and other parties can verify integrity and authenticity of the document issued by its provider. This is an important reason to require qualified e-signatures or e-seals under such documents: these enable re-use and long-term preservation.

See Document Extract for an example use case and technical proposal for such reuse. This requires persisting and communicating at least some of the values in requirement 1.

It is also difficult to enforce such requirements on Relying Party Instances. Instead, what about adding a conditional “unless the Relying Party Instances explicitly asks the user for consent to persist and share these values, stating the purpose for this reuse”?

[AEPDmbeltran]

On behalf of the Spanish Data Protection Authority (AEPD)

The attached document contains our comments and responses on this topic.

topicA AEPD response.pdf

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

[phin10]

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

AEPD: We recommend data protection compliance to be a topic in itself, with sufficient time to discuss it and incorporate it into the ARF. The ARF should be established to facilitate compliance with the GDPR. Issues related to accountability and ecosystem governance, responsibilities in the processing of personal data, international transfers, etc., need to be explicitly discussed.

Response: Although we make a best effort to provide personal data protection, a GDPR assessment is out of scope of the ARF and will be performed separately, by another body.

AEPD: The current title of this topic does not reflect its content. The topic is entitled "Privacy risks and mitigations" but focuses solely on Relying Party linkability, which could be seen as a limited approach” […].

Response: The scope of the paper was defined to be:
- Risks to user privacy, particularly those arising from collusion between Relying Parties or between a Relying Party and an Attestation Provider.
- Existing countermeasures in the ARF and their limitations.
- Potential technical solutions, including Zero-Knowledge Proofs (ZKP), and organizational measures to address these risks.
We recognize that all privacy risks mentioned in the risk register are equally important and will be discussed in subsequent topics.

AEPD: Concerning the Relying party linkability, the actual topic discussed now, we think that it would be beneficial to properly manage the risk from a data protection perspective to separate two types of wallet use cases clearly: 1) use cases in which the user must identify themself to the Relying Party and 2) use cases in which the user must not identify themself to the Relying Party. […] Both types of use cases are affected by different threats and risks. For example, the risk of Relying party linkability, exhaustively analysed in the published discussion paper, should only concern the second group, for which technical and organizational measures must be provided to avoid or mitigate it.

Response: We agree with your comment. For this reason, we require the provider to create policies defining which privacy mechanisms should be used (Requirement 9). We have also defined requirements related to the “organizational measures” you are mentioning (e.g., Requirement 12 and Requirement 17).

AEPD: It is essential to promote preventive measures, both technical and organizational (that avoid or mitigate the risk) over reactive or "repressive" measures (that act once an incident has already occurred). This is data protection by design and by default […]

Response: We agree with this approach. However, currently, it does not seem possible to use reactive measures only and mitigate all linkability threats. Method A is defined in the ARF to implement unlinkability by design. On top of this, ZKP is also discussed in topic G - Zero Knowledge Proof.

AEPD: To prevent the Attestation Provider from […] ; Methods B and C […].

Response: Overall, we agree with your comments, and we have tried to capture these observations in the discussion paper. Attestation Providers should make a policy decision based on these observations as well as their particular use cases.

AEPD: We advise promoting other attestation formats relying on randomized or blind signatures and anonymous credentials, at least for the second group of use cases (not requiring users' identification).

Response: This is discussed in topic G - Zero Knowledge Proof.

AEPD: As we have already said, method A is the only one that avoids the risk of linking […].

Response: During the focus group meetings use cases where methods B or C are more suitable were identified. But Wallet Solutions are still required to support method A.

AEPD: […] Users should have control over the attestations stored in their wallets and the ability to request the deletion of attestations that are no longer needed, for example.

Response: These issues are discussed in topic B - Re-issuance and batch issuance of PIDs and Attestations.

AEPD: […] However, we advise assessing revocation mechanisms based on cryptographic accumulators or other kinds of zero-knowledge proofs to prove the validity of an electronic attestation without revealing any information.

Response: These issues are discussed in topic G - Zero Knowledge Proof.