diff --git a/docs/arf.md b/docs/arf.md index 1fa6e7a..dd58c9c 100644 --- a/docs/arf.md +++ b/docs/arf.md @@ -1332,8 +1332,8 @@ Instance. To be able to comply with such requests, these parties need to trust each other. This trust generally requires the existence of the following two conditions: -1. The requestee is sure about the requester\'s identity, and - optionally the requester is sure about the requestee\'s identity. +1. The requestee is sure about the requester's identity, and + optionally the requester is sure about the requestee's identity. This is referred to as (single-side or mutual) *authentication*. 2. The requestee is sure that the requester has the right to request diff --git a/docs/discussion-topics/a-privacy-risks-and-mitigations.md b/docs/discussion-topics/a-privacy-risks-and-mitigations.md index 51df659..0b84d4a 100644 --- a/docs/discussion-topics/a-privacy-risks-and-mitigations.md +++ b/docs/discussion-topics/a-privacy-risks-and-mitigations.md @@ -1,8 +1,9 @@ Version 0.5, updated 11 December 2024 -# Introduction +# A - Privacy risks and mitigation +## Introduction -## Discussion Paper topic description +### Discussion Paper topic description This document is the Discussion Paper for eIDAS Coordination Group regarding Topic A: Privacy risks and mitigation. @@ -33,7 +34,7 @@ such as Zero-Knowledge Proofs (ZKP).* **In this version of this document, the feedback of Member States during the first meeting of December 4th, 2024, was processed.** -## Related risks in the Risk Register +### Related risks in the Risk Register The risk register for European Digital Identity Wallets \[RiskRegister\] contains the following risks regarding User tracking as a result of @@ -79,7 +80,7 @@ Attestation Provider: Surveillance, or monitoring, is defined as the unauthorised tracking -or observation of a wallet user’s activities, communication, or data. +or observation of a wallet user's activities, communication, or data. Surveillance is often related to inference, which is defined as the deduction of sensitive or personal information from seemingly innocuous data. @@ -99,7 +100,7 @@ data. Wholesale surveillance is defined as the tracking or observation of -the activities of many users through their wallet’s communication or +the activities of many users through their wallet's communication or data. Wholesale surveillance is often associated with surveillance (R14) and inference at a global scale, where information about many users is combined to deduce sensitive or personal data about users or to identify @@ -158,19 +159,19 @@ required. -## Key words +### Key words -This document uses the capitalized key words ‘SHALL’, ‘SHOULD’ and ‘MAY’ +This document uses the capitalized key words 'SHALL', 'SHOULD' and 'MAY' as specified in RFC 2119, i.e., to indicate requirements, recommendations and options specified in this document. -In addition, ‘must’ (non-capitalized) is used to indicate an external +In addition, 'must' (non-capitalized) is used to indicate an external constraint, for instance a self-evident necessity or a requirement that -is mandated by an external document. The word ‘can’ indicates a -capability, whereas other words, such as ‘will’ and ‘is’ or ‘are’ are +is mandated by an external document. The word 'can' indicates a +capability, whereas other words, such as 'will' and 'is' or 'are' are intended as statements of fact. -## Document structure +### Document structure This document is structured as follows: @@ -190,17 +191,17 @@ This document is structured as follows: - Chapter 6 proposes a few High-Level Requirements to be added to the ARF. These are for discussion. -# Risks for User privacy due to collusion +## Risks for User privacy due to collusion -## Linkability +### Linkability This chapter describes in detail how the attestation formats currently specified for use in the EUDI Wallet ecosystem could be misused for -tracking the User’s behaviour. +tracking the User's behaviour. The attestation formats required to be supported in the ARF are -specified in ISO/IEC 18013-5 \[ISO18013-5\] and “SD-JWT-based Verifiable -Credentials (SD-JWT VC)” \[SD-JWT VC\]. Both of these formats enable +specified in ISO/IEC 18013-5 \[ISO18013-5\] and "SD-JWT-based Verifiable +Credentials (SD-JWT VC)" \[SD-JWT VC\]. Both of these formats enable selective disclosure of attributes by making use of so-called salted-attribute hashes. For more information on this technique, see \[ETSI 119476\]. In a nutshell, the idea is that an Attestation Provider @@ -229,7 +230,7 @@ unique value. These elements include: - The value of the Attestation Provider signature. In addition, also timestamps, such as the signing or issuing time of the -attestation and the ‘valid from’ and ‘valid until’ timestamps may be +attestation and the 'valid from' and 'valid until' timestamps may be unique, if they are precise enough. For example, if the timestamps include milliseconds, this will almost always be the case. @@ -246,7 +247,7 @@ Linkability comes in two varieties, Relying Party linkability and Attestation Provider linkability. These are discussed in the next sections. -## Relying Party linkability +### Relying Party linkability Relying Party linkability means that one or more malicious Relying Party are able to link multiple presentations of the same attestation. For @@ -270,7 +271,7 @@ used at multiple Relying Parties. By combining the attribute values that were presented during each of these interactions, they will be able to build a profile of the User. -Also note that linkability of attestations can be a danger to the User’s +Also note that linkability of attestations can be a danger to the User's privacy even if Relying Parties are not actively trying to track Users. If a Relying Party (or multiple Relying Parties) is the victim of a data breach by an attacker, and the data breach includes unique attestation @@ -288,7 +289,7 @@ particular, Relying Parties found offending can have their access certificate revoked, after which they will not be able to interact with Wallet Units anymore. -## Attestation Provider linkability +### Attestation Provider linkability Attestation Provider linkability means that one or more Relying Parties collude with the provider of an attestation to track the User when using @@ -312,7 +313,7 @@ discourage Attestation Providers from colluding and tracking Users. In addition, many Attestation Providers are subject to regular audits, which means that collusion and tracking can more easily be detected. -## WUAs and Wallet Providers +### WUAs and Wallet Providers The Wallet Unit Attestation (WUA) is an attestation issued to the Wallet Unit by the Wallet Provider. In the context of this discussion paper, @@ -322,13 +323,13 @@ and the mitigation measures for Relying Party linkability described in the next chapter can also be used by Wallet Provider to mitigate the Relying Party linkability risks associated with presenting WUAs. -Therefore, in this discussion paper the term ‘Attestation Provider’ +Therefore, in this discussion paper the term 'Attestation Provider' includes Wallet Providers, in their specific responsibilities as issuers of WUAs. -# Possible mitigation measures for Relying Party linkability within the current ARF +## Possible mitigation measures for Relying Party linkability within the current ARF -## Introduction +### Introduction An (honest) Attestation Provider can mitigate Relying Party linkability mitigated partly or fully by the following two measures: @@ -356,20 +357,20 @@ These methods are discussed in the next sections of this chapter. Based on these discussions and an inventory of the opinion of Member States, Chapter 6 contains a number of changes that will be made to the ARF. -## Method A: Once-only attestations +### Method A: Once-only attestations -### Description +#### Description In this approach, the Attestation Provider requires the Wallet Unit to present each attestation only once. -### Advantages +#### Advantages If this approach is used, none of the unique values in the attestation will be issued twice or more times to a Relying Party. Therefore, this method fully mitigates Relying Party linkability. -### Technical impacts on Wallet Unit +#### Technical impacts on Wallet Unit If an attestation may be presented only once, in theory the Wallet Unit could request a new attestation as soon as possible after an attestation @@ -384,7 +385,7 @@ To prevent the Wallet Unit from running out of unused attestations, it must have a lower limit for the number of unused attestations it holds and request a new batch from the Attestation Provider when the number of unused attestations goes below this limit, as soon as it is able to. -This is called the ‘saw-tooth model’ in inventory management. +This is called the 'saw-tooth model' in inventory management. If this approach is used and the Wallet Unit is offline for a prolonged period of time, the Wallet Unit may run out of unused attestations. To @@ -402,7 +403,7 @@ the Wallet Unit has run out of unused attestations and is not able to request new ones, it will start re-using either a single attestation or a batch of attestations, as described for these methods. -### Drawbacks +#### Drawbacks A drawback of this method is that the number of attestations to be issued depends on the frequency of use. This has two effects: @@ -414,21 +415,21 @@ issued depends on the frequency of use. This has two effects: the use of the attestation to the Attestation Provider. 2. This method may mean imply unpredictability regarding the load on - the Attestation Provider’s systems. If a User uses their attestation + the Attestation Provider's systems. If a User uses their attestation frequently, the Attestation Provider will have to issue many attestations. On the flipside, if an attestation is seldomly used, the Attestation Provider will have to issue very few attestations per year. This is because the validity period of the attestation can be chosen very long if an attestation is presented at most once - anyway, without negative effects to the User’s privacy. + anyway, without negative effects to the User's privacy. Another drawback of this method is that the Attestation Provider is dependent on the correct implementation by the Wallet Unit to ensure that it is used correctly. -## Method B: Limited-time attestations +### Method B: Limited-time attestations -### Description +#### Description In another approach, a Wallet Unit may present each attestation multiple times, but only as long as it is valid. Moreover, the Wallet Provider @@ -437,7 +438,7 @@ is statistically unlikely that any of the unique values in the attestation can be effectively used by colluding Relying Parties to correlate and track the User. -### Advantages +#### Advantages The biggest advantages of this method are: @@ -456,11 +457,11 @@ The biggest advantages of this method are: the Attestation Provider does not get any information about the frequency of use of their attestations. -### Technical impacts on Wallet Unit +#### Technical impacts on Wallet Unit None, as described above. -### Drawbacks +#### Drawbacks The main drawbacks of this method are @@ -480,15 +481,15 @@ The main drawbacks of this method are be Users will an above-average attestation usage. These Users will therefore be subject to a higher level of risk of tracking. -## Method C: Rotating-batch attestations +### Method C: Rotating-batch attestations -### Description +#### Description Using this method, the Attestation Provider issues attestations in batches to the Wall Unit, like when using once-only attestations (method A). However, in method C a Wallet Unit uses the attestations in a batch a random order, until it has used all attestations in the batch once. -Then it ‘resets’ the batch and starts using them again, again in a +Then it 'resets' the batch and starts using them again, again in a random order. A batch may consist, for instance, of 20 attestations. If so, any @@ -512,27 +513,27 @@ Transport Systems (C-ITS). The OpenID4VCI specification used for attestation issuance in the EUDI Wallet ecosystem supports batch issuance. -### Advantages +#### Advantages If this approach is used, the number of attestations to be issued is constant over time and does not depend on usage. Therefore, like method B, this method does not leak information to the Attestation Provider and -ensures a constant and predictable load for the Attestation Provider’s +ensures a constant and predictable load for the Attestation Provider's systems. Moreover, compared to method B this method increases the level of privacy, especially for attestations that are used quite frequently. Or, to put the same thing in a different way, if a batch of attestations is used in a rotating fashion, the validity period of an attestation can be -longer without impacting the User’s privacy. +longer without impacting the User's privacy. -### Technical impacts on Wallet Unit +#### Technical impacts on Wallet Unit The Wallet Unit must implement dedicated functionality to support this method, for example to keep track of which attestations are used and unused, and when a batch is fully used and must be reset. -### Drawbacks +#### Drawbacks This method has the following drawbacks: @@ -557,7 +558,7 @@ This method has the following drawbacks: actually been used or not. Therefore, this approach seems suitable only if the User presents attributes to Relying Parties frequently. -## Method D: Per-Relying Party attestations +### Method D: Per-Relying Party attestations When this method is used, the Wallet Unit will present different attestations to different Relying Parties. However, in case a Relying @@ -569,7 +570,7 @@ In fact, this method can be seen as a mixture of methods A and B described above: it uses method A for different Relying Parties, and method B for recurring Relying Parties. This implies that all of the respective advantages and disadvantages of these methods apply also for -this method. The ‘weight’ of these advantages and disadvantages will +this method. The 'weight' of these advantages and disadvantages will depend on whether the User interacts a few times with a large number of different Relying Parties, or, on the contrary, tends to interact a larger number of times with only a small number of Relying Parties. @@ -583,7 +584,7 @@ authenticate themselves to Wallet Units contain a unique identifier of the Relying Party. However, it represents an extra effort for the Wallet Unit, and it may complicate attestation inventory management. -## General note: Diminishing the costs of issuing multiple attestations +### General note: Diminishing the costs of issuing multiple attestations The operational costs of issuing an attestation are determined to some extent by the requirement that, for security reasons, the Wallet Unit @@ -608,9 +609,9 @@ batch issuance of PIDs and Attestations) and Topic C (Wallet Unit Attestation (WUA) and key attestation), respectively. They will therefore not be further discussed here. -# Ensuring User privacy when checking the revocation status of attestations +## Ensuring User privacy when checking the revocation status of attestations -## Introduction +### Introduction For the revocation of PIDs and attestations (including WUAs), the ARF specifies three methods: @@ -628,11 +629,11 @@ be able to verify that the Attestation Provider has not revoked the attestation. When discussing the risk of tracking Users, particular attention should be given to this process. -## General requirements +### General requirements To the maximum extent feasible given operational constraints, the Attestation Provider should not be able to learn anything about the -User’s use of an attestation based upon interactions between Relying +User's use of an attestation based upon interactions between Relying Parties and the Attestation Provider related to attestation revocation checking. @@ -649,7 +650,7 @@ Downloading an Attestation Status List or Attestation Revocation List SHALL NOT require the Relying Party or Relying Party Instance to authenticate itself in any way. -## Requirements specific for Attestation Status Lists +### Requirements specific for Attestation Status Lists To ensure User privacy specifically when the Attestation Provider uses Attestation Status Lists to enable revocation checking, this document @@ -672,7 +673,7 @@ recommends the following: not able to deduce which attestation (likely) was presented to that Relying Party. -# Mitigating linkability by using Zero-Knowledge Proofs +## Mitigating linkability by using Zero-Knowledge Proofs Zero-Knowledge Proofs (ZKP) offer strong potential as a privacy-enhancing technique. This topic will be revisited in Topic G to @@ -681,19 +682,19 @@ integration, particularly focusing on defining specific requirements for implementing ZKPs by using any type of WSCD/WSCA. For further details, please see the 'Cryptographers' Feedback on the EU -Digital Identity’s ARF’ +Digital Identity's ARF' [(here)](https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework/issues/200), and the Commission's response to it [here.](https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework/discussions/211#discussioncomment-9882388) -# Additions to the ARF +## Additions to the ARF -## High-Level Requirements to be added to Annex 2 +### High-Level Requirements to be added to Annex 2 The High-Level Requirements in this section will be added to Annex 2 of the ARF v1.7. -### Requirements to be added (likely) to Topic 10/23 +#### Requirements to be added (likely) to Topic 10/23 1. A PID Provider, Attestation Provider, or Wallet Provider SHALL ensure that all PID, attestation or WUA unique elements, including @@ -886,7 +887,7 @@ attestation separately. > Note: For example, the parameters to be set for method A include the > lower limit for unused attestations and the batch size. -### Requirements to be added (likely) to Topic 1 +#### Requirements to be added (likely) to Topic 1 1. When receiving a PID, attestation, or WUA a Relying Party Instance SHALL discard the values of all unique elements, including at least @@ -895,7 +896,7 @@ attestation separately. these values to the Relying Party or to any other party in the EUDI Wallet ecosystem. -### Requirements to be added (likely) to Topic 7 +#### Requirements to be added (likely) to Topic 7 1. A Relying Party Instance SHOULD NOT request the relevant Attestation Status List or Attestation Revocation List each time an attestation @@ -932,7 +933,7 @@ requests a particular ASL, the Attestation List Provider is not able to deduce which PID or attestation (likely) was presented to that Relying Party. -## High-Level Requirements to be deleted +### High-Level Requirements to be deleted WUA\_09: A Wallet Provider SHALL consider all relevant factors, including the risk of a WUA public key becoming a vector to track the @@ -947,14 +948,14 @@ These two requirements can be deleted if the ones proposed in section 6.1 are added, because the proposed requirements include the Wallet Provider and are much more detailed than the above two requirements. -## Descriptions to be added to the ARF main document +### Descriptions to be added to the ARF main document A summary of the descriptions in chapter 2 will be added to section 6.1.3 of the ARF main document, version 1.7. A summary of the descriptions in chapter 3 will be added to section 6.6.5 of the ARF main document, version 1.7. -# References +## References diff --git a/docs/discussion-topics/b-re-issuance-and-batch-issuance-of-pids-and-attestations.md b/docs/discussion-topics/b-re-issuance-and-batch-issuance-of-pids-and-attestations.md index fdf52c8..3808cb4 100644 --- a/docs/discussion-topics/b-re-issuance-and-batch-issuance-of-pids-and-attestations.md +++ b/docs/discussion-topics/b-re-issuance-and-batch-issuance-of-pids-and-attestations.md @@ -1,6 +1,8 @@ -# Introduction +# B - Re-issuance and batch issuance of PIDs and Attestations -## Discussion Paper topic description +## Introduction + +### Discussion Paper topic description This document is the Discussion Paper for eIDAS Coordination Group regarding Topic B: Re-issuance and batch issuance of PIDs and @@ -15,7 +17,7 @@ example, requirements around authentication of the User and re-use of existing private keys may be different for first-time issuance and re-issuance, batch issuance or synchronous issuance of an attestation* -## Related risks in the Risk Register +### Related risks in the Risk Register The risk register for European Digital Identity Wallets \[RiskRegister\] contains no risks regarding re-issuance. This is because the risk @@ -23,19 +25,19 @@ register focuses on risks related to security and privacy, not on operational issues such as the difference between first-time issuance and re-issuance of attestations. -## Key words +### Key words -This document uses the capitalized key words ‘SHALL’, ‘SHOULD’ and ‘MAY’ +This document uses the capitalized key words 'SHALL', 'SHOULD' and 'MAY' as specified in RFC 2119, i.e., to indicate requirements, recommendations and options specified in this document. -In addition, ‘must’ (non-capitalized) is used to indicate an external +In addition, 'must' (non-capitalized) is used to indicate an external constraint, for instance a self-evident necessity or a requirement that -is mandated by an external document. The word ‘can’ indicates a -capability, whereas other words, such as ‘will’, ‘is’ or ‘are’ are +is mandated by an external document. The word 'can' indicates a +capability, whereas other words, such as 'will', 'is' or 'are' are intended as statements of fact. -## Document structure +### Document structure This document is structured as follows: @@ -54,9 +56,9 @@ This document is structured as follows: - Chapter 5 lists the additions and changes that will be made to the ARF as a result of discussing this topic with Member States. -# Re-issuance and batch issuance of PIDs and attestations +## Re-issuance and batch issuance of PIDs and attestations -## Description +### Description Version 1.5 of the ARF contains a large number of requirements regarding the issuance of PIDs and attestations, primarily in Topic 10/23 and also @@ -81,7 +83,7 @@ attribute values and validity period. In general, if the original PID or attestation was issued in a batch, then the PID Provider or Attestation Provider will re-issue that PID or attestation in a batch as well. -## Support by OpenID4VCI +### Support by OpenID4VCI The ARF requires that Wallet Units, PID Providers, and Attestation Providers use the \[OpenID4VCI\] specification for issuance of PIDs and @@ -118,7 +120,7 @@ Questions # Reasons for re-issuance -## Overview +### Overview There may be different reasons for re-issuing a PID or attestation, for example: @@ -139,7 +141,7 @@ The main reason for batch issuance of PIDs or attestations within the EUDI Wallet ecosystem is to (partly) mitigate Relying Party linkability. For this, see \[Topic A\]. -## PID or attestation nearing its end of validity or Wallet Unit running out of PIDs or attestations +### PID or attestation nearing its end of validity or Wallet Unit running out of PIDs or attestations As specified in \[ISO/IEC 18013-5\] or \[SD-JWT VC\], each PID or attestation contains metadata indicating its validity period. @@ -173,7 +175,7 @@ or attestation, where the User must take the initiative to request the PID or attestation, and is potentially involved in the process in other ways as well. These aspects are discussed in chapter 4. -## A change in attribute values +### A change in attribute values During the lifetime of a PID or attestation, the value of some of the attributes may change. For example, at the date of birth of the User, an @@ -189,7 +191,7 @@ on the User, because they will notice that their attribute values have been changed. For transparency reasons, it seems necessary to require that the Wallet Unit notifies the User about such a change. -## Synchronous issuing +### Synchronous issuing A third reason for re-issuing a PID or attestation is where the PID Provider or Attestation Provider uses synchronous issuing. In such an @@ -203,16 +205,16 @@ similar to the reasons discussed in section 3.2. Users should not notice that a PID or attestation is being re-issued, nor should they have to take any action to ensure that re-issuance happens. -# Differences between first-time issuance and re-issuance or batch issuance +## Differences between first-time issuance and re-issuance or batch issuance -## User authentication by PID Provider or Attestation Provider +### User authentication by PID Provider or Attestation Provider In \[Topic A\] a high-level requirement was established that, to the maximum extent possible, Users will not be involved in managing the re-issuance of new attestations. This is an important principle. Requiring that the User is involved in re-issuance processes would mean that a User is requested to perform actions that they did not initiate, -and for which they probably don’t understand the reason. This would lead +and for which they probably don't understand the reason. This would lead at least to a bad user experience, and most likely also to operational problems, such as Users not cooperating. Users may start to distrust their Wallet Unit if it unexpectedly keeps asking the User to @@ -263,10 +265,10 @@ Questions currently present in the WSCA, by using the DPoP mechanism in RFC 9449? -## User authentication and key management by the WSCA +### User authentication and key management by the WSCA The ARF v1.4 (and v1.5 as well) contains a requirement (WTE\_02 / -WUA\_02) stating that “a WSCA SHALL authenticate the User before +WUA\_02) stating that "a WSCA SHALL authenticate the User before performing any cryptographic operation involving a private or secret key of (…) a PID or an attestation in a Wallet Unit.” @@ -346,7 +348,7 @@ especially not since the User is not even aware of the concept of batch issuance, nor of the reasons for it. However, ARF 1.5.0 already contains the following note to requirement -WUA\_02: “Many actions of the Wallet Instance, such as processing a +WUA\_02: "Many actions of the Wallet Instance, such as processing a Relying Party request and presenting an attestation, require multiple cryptographic operations, for example ephemeral key generation followed by key agreement and message encryption. This requirement does not imply @@ -366,7 +368,7 @@ Questions 9. What do you think about User authentication in batch-issuance scenarios? -## Triggers for the issuance process +### Triggers for the issuance process The process of first-time issuance of a PID or attestation is triggered by the User, who wants to obtain a PID or attestation and triggers the @@ -379,7 +381,7 @@ Provider or Attestation Provider, or the Wallet Unit. However, it is not clear how the PID Provider or Attestation Provider can trigger the Wallet Unit to start the re-issuance processes. A Wallet Provider will typically be able to send a push message to a Wallet Unit, -which will cause the Wallet Unit to contact the Wallet Provider’s +which will cause the Wallet Unit to contact the Wallet Provider's backend to look for any updates or other actions. But PID Providers and Attestation Providers are different from Wallet Providers, generally speaking, and will typically not have this option. @@ -464,7 +466,7 @@ value anyway. This approach nevertheless has some drawbacks as well: lost the right to drive because of medical reasons or severe traffic violations. Such a User may refuse to trigger the re-issuance process because they want to continue using their existing PID or - attestation with the ‘old’ values. Obviously, the PID Provider or + attestation with the 'old' values. Obviously, the PID Provider or Attestation Provider can (and should) revoke the existing PID or attestation. But this implies that they should have a policy determining how they will deal with situations like this. @@ -489,9 +491,9 @@ Questions 14. Can you think of any other option? -# Additions and changes to the ARF +## Additions and changes to the ARF -## High-Level Requirements to be added to Annex 2 +### High-Level Requirements to be added to Annex 2 The following High-Level Requirements will be added to Annex 2 of the ARF v1.8: @@ -499,14 +501,14 @@ ARF v1.8: <To be added after discussion of this Discussion Paper with Member States.> -## High-Level Requirements to be changed +### High-Level Requirements to be changed <A future version of this document will analyse the requirements on issuance in v1.5 of the ARF and determine whether they need to be changed (and if so, how) in the light of the conclusions reached for this Discussion Paper.> -### Topic 10/23 +#### Topic 10/23
@@ -535,7 +537,7 @@ this Discussion Paper.>
-### Topic 9 +#### Topic 9 @@ -564,12 +566,12 @@ this Discussion Paper.>
-## Descriptions to be added to the ARF main document +### Descriptions to be added to the ARF main document A summary of the descriptions in chapters 2, 3, and 4 will be added to the ARF main document, version 1.8. -# References +## References