Keywords

1 Introduction

Electronic identification aims at revolutionising the way users interact with online services. In the EU, electronic identification of citizens is at the discretion of the Member States. A handful of Member States have developed national schemes for electronic identification (eID) provision to their citizens, with their architectures varying to a large extend [9]Footnote 1. As a result, national systems differ not only in the amount of citizen data they process but also in the level of data protection they offer to these data.

Regulation 910/2014 on electronic identification and trust services (hereinafter eIDAS),Footnote 2 which came into force on 1 July 2016, enables cross-border interoperability of the diverse national eID schemes. eIDAS aims to create “a common foundation for secure electronic interaction between citizens, businesses and public authorities”Footnote 3 in order to “remove existing barriers to the cross-border use of electronic identification means.”Footnote 4 Chapter II “Electronic Identification” defines the principles required for cross-border eID use across EU Member States by specifying a common denominator in architecture and policies for national schemes to become interoperable. The eID scheme of Germany is the first that has become accessible by all Member States since 29 September 2018.

Meanwhile, the EU’s personal data protection framework has been updated by the General Data Protection Regulation (GDPR),Footnote 5 which introduced a risk-based approach to data protection and became directly applicable on 25 May 2018. The GDPR aims to facilitate the “free movement of personal data within the Union”,Footnote 6 in particular in a cross-border context,Footnote 7 while ensuring that the data subjects’ rights (and in particular their right to the protection of their personal data) are not violatedFootnote 8.

Article 25 of the GDPR introduces a new requirement of Data Protection by Design. The term is linked to Privacy by Design, a principle stemming from modern privacy engineering. Privacy by DesignFootnote 9 is advocating for privacy considerations that are embedded in the technology itself, from the design stage throughout the life-cycle of a system [11], rather than imposed only through soft policy measures.Footnote 10 The Privacy by Design Resolution, adopted in 2010 by the International Conference of Data Protection and Privacy Commissioners, stresses that Privacy by Design is a “holistic concept that may be applied to operations throughout an organization, end-to-end” [1].

Although Privacy by Design is increasingly explored in literature, the effect of the new requirement of the GDPR on design and architectural choices of online services, such as eID provision, remains partially uncertain. This is especially true since Data Protection by Design befalls data controllers and processors but not system designers, creating therefore inconsistencies as to how the obligation will be translated into system design. Neither eIDAS nor the GDPR offer specific guidance on the means to achieve Data Protection by Design, allowing room for interpretation by the data controllers. However, although eIDAS is technology-neutral,Footnote 11 its provisions and accompanying Implementing Acts define a set of requirements for national schemes. Consequently, there is a need to assess the extent and the means by which Data Protection by Design can be effected in the eIDAS Interoperability Framework. This becomes particularly important when considering that, even though eIDAS primarily targets public-sector online services, voluntary use of the eIDAS framework by private-sector services is actively encouraged.Footnote 12 In contrast to public-sector services, whose data dissemination practices are often regulated by national legislation, the private sector remains relatively free to decide how to comply with the data protection requirements of the GDPR.

One key question, therefore, is to assess the implications of Data Protection by Design upon the eIDAS Interoperability Framework, and determine whether the Interoperability Framework could be extended to maintain a high level of data protection in cross-border transactions with both public- and private-sector services.

In order to tackle this question, this paper employs an interdisciplinary approach through the use of three different methods: Desk research on Privacy by Design and its application for eID schemes, a synthesised assessment of the general guidance on Data Protection by Design and Data Protection Impact Assessments, and qualitative data collection through a series of interviews with experts in the field of eID. The desk research is used to identify the goals and methods of Data Protection by Design, and in particular how these goals are met in the context of eID. To fully identify its effects in the context of eID, Article 25 of the GDPR should be read in conjunction with Article 35 on Data Protection Impact Assessments, which are meant to provide a process through which the engineering of data protection principles and security measures shall be assessed [37]. Finally, the interviews, which followed a semi-structured format, were used to confirm the findings of the assessment and gave the opportunity to eID experts to express their opinion on Data Protection by Design for eID and the expected impact of eIDAS’ Interoperability Framework on participating schemes. Through thematic analysis, the transcripts established the current practices in eID schemes and the state-of-the-art in regards to Data Protection by Design. We refer to national eID schemes to illustrate how a state-of-the-art system will be impacted by the Interoperability Framework.

The paper is structured as follows: Sect. 2 provides an overview of the Interoperability Framework as defined by eIDAS and its Implementing Acts. We explain the link to the GDPR in Sect. 3 and examine the domain and effect of Data Protection by Design, through seven ‘data-protection goals’ as proposed by the German Standard Data Protection Model [15]. In Sect. 4 we examine how the Interoperability Framework meets the data protection goals and note that the goal of unlinkability is only partially met. We focus, thus, on unlinkability and analyse what unlinkability entails for eID schemes. We explain how the Interoperability Framework might in certain cases result in constrains on the level of unlinkability that can be supported in cross-border transactions in Sect.  5 and consequently propose a practical way to assure the Interoperability Framework can be extended to support a higher level of unlinkability in Sect. 6. A summary of our findings and concluding remarks can be found in Sect. 7.

2 The eIDAS Interoperability Framework

The cross-border communication of national eID schemes takes place through a set of nodes and related specifications that eIDAS names ‘Interoperability Framework’.Footnote 13 Communication between national eID schemes and service providers happens through ‘eIDAS nodes’.Footnote 14 eIDAS names the Member State whose notified eID scheme is used as the ‘sending Member State’ [17] and the Member State where the service provider resides as the ‘receiving Member State’ [17]. Two configurations are supported: The sending Member State can operate an eIDAS node domestically, which will relay authentication requests and assertions between the service providers of the receiving Member State and the national eID scheme (proxy configuration) [17]. Alternatively, the sending Member State provides an instance of their national eID scheme as an eIDAS node which is deployed to each receiving Member State (middleware configuration). The middleware is operated by operators at the receiving Member State [17].

eIDAS defines a set of ‘person identification data’Footnote 15 to be transmitted in cross-border identifications. Participating schemes need to satisfy a ‘Minimum Dataset’, which contains four mandatory and four optional attributes.Footnote 16 Mandatory attributes are the (a) first and (b) last names of the person, (c) their date of birth and (d) a unique identifier “as persistent as possible in time.”Footnote 17 In addition, the Minimum Dataset may contain (a) the first and last name(s) at birth, (b) the place of birth, (c) the current address and (d) the gender.Footnote 18 The Minimum Dataset is required in every cross-border identification.

eIDAS recognises that eID services have to perform data processing for the needs of electronic identification. Accordingly, Article 5(1) establishes that all processing should be carried out “in accordance with Directive 95/46/EC”, which has since been repealed by the GDPR.Footnote 19 Consequently the benchmark for data protection compliance under eIDAS is the GDPR. Interestingly, eIDAS seems to have anticipated the GDPR. Article 12(3)(c) of eIDAS mandates that the Interoperability Framework shall “facilitat[e] the implementation of the principle of Privacy by Design;” and Article 5(2) provides that “the use of pseudonyms in electronic transactions shall not be prohibited.” In addition, the explanatory recital in the preamble refers to the principle of data minimisation.Footnote 20 However, even if eIDAS seems to acknowledge the importance of Data Protection by Design, it is arguable whether the way the Interoperability Framework has been set up can really facilitate the level of data protection guaranteed by some national eID schemes in cases where full identification of a natural person is not necessary.

In order to derive the potential impact of the GDPR on eIDAS it is necessary to analyse the domain and effects of GDPR Article 25. Such an analysis needs to be coupled with an analysis of GDPR Article 35, which offers a process to contextually derive the requirements of Data Protection by Design.

3 Data Protection by Design

Data Protection by Design, under Article 25 of the GDPR, stems from the literature and practice of Privacy by Design approaches in system engineering. Privacy by Design models have extended and refined the protection goals from the field of computer security (confidentiality, integrity and availability, i.e. the ‘CIA’ model [7, 36]), following the model developed by [52] and [28] and which formed the basis of the German Standard Data Protection Model [15]. Four privacy specific goals have been added to the CIA model, to form seven data protection goals: confidentiality, integrity, availability, transparency, intervenability unlinkability and data minimisation [6, 14, 15, 28, 29, 41, 52].

Article 25 of the GDPR obliges data controllers to “implement appropriate technical and organisational measures” in order to effectively adhere to data protection principles.Footnote 21 Data processors are indirectly captured by GDPR Article 25Footnote 22 and system producers are “encouraged [...] with due regard to the state of the art, to make sure that controllers and processors are able to fulfil their data protection obligations.”Footnote 23 Of note, eIDAS’ requirement to facilitate Privacy by Design could be seen as going further than the GDPR in that it does not expressly target only data controllers. The measures envisioned by Article 25 have to be in place “both at the time of the determination of the means for processing and at the time of processing itself”.Footnote 24 In other words, technological and policy support for the privacy of data subjects has to be implemented from the design phase and throughout the processing operations. A failure to comply with this requirement might trigger an administrative fine of up to €10.000.000 or in the case of an undertaking, up to 2% of the total worldwide annual turnover of the preceding financial year, whichever is higher.Footnote 25 The controller shall justify the selected measures against a list of contextual factors: “the cost of implementation and the nature, scope, context and purposes of processing as well as the risks [...] posed by the processing”.Footnote 26

The seven data protection goals align with the data protection principles of Article 5 GDPR.Footnote 27 An overarching principle, explicitly mentioned in Article 25, is data minimisation. Data minimisation requires the processing (including the collection) of only the data “limited to what is necessary”Footnote 28 to accomplish a certain purpose. In tandem, under the purpose limitation principle, processing purposes must be specified, explicit and legitimate;Footnote 29 in other words purposes should already be defined before data collection. Therefore, not only collection of data must be limited, but collected data must be strictly necessary to a predefined relevant purpose. Confidentiality refers to non-disclosure of certain aspects in an IT system. In a privacy context it can be translated as the need to ensure that information is accessible only by authorised users. Integrity protects the modification, authenticity and correctness of data. It relates, therefore, to safeguards for the accuracy and completeness of the data and their processing methods. Availability concerns the availability, comprehensibility and processability of data. Transparency relates to ‘soft’ privacy – the relevant policies, reporting and auditing mechanisms in place. Intervenability ensures that parties to the data processing can intervene in the processing when necessary. Finally, unlinkability regards the inability of an attacker to know if any two points of a system are related (for example, an eID and its owner).Footnote 30 Of note, this definition as explained below is only partial as it focuses upon external actors only. Yet, we argue that in a data protection context, unlinkability should also take into account internal actors.

The data protection goals systematize the obligations put forth by the GDPR, to assist when performing a Data Protection Impact Assessment [15]. Data Protection Impact Assessments are meant as a tool to effect the engineering of data protection principles in a system and, thus, Data Protection by Design. Examining the Interoperability Framework, therefore, in the light of the data protection goals is a useful way to determine the level of Data Protection by Design afforded by eIDAS.

4 The Goal of Unlinkability for eID Schemes

Looking at the Interoperability Framework through the prism of data protection goals, it is clear that those goals have guided the action of the EU legislature. Although most data protection goals have been taken into account by eIDAS and its Implementing Acts,Footnote 31 facilitation of the level of unlinkability might be further extended, especially in cases where the service provider is a private-sector entity.

Data minimisation in eIDAS is dealt with through the definition of the Minimum Dataset. The premise is that the Minimum Dataset represents the absolute minimum of attributes necessary to “uniquely represe[nt] a natural or legal person”.Footnote 32 Confidentiality is guarding against unauthorised access and disclosure of data. The Implementing Acts define a series of “implement[ed] security controls”,Footnote 33 following a risk-based approach depending on the applicable Level of Assurance, that aim to secure that access and disclosure happens only against authorised actors. The Levels of Assurance (‘Low’ – ‘Substantial’ – ‘High’)Footnote 34 also guarantee that technical controls are in place to effect the integrity of the claimed identity and its data.Footnote 35 Availability, which is an explicit goal of eIDAS Article 7(f), is served through legalFootnote 36 and technical controls.Footnote 37 Transparency is addressed by way of published notices and user information about the service providers and the national schemes.Footnote 38 Even though eIDAS does not strictly require service providers to display their identity to the users, it allows service providers to do so if they wish [18]. Intervenability, which relates to the user rights about rectification, revocation and erasure of their data, is left to the responsibility of the national eID schemes, since eIDAS is only meant to relay eID data.

Unlinkability appears to be one of the most challenging goals to meet in the context of the Interoperability Framework. Unlinkability aims to serve data minimisation and purpose limitation. In general unlinkability is used to express the impossibility of linking an action performed inside a system (for example, sending a message) to a particular process or agent of the system (in this example, the sender), or the possibility to infer from an outside standpoint that two different sessions in the system (for example two different messages) are performed by the same agent (have, for example, the same originator).Footnote 39 However, in a data protection context, unlinkability refers to the risk of linking personal information to its data subject. Therefore, the goal of unlinkability is to eliminate risks of data misuse by minimising risks of profiling [52]. Unlinkability is a key requirement for eID schemes. Indicated in the literature, and confirmed in the expert interviews,Footnote 40  a primary goal of privacy-enhancing eID schemes is to prevent different pieces of information to be linked together [28, 29, 49].

The GDPR elevates unlinkability into a performance standard through the data minimisation and purpose limitation principles. Privacy discourse has identified mechanisms for unlinkability, such as data avoidance, separation of contexts through federated distribution, encryption, access control, anonymisation, data destruction etc. [20]. However, the GDPR refrains from providing design standards to realise purpose limitation and data minimisation. Article 25 and its relevant Recital 78 only provide pseudonymisation as an example. In this paper we limit the focus to two specific measures, pseudonymisation and selective disclosure, since both have been identified in electronic identification literature as of particular importance for unlinkability [16, 39, 41, 52]. Pseudonymisation is explicitly mentioned in the GDPR.Footnote 41 Based on the definition of pseudonymisation,Footnote 42 it must be assumed that a pseudonymised eID dataset can only exist coupled with selective disclosure, i.e. when no other identifying attributes are present in the dataset.Footnote 43

Data minimisation could be seen as having three dimensions: minimisation of content, where the amount of information collected should be the minimum necessary;Footnote 44 temporal minimisation, where information should be stored only for the minimum amount of time necessary for the specific processing;Footnote 45 and minimisation of scope, where data should be used only for the purposes collected.Footnote 46 Selective disclosure addresses data minimisation in the strict sense of Article 5(1)(c) – content minimisation. As a means to effect content minimisation, selective disclosure refers to the ability to granularly release information for a specific purpose. Selective-disclosure-capable systems have the ability to accept and transmit only a subset of the available attributes, depending on the processing at hand [38]. An advanced example of selective disclosure can be seen in Fig. 1, where the system only transmits an inferred claim calculated from the user’s age instead of transmitting the user’s date of birth.

Fig. 1.
figure 1

Simplified verifiable claim using selective disclosure

Full size image

Pseudonymisation as a means of unlinkability refers to the substitution of direct identifiers with constructed attributes so that the link with the original identifying dataset weakens. There are several degrees of pseudonymisation, with the main impacting factors being the frequency of use of a certain pseudonym and the amount of remaining identifying information in the set. In cases where pseudonyms change across uses (‘unidirectional pseudonyms’), linkability between datasets is greatly reduced. On the contrary, where the same pseydonym is deployed regardless of use (an ‘omnidirectional’ pseudonym) there is a risk of linkability as the pseudonym can act in the form of a de facto unique identifier. In eID architectures unidirectional pseudonyms have so far been deployed in two ways: in ‘pairwise persistent’ configurations, different pseudonyms are constructed for every pair of pseudonym–user, but remain the same for the specific pair. This way no two service providers receive the same pseudonym, and therefore, service providers cannot easily infer that the pseudonyms refer to the same user. However, since the pseudonym is persistent for that specific user–service pair, it is technically possible for the service to monitor how the pseudonym is used in its system (even if the real identity of the user is not yet known).Footnote 47 In contrast, in deployments where the pseudonyms change in between uses even of the same service (‘transient pseudonyms’) a service provider is not able to distinguish that two uses concern the same user [50]. Although this resolves the issue of linkability it makes it difficult for services to recognise recurring users. For this reason pairwise persistent pseudonyms are preferred in practiceFootnote 48.

An illustrative example of how unlinkability has been addressed can be given through the case of the German “neuer Personalauswess” (nPA). The nPA is a federated eID scheme, based around a national eID card that is provided to every citizen. The scheme was built around Privacy by Design principles, supporting advanced privacy controls for the users.Footnote 49 The implementation does not depend on an Identity Provider,Footnote 50 identification of the user happens through the eID card and a user-controlled middleware software [42].

The nPA incorporates data minimisation through selective disclosure and pseudonymisation. The card has a pre-defined set of attributes stored inside a local RFID chip (refer to Table 1). When performing an electronic identification, the service provider requests the attributes necessary for the identification. The user can then select which of the requested identifiers they wish to disclose to the service provider (selective disclosure). Additionally the nPA employs pairwise-persistent pseudonyms in lieu of an identifier, which are different for every pair of user–service [23, 24]. Notably, if a service decided to sub-let their eID infrastructure to other services, all services under the same infrastructure would receive the same pseudonym, therefore increasing the potential to infer the associated identity of the user by combining data. To eliminate this risk, Germany has put policies in place (soft privacy) that forbid linking of data.Footnote 51 The nPA also supports advanced calculations, providing a Yes/No answer about a user’s age or location eligibility – without disclosing therefore the user’s date of birth or address [24].

Table 1. Minimum data set provided by the German eID scheme [26]
Full size table

On 22 August 2017 Germany pre-notified the nPA under the process of eIDAS Article 9 [25], with the notification published on 26 September 2017.Footnote 52 Since the nPA is the first notified scheme, it is an excellent example to highlight potential issues with unlinkability within the eIDAS framework. Of note, the nPA is not the only national scheme to feature unlinkability for privacy protection: the Austrian and the UK’s schemes also feature a form of pairwise persistent pseudonymisation, whereas Austria plans to also introduce a form of selective disclosure.Footnote 53 The Belgian scheme is also exploring pseudonymisation solutions.Footnote 54 Effectively, one third of the schemes currently undergoing a notification procedure for eIDAS is deploying some level of unlinkability.Footnote 55 However, this paper will largely refer to the German scheme since it has already undergone the notification process.

5 Unlinkability in the Interoperability Framework

The aspiration of eIDAS to set up a “technology-neutral” Interoperability Framework should indicate that advanced privacy designs are supported. This is supported by the explicit mention that the Interoperability Framework will facilitate Privacy-by-DesignFootnote 56 and eIDAS will not prejudice against the use of pseudonyms.Footnote 57 At the very least, it should denote that where national systems support such features, they can be integrated in the Interoperability Framework. However, it appears that the necessity of a common denominator, which is considered essential for transactions with public-sector services, hampers the extend to which Privacy by Design can be used. The main obstacle is the Minimum Dataset and its mandatory attributesFootnote 58.

The Minimum Dataset was devised in order to ensure that public-sector service providers, who are obliged to accept other EU Member State’s notified eIDs, will have enough information to uniquely identify a foreign citizen. The Minimum Dataset, in other words, is based on the assumption that public-sector services are dependent on successful unique identification of a person in order to provide a service. This is true for a lot of public-sector services eIDAS targets: filing taxes, proving residence status, using student services, opening bank accounts.Footnote 59 In addition, some e-government services depend upon a degree of linkability, that the Minimum Dataset provides, in order to satisfy the ‘once-only principle’.Footnote 60 However, not all services benefit from a degree of linkability: this is certainly true for providers of the private-sector who rarely require identification in order to provide a service, such as for example online social platforms, but also for a number of public-sector providers who either operate services where identification is not necessary (i.e. where age verification suffices) or operate sensitive services, like national health services (i.e. drug rehabilitation services). In such cases, linkability could damage the reliability of the provided service, increasing the risk of profiling or data misuse.

Looking back at Germany’s notification, the adaptation of the nPA’s characteristics in order to conform to eIDAS’ requirements already excludes its full pseudonymisation and selective disclosure capabilities. Germany will be deploying the nPA as middleware instances – an instance located at and operated by each receiving Member State. They have also provided a mapping against the attributes required by eIDAS (Table 1). The optional attribute of the gender is not present in the nPA dataset; the optional attribute of name at birth can be provided but only where the attribute has been included in the eID card. All mandatory attributes, nonetheless, are supported. Since eIDAS mandates that the mandatory part of the Minimum Dataset shall in any case be transmitted, and, depending on the receiving service, might be enriched by optional attributes, a user of the nPA will not be able to (de)select attributes for transmission without resulting in an unsuccessful authentication.

In addition, in absence of unique identifiers in GermanyFootnote 61 the nPA will substitute the mandatory ‘Uniqueness identifier’ with a pseudonym. As explained above, the card is capable of producing a persistent unique pseudonym for each pair of user–service, which provides a basic protection against linkability of data between services. However, in cross-border authentications, all of the public-sector services of the receiving Member State will be considered as one service. The receiving Member State will be assigned a pseudonym unique for the pair user–Member State, which will function as the Minimum Dataset’s ‘uniqueness identifier’ [26].Footnote 62 As a result, all public-sector services of the receiving Member State will be receiving the same unique identifier (along with at least the remaining mandatory attributes) thereby raising the question of how linkability of data and uses within a receiving Member State can be prevented. Note that, as abovementioned,Footnote 63 under the GDPR in order for a dataset to be considered pseudonymised all other attributes aside from the pseudonyms have to be such that identification of the data subject is not possible. That would be the case, for example, when the only attributes in a dataset are a pseudonym and a date of birth. Seeing as, even when a pseudonym is used in place of a unique identifier, it will always be accompanied by identifying information (the rest of the mandatory Minimum Dataset attributes) it is unlikely that an eIDAS dataset will ever meet the definition of GDPR’s pseudonymisation.Footnote 64 In this sense, there can be no pseudonymisation in eIDAS without selective disclosure. Thus, use of pseudonyms in eIDAS might not be ‘prohibited’ per se, but it certainly is restricted.

With selective disclosure and pseudonymisation restricted, ‘facilitation’ of Privacy by Design is constrained. In the spirit of the GDPR, the measures afforded by a system should be proportionate to the levels of risk involved in the data processing [4]. Cross-border eID provision should be expected to involve high-risks of processing before any mitigating controls are put in place, in light of the guidance on Data Protection Impact Assessments [5].Footnote 65 It can be argued therefore that, by limiting the amount of unlinkability afforded by national systems, service providers that do not require all the attributes of the Minimum Dataset will face problems justifying its processing. Obviously this assertion is contextual. The capabilities of the national scheme providing the electronic identification have a clear impact, as not all systems support selective disclosure and pseudonymisation. However, at least when supported by the national system, the eIDAS Interoperability Framework should be able to support a higher level of unlinkability.

Acting otherwise can prove highly problematic for national schemes that support a high level of unlinkability, as these national schemes will not be able to guarantee such a level for cross-border transactions. In light of eIDAS Article 8, the description of the Levels of Assurance and their governing data protection goals, i.e. integrity, the Member States that offer a high degree of unlinkability would not be in a position to negotiate attributes with service providers that do not require the full Minimum Dataset. As a result, there is an argument that eIDAS Article 12(c) would not be met in the sense that the Interoperability Framework would undermine rather than facilitate Privacy by Design. Going further, national data controllers enabling and operating eID and authentication cross-border would be prevented from offering to their users a high level of data protection in cases where the services requesting eID do not need the complete Minimum Dataset. This could have implications in terms of liability as eIDAS Article 11 should be read in combination with GDPR Articles 82 and 83.

6 Reinforcing the Level of Data Protection by Design in eIDAS

Better incorporation of selective disclosure and pseudonymisation into the Interoperability Framework could reinforce Data Protection by Design in the eIDAS Interoperability Framework. It is true that modifying the Framework to accept different capabilities depending on the features of every national system might be impossible, as it would require an upfront insight into the design of all EU systems – whose participation in the Framework is after all voluntary and, hence, not guaranteed. A potential practical way out however would be through an extension of the supported SAML exchanges.Footnote 66 Currently the SAML profile specifies that “at least all attributes defined as mandatory within this minimum data set MUST be requested. At least one minimum data set MUST be requested in each <saml2p:AuthnRequest>” [19].Footnote 67 The SAML exchanges could be enriched to be able to distinguish and accept requests for a smaller amount of attributes than the ones present in the Minimum Dataset, depending on the requirements of the service provider. The extension would be similar to the proposed scenario in [32]. In this scenario, the service provider would have to specify the required attributes in its request for authentication (see Listing 1 in [32]). The Minimum Dataset would still be sent to the eIDAS node, so as to satisfy the design of systems that do not natively support selective disclosure or pseudonymisation. However, the eIDAS node would then be able to extract only the attributes specified in the request, repackage them into a set under a different pseudonym in place of a unique identifier and transmit them back to the service provider. A similar architecture has been proposed in [43], when the FutureID broker acts in a ‘claims transformer mode’. However, the eIDAS node would not perform the authentication itself (at least when functioning in a proxy mode) but it would simply transform the SAML assertion received by the national eID scheme. Such a functionality is supported, for example, by the eID component (based on [34]) in the FutureTrust project currently under way [33].

If the notified scheme is deployed in a proxy mode [17], and therefore operated by the sending Member State, a solution like that would ensure that no excessive personal data leave the territory of the notified scheme. In cases where the national system is deployed in and operated by the receiving Member State in a middleware configuration, the transmitting Member State has significantly less control over the amount of attributes used. In a middleware configuration it seems likely that the Minimum Dataset will always have to be transmitted to the receiving Member State. However, instead of forwarding the whole Minimum Dataset to the service provider, the eIDAS node could then be able to selectively transmit attributes. The ability to select which attributes to disclose and package them under different pseudonyms would strengthen the level of privacy by reducing the amount of information service providers receive and, effectively, the risk of data collusion. Additionally, selective disclosure at the receiving Member State level would guarantee that in a case of dispute, i.e. in cases of fraud or a law enforcement investigation, the receiving Member State would be able to backtrack the pseudonymisation to identify the affected citizens. This extension of eIDAS constitutes an easy, low cost solution since it requires neither the alteration of eIDAS nor the modification of the architecture. Instead, it can be effected through the issuance of a Regulatory Technical Standard that will provided the added SAML elements to the current eIDAS SAML profile.

7 Conclusion

The risk-based approach of the GDPR in principle allows data controllers to tailor the protection of personal data in their systems as determined by the nature of data processing. The GDPR supports this relative freedom by refraining from specifying an explicit list of appropriate compliance measures. However in practice this might lead to protection that is sub-par to what technology can currently support. Such a case can be observed in relation to eIDAS and its requirement for a Minimum Dataset of mandatory attributes.

Modern electronic identity technology recognises that the amount of information needed for successful authentication varies depending on the service. It also accepts that for better protection of personal data, linkability of datasets should be prevented as far as possible. This paper argues that, on par with the GDPR’s risk-based approach, data minimisation should vary subject to the needs of the accessed service and the implemented technical and organisational measures in the Interoperability Framework should provide the same level of data protection guaranteed by the Member States.

The adequate level of data protection should be judged based upon the data-protection goals, which systematise the obligations put forth by the GDPR. eIDAS has been diligent in satisfying most of these protection goals, through its provisions and related Implementing Acts and technical specifications. However, in an effort to define a common denominator for interoperability, the existence of the Minimum Dataset and its unique identifier put constrains into the degree of unlinkability that can be afforded by eIDAS’ Interoperability Framework.

This is problematic for participating national schemes that provide a high degree of unlinkability through advanced selective disclosure and pseudonymisation. These schemes will be forced, when participating in eIDAS, to lower the level of protection they provide to their citizens.

This paper proposes that the way the eIDAS nodes operate should be altered so that selective disclosure and pseudonymisation can be possible for the national schemes that support them. Selective disclosure and pseudonymisation, and consequently a greater level of data minimisation, will significantly improve the amount of data that data controllers in electronic identification, residing either in the sending Member State or the receiving Member State, are processing. Thus, such a solution would reduce the associated risks, offering easier ways to demonstrate compliance with the GDPR. We demonstrate how such a solution could be achieved through alterations to the eIDAS SAML profile by way of a Regulatory Technical Standard so that its implementation causes the minimum disruption possible.