Privacy in Digital Identity Systems: Models, Assessment, and User Adoption

The use of digital or electronic identity (eID) systems is a growing trend in on-line environments, both in public and private sectors. In the public sector, the eID ecosystem is believed to be a driver for stronger e-Government adoption by citizens, while the private sector (banks, travel companies, etc.) may also be interested in secured solutions strongly linked to the civil identity. In the European Union, a long term strategy has been in place for the last few years, and has resulted in a recent adoption (in 2014) of the Regulation on Electronic identification and trust services (eIDAS) [1]. This text establishes the main principles that will guide implementation and use of digital identities in the Member States in the near future. While the scope of the Regulation concerns public e-services only, the goal is clearly to set a global policy framework to boost the adoption of eID in both public and private sectors.^{Footnote 1}

Basically, an electronic identity management system (eIDMS) allows user identification and authentication to on-line services through the use of various authentication means (from login/password to smartcards). Once authenticated, the user is linked to a set of attributes (civil identity, date of birth, address, etc.) and is able to use the service. Today’s eIDMSs use various approaches defining technical and organizational architectures to establish trust relationships between the following entities: users, the Identity Provider (IDP) which is a trusted third party in charge of managing the eID of users, and Service Providers (SPs) which deliver a service to the user [2]. As the cornerstone of that architecture, the IDP has an influential role in privacy handling: it belongs to a continuum where at one extremum the IDP only manages issuance and revocation (e.g. when the eID is declared stolen) and, at the other extremum, it knows all about the users’ transactions as it is asked each time to assert user attributes.

In these architectures, different stakeholders (SPs, IDP) manage users’ attributes, which are personal data in the sense of the Data Protection Directive 95/46/EC [3]. Consequently, the use of eIDMS raises several privacy concerns. It must be emphasized here that the EU legislation deals with the notion of personal data, which is clearly distinguished from the notion of privacy [4]. However, for the sake of simplicity, this paper uses both notions without distinction.

The main privacy concerns are disproportionate data disclosure and user linkability across service providers, which may lead to the knowledge of a user’s behaviour by third parties, and thus to unwanted behaviour profiling [5]. If the user has to prove to be over 18 years old to access a service, there should be no disproportionate data disclosure of an exact age and/or civil identity for that purpose. If the user accesses an e-health service and a bank service, in principle there should be no possible linking of the two actions, neither by both SPs nor by IDP.

A possible way to cope with such privacy threats is to implement two measures. The first one is pseudonymous authentication which basically refers to the use of one or many pseudonyms, not unequivocally associated to the civil identity, for identification and authentication to on-line services. Only the issuing authority (IDP) has the knowledge of this association and may reveal it for legal reasons (e.g. fraud). The second one is user-controlled selective attributes disclosure, which is usually implemented as a checkbox allowing the user to select which attributes are disclosed to a particular SP. Both the effectiveness and the user’s perception of privacy protection may be quite different depending on design choices about how the pseudonymous authentication and the data flows between the different stakeholders are designed.

These privacy protection principles are recalled in the aforementioned eIDAS Regulation under Art. 5 which states that (1) processing of personal data shall be carried out in accordance with Directive 95/46/EC (that is respecting among other principles that the data disclosed are “adequate, relevant and not excessive in relation to the purposes for which the data are collected and/or further processed”) and that (2) “the use of pseudonyms in electronic transactions shall not be prohibited”. The Regulation however does not specify how these principles should be implemented, nor does it take into account the eIDMS already deployed in several Member States. However, according to the design choices made by Member States, these eIDMS lead to different privacy protection levels.

The goal of this paper is to provide a comprehensive analysis of eIDMS architectures with regard to the data protection criteria, and to generalize into an analysis grid for privacy evaluation of any existing or future eIDMS. The paper is organized as follows. Section 2 highlights the methodology of the comparative analysis and introduces the analysis grid. Section 3 motivates the selection of four European States and provides a brief description of their eIDMS. Section 4 introduces the models of the relationship between the user, the eID implementation and user’s digital identities, develops the analysis grid and applies it to four countries to describe the efficiency of privacy protection. Finally, Sect. 5 addresses two open questions. First, as the privacy concerns seem to grow among the population, it could be expected that more privacy preserving eIDMS would get larger user adoption. However, we underline that, as of today, there is no strong evidence of such a correlation. Second, we identify some of the key factors (namely the number of services available for the user and the perceived privacy) that may influence the user adoption of eIDMS.

To conduct the comparative analysis, we adopt a particular methodology, articulated around three points.

First, the paper aims to propose a relevant level of description of privacy protection measures, mainly related to pseudonymity. The literature often provides either a too high-level description in terms of models of trust [6, 7], or a too detailed technical description in terms of data flows. While both are necessary in their own contexts, we are looking for an approach which is able to catch at the same time the functional relations between parties, and the relevant aspects of actual, existing systems, while not being lost with low-level details. We believe that such a “big picture” can benefit the discussion in the context where people from different viewpoints (engineers, policy makers, service providers, lawyers, civil society) are brought together to discuss these important issues.

Second, our analysis considers only already deployed architectures, and not well-known theoretical models (such as central, federated or user-centric), nor EU research and development projects. Indeed, existing systems are known to exhibit notable differences from theoretical models. For example, the Austrian eID architecture is a complex mixture of central, federated and user-centric models [8]. Similarly, the German eID does not fit any of existing theoretical models or “pure” architectures such as SAML, OAuth, etc., or their privacy characteristics as described in [9]. We wish our analysis to be very practical and realistic.

Third, we identify three inter-related design axes (illustrated Fig. 1) that help evaluate the privacy protection level in a real system. Axis 1 concerns the relationship between eID carriers, eID deployers (the concept we introduce on this occasion, see Sect. 4 for details) and multiple pseudonyms; we also mention public policy on multiple pseudonyms and user initiatives related to the presence of pseudonymous authentication. Axis 2 deals with the management of user attributes. Axis 3 concerns the way the authentication scheme and the functional relations between parties are implemented. The 3 axes are inter-related from the privacy protection point of view, and the inter-axis analysis is provided in Subsect. 4.4, leading to a full analysis grid applicable to any country.

Analysis grid. Bullet items are sub-axes, dash items are design options (if relevant).

Full size image

For the purposes of our analysis, we identified four countries. While small, this sample is quite representative of the diversity of solutions: from a basic non-pseudonymized solution to complex privacy protection oriented ones. All the systems offer electronic authentication and electronic signature (this feature is not directly addressed here). The available service providers cover a large range of public (e-Government, social security) and private (banking, insurance, travel) services.

Estonian eID.

Launched as early as 2002 and often described as a success story, the Estonian eID can be supported by various carriers (smartcard, mobile) and allows the user to be authenticated by on-line services. The main compulsory eID card serves also as National ID document in off-line identification. The user is identified by a unique Personal Identification Code, considered as non-confidential in Estonia and based on the Population Register. The main privacy protection mechanism is related to the management of a user’s attributes [10, 11].

Austrian Citizen Card (CC).

Massively rolled-out by 2006, the Austrian eID is a flexible approach based on a particular technology called the Citizen Card concept (CC). The eID can be supported by various carriers such as mobile phones or chip cards (e.g. Social Security e-card). The CC and its carriers are not National ID documents, but are the official eID. As in Estonia, there is a central database called the Central Residents Register. However, the Austrian legislation prohibits the use of these identifiers by service providers. The main privacy protecting mechanism is the use of sector-specific pseudonymous authentication [12, 13].

German eID.

Launched in 2010, the German credit-card format carrier fulfils two functions: eID, machine-readable travel document and National Identity card (or “nPA” which stands for “neue Personalausweis”, i.e. new passport). Here, national legislation does not allow a central database of identifiers. The main privacy preserving mechanisms are: pseudonymous authentication, user controlled disclosure of attributes, no knowledge of users’ activities by IDP, and mutual authentication between the user and the SP (the SP’s validity is systematically verified) [14–16].

SuisseID.

Launched in 2010 as a mostly private-sector initiative, SuisseID is used only for on-line authentication, and is not an ID document. Different form-factors (smartcards, usb-sticks and mobiles) are available. The privacy protection mechanisms are optional pseudonymous authentication and selective disclosure [17, 18].

In this section, several design choices for privacy protection in the four countries selected are described following the analysis grid illustrated in Fig. 1. In the following, we use the terms identifier (when unequivocally linked to civil identity) and pseudonym (when not) to refer to the way a Service Provider (SP) identifies the user. The same user may be represented by different pseudonyms for different SPs.

4.1 The eID Deployer Concept

To model virtually any case of the relationship between the user, the eID implementation and the user’s digital identities (pseudonymized or not), here we introduce the concept of the eID deployer. The digital identities are deployed by the eID deployer which is an abstract functionality to establish the link between the physical form-factor of an authentication mean (called carrier) and the identifier or pseudonym. Several carriers may instantiate the same eID deployer if they fulfil the same function and disclose the same identifier/pseudonym and/or attributes. For example, two carriers belonging to the same user (e.g. a smartcard and a smartphone) may deploy the same pseudonym or a set of pseudonyms representing this user. Alternatively, the user can possess several carriers, each of which deploys its own eID, i.e. its own identifier or pseudonym. That is, multiple pseudonyms can be achieved in two manners: either by generating one pseudonym by the eID deployer and providing the user with many eID deployers, or by generating multiple pseudonyms from one eID deployer. From the user’s point of view, this mechanism allows partial [19, 20] digital identities to be managed in the sense that a user’s actions in one usage context are not known in the other one (the user is cross-domain unlinkable).

In the rest of this section, we analyze the level of privacy protection according to 3 design axis: pseudonymous authentication, attributes’ location and authentication schemes.

4.2 Pseudonymous Authentication

Three Models of eID deployer.

This sub-section describes the three models relative to the eID deployer implementation.

No Pseudonym: One Identifier from Multiple Carriers.

There can be no pseudonymity, in which case the user is always identified with a unique identifier unequivocally linked to the civil identity (typically, the unique citizen identification number from the population register). It must be noted that in this case, because of the static nature of the link between unique identifier and civil identity, the latter can be regarded as a part of the former, and not as a distinct attribute. The eID deployer’s function is simply to disclose the same identifier to different SPs. This is the case in Estonian eID where civil identity (i.e. name and date of birth) and unique identifier are stored directly in the electronic certificate and disclosed at each authentication session. In Estonia, the eID deployer is implemented on several carriers: mandatory National ID with eID based on a smartcard, optional DigiID based on a smartcard and which allows the same actions as the main eID without being a National ID document, and optional smartphone based Mobile-ID. In digital environments, all theses carriers act in the same manner and fulfil the same function to uniquely represent the user.

One Pseudonym from Multiple Carriers.

The simplest way to implement pseudonymity is to envisage an eID deployer which discloses one pseudonym instead of civil identity. In this case, the civil identity is known only by the eID issuing authority (IDP). The SP knows the user only as the pseudonym, and if the civil identity is disclosed to the SP, it is an attribute of the pseudonym. Again, there can be multiple carriers on which the same eID deployer is implemented, disclosing the same pseudonym. This approach is implemented in SuisseID, where the user can purchase a smartcard-based or usb-stick based carrier, and can opt for a complementary mobile phone-based carrier, all deploying the same eID. With this solution, if the user wishes to use multiple pseudonyms, he has to purchase as many carriers with corresponding eID deployers as the number of pseudonyms he wishes. Typically, one may want to have a non-pseudonymized eID and one or several pseudonymized eID for different usage contexts (see below the sub-section User’s or Service Provider’s control on pseudonymous authentication for details).

Multiple Pseudonyms from One (or Multiple) Carrier(s).

A more sophisticated mechanism is used in Austria and Germany. The eID deployer can generate software defined sector-specific pseudonyms, each of which is used in the corresponding sector. In Austria for example, there are 26 distinct sectors, from social security to banking. It seems that there is no technical difficulty to increase the granularity from sector- to service-specific pseudonyms. The SP identifies the user only as the pseudonym specific to the sector so that no cross-sector linkability is possible. In this approach, there is no “root” pseudonym or identifier. Indeed, German legislation prohibits central registry of citizens and unique identification numbers in general. The Austrian eID system does rely on the Central Registry of Residents (CRR), but there are additional one-way hash mechanisms implemented at two stages: first, to prevent the tracking back from a sector-specific pseudonym to the sourcePIN stored in a separate container on the eID carrier, and second, to prevent tracking further back from the sourcePIN to the CRR. Here also, all the carriers (social security smartcard, bank smartcard, mobile phone, etc.) represent the same eID deployer, because all carriers fulfill the same functional role to generate sector-specific pseudonyms in the same manner. In Austria, it is not possible to hold more than one eID deployer: whatever the carrier is, the same user will be represented by the same pseudonym in the same sector. In Germany, only one carrier and thus one eID deployer is allowed for the moment which is a smartcard combining eID, national ID and a machine readable travel document. There are however plans to implement mobile carriers as well, as in Austria. The three models are depicted Fig. 2.

Three models of eID deployer, implemented in Estonian eID; SuisseID; Austrian Citizen Card and German eID respectively (from left to right).

Full size image

Public Policies on Multiple Pseudonyms.

Different states present different public policies with regard to the use of multiple pseudonyms and to the enrolment procedure. It is interesting to note that the strength of enrolment is not directly related to the presence of pseudonymity. Estonia and Germany exhibit rather strict procedures involving the Ministry of Interior, while they do have opposite policies as to the use of pseudonyms. Austria and especially Switzerland have lighter procedures, with possibly remote activation, via Internet or post.

This can be explained by the fact that policy strategies are based not on the presence of pseudonyms per se, but on the articulation between the national ID document and the eID deployer. Indeed, in countries with the strictest enrolment procedures where at least one of the carriers fulfils the traditional physical identity card purpose, only one eID deployer is allowed. In countries with the lightest enrolment procedure where there is no direct link with the traditional ID purpose (SuisseID), there are no restrictions on the number of eID deployers. Austria falls in between: while not being a National ID, the eID is official for on-line transactions; thus, multiple eID deployers are not allowed.

User’s or Service Provider’s Control over Pseudonymous Authentication.

When pseudonymity is implemented, the user may be granted or not the initiative of its use. The pseudonymity can be called automatic when all authentications make use of a pseudonym, as in Germany and Austria, and user-defined when the user has the initiative to use the pseudonym or not, as with SuisseID. In the particular case of SuisseID however, for unknown reasons, it is not possible to have both a pseudonym and a real name name in the same eID deployer so that the user’s choice at issuance is definitive.

It has to be noted however that whatever the design choice, a specific SP such as the tax office may require civil identity to be disclosed. In automatic pseudonymisation this situation may be handled by the eID deployer and does not prevent the use of the service. In user-defined pseudonymisation, at least in the particular case of SuisseID, this may prevent the use of a service if the pseudonymisation was chosen at issuance. In other words, the SP may have the last word on the use of pseudonyms, possibly by preventing the use of the service.

4.3 Location of User’s Attributes

While pseudonymous authentication is certainly the main factor in preserving a user’s privacy, the way the eIDMS manages users’ attributes that are personal data from the legal point of view, has a significant influence as well. The scope of this sub-section is limited to the attributes at issuance (those stored on the carrier and those known by the IDP) and does not include dynamic attributes collected by a particular SP during online transactions which may be used for profiling. We distinguish three situations.

Localized Attributes.

This first option depicts the case where the attributes such as personal address (i.e. data other than those strictly necessary for authentication) are stored locally on the carrier, and are not continuously stored by the IDP or SP, thus reducing the degree to which personal data can be accessed by third parties. This scheme is implemented in the German eID where the carrier bears attributes such as family and given names; artistic name and doctoral degree; date and place of birth; address and community ID; expiration date and optional fingerprints.

Distributed Attributes.

The opposite option is to store only minimum attributes on the carrier itself (e.g. name, date of birth and nationality). In this case, the different SPs manage the attributes relative to their services, such as the personal address, for example. This option has certain advantages: the IDP does not have any additional information about a user’s attributes, and a given SP normally cannot access attributes stored by other SPs. This option is implemented in the Estonian eID. Here however, these advantages are enforced by legal requirements only, as the use of a unique personal identifier across public and private SPs makes the cross-service correlation of attributes technically possible. In the Austrian Citizen Card, few attributes are present in the eID deployer (name and date of birth).

Centralized Attributes.

In this intermediate option, the eID deployer itself contains fewer personal data than the set managed by the issuing IDP. The role of the IDP is complex as it deals both with the knowledge of attributes themselves, and with their assertion and disclosure to the SP: in some cases, the IDP could disclose all attributes that it stores, while in other cases only a sub-set of attributes. The centralized design option is implemented in the SuisseID, where the only mandatory attributes on the carrier are the SuisseID number and the name or the pseudonym. However, despite this minimal mandatory design, the SuisseID carrier can also carry optional attributes, such as affiliation, e-mail, etc., if the user decides so. In addition, the SuisseID introduces “auxiliary identity providers” distinct from the IDP involved in the issuing of the SuisseID. They are similar to what is classically called Attribute Providers: while the main IDP manages only basic personal data, these providers manage extended attributes (e.g. professional data, such as lawyer, representative of a moral person, etc.). There can be an arbitrary number of Attribute Providers, allowing further development of the usages. The design decisions implemented in the SuisseID confer a central role to the IDP and to Attribute Providers and require a great amount of trust in them.^{Footnote 2}

4.4 Authentication Schemes

The authentication scheme determines the roles of IDP and SPs, and the flow of attributes between them during the authentication. Also, in relation to the scheme, an eventual user controlled selective attributes disclosure can be implemented, which is typically done via a dashboard or a checkbox. In the following, we describe 4 schemes of high-level functional relations (and not the low-level data flow) between the parties.

Offline Scheme (A).

In this scheme, illustrated in Fig. 3, the IDP is normally not aware of the flow of user attributes which are managed directly by SPs. After the enrolment, IDP manages only revocation lists and verification of a card’s status by SPs. Along with distributed attributes management described above, this scheme is intended to prevent the establishment of a central data holder. However, when implemented together with a unique identifier, it does not prevent cross-SP linkability.

Off-line (A)

Full size image

In the particular case of Estonia, where this scheme is implemented, the user has no a priori control on attribute management. This lack is partially compensated by a posteriori user access, as there are legal dispositions allowing the user to monitor which attributes are accessed or stored by each SP. However, it is unclear to what extent this obligation is respected, and several reports^{Footnote 3} [21] and users’ comments [22] seem to doubt about the system’s transparency.

Federation Without User Control (B).

In the scheme illustrated in Fig. 4, implemented in the Austrian Citizen Card, the federal IDP plays a central role. This scheme requires that the SP send an authentication request to the IDP in a systematic manner.

Federation without user control (B)

Full size image

As already mentioned, the privacy against SPs is guaranteed by the use of sector specific pseudonyms generated by the IDP. There is no selective disclosure, and it seems that the personal data transmitted to SPs may on some occasions contain more than that strictly needed for the authentication (e.g. the name and the date of birth) [23]. The privacy against the IDP is not ensured as the IDP knows all the services accessed by the user. Overall, this scheme requires a high level of trust in the IDP.

Federation with User Control (C).

The scheme illustrated in Fig. 5 is implemented in the SuisseID. This scheme is guided mainly by the wish to allow more user control. To enable this, all authentication requests are redirected to the user who controls, via a checkbox-style interface, which attributes he agrees to disclose to the SP.

Federation with user control (C)

Full size image

To guarantee the privacy against SPs, both basic and extended attributes follow this selective disclosure procedure. As multiple eID deployers are allowed, when the same user has several (pseudonymized) SuisseIDs, the linking across SPs is more difficult. As for the privacy against the IDP, the IDP still holds a central role and is able to link the identifier and pseudonyms across different SPs that the user access to.

Mediation with User Control (D).

The last scheme illustrated in Fig. 6, implemented in Germany, is guided by extended security and privacy requirements. Mutual authentication between the user and the SP is used to provide access control, so that only authorized, white-listed SPs can access the user attributes. To this end, an additional element called the eID Server is implemented at the SP side to support communications with the eID client. The eID Server regularly receives, from the authorization certificates authority, updated authorization certificates for the SPs and revocation lists for eID cards. The role of the eID Server is quite different from the IDP’s in its classical acceptance, as it is not a centralized federation operator. The SP can develop its own eID Server according to publicly available specification. Alternatively, 4 eID servers are certified by the German Federal Office for Information Security and made available for SPs to establish connection to.

Mediation with user control (D)

Full size image

Once the connection between the eID deployer and the SP is established through the eID Server, the attribute disclosure is controlled by the user via a checkbox.

To avoid that SPs uniquely identifies the user, an additional mechanism is implemented. The same authentication key is placed on a batch of carriers belonging to different users. Thus, the SP knows only that it is communicating to an authentic eID deployer but does not know to which one in the batch.

4.5 Interdependencies Between Design Axes

We can now draw conclusions on the design inter-dependencies between the 3 design axes we are interested in, which are pseudonymity, attributes location and authentication schemes. Three main aspects are addressed here: privacy against IDP (knowledge of user’s actions and attributes), privacy against SPs (cross-SP linkability of the identifier or pseudonym, and cross-SP linkability of attributes) and selective attributes disclosure to SPs.

In both cases of No pseudonym and One pseudonym, there is no a priori necessity to grant a central role to the IDP.

In the No pseudonym design option, most of the time, the IDP is not informed about a user’s transactions and attributes. The IDP is informed only when the SP needs to check the revocation state of a certificate, as can be seen in the authentication scheme (A). Distributed attributes is a possible way to achieve some privacy protection against cross-SP attributes linkability, even if cross-SP identifier linkability is not addressed, as in the Estonian eID. As few attributes are present on the eID deployer, there is little interest in implementing a selective disclosure of attributes, although it could be technically possible.

In the One pseudonym approach, such a global scheme could also be implemented. However, if additional Attribute Providers are envisaged, the IDP and Attribute Providers are playing a more central role, both in terms of the knowledge of centralized attributes and their assertion to SPs. To partially prevent excessive knowledge of attributes by SPs and thus cross-SP attributes linkability, the selective disclosure can be implemented. The simplest and most “natural” way is to handle it at the level of the IDP which asserts user attributes at each transaction, as illustrated by the authentication scheme (C). These measures, implemented in the SuisseID, do not address cross-SP linkability of the pseudonym (unless the user has many eID deployers), or the knowledge of the user’s actions by the IDP.

In Multiple pseudonyms, the main gain is the absence of cross-sector or cross-SP linkability. The simplest way to achieve this is to involve the IDP as the trusted third party in pseudonym generation and confirmation to SPs, as illustrated by authentication scheme (B). The obvious drawback is that the IDP may gain a central role. Intrinsically, the IDP’s knowledge of services visited by the user is difficult to avoid in this authentication scheme. To limit at least the knowledge of users’ attributes by the IDP, a distributed approach to attribute management can be implemented as a complementary measure, as in the Austrian eID.

To mitigate these issues and to preserve privacy against both the IDP and SPs simultaneously, a much more complex global scheme is needed. Along with already discussed selective disclosure, two additional steps can be performed: the batching of authentication keys, so that the SP cannot attribute a unique identifier to or even track the user, and a direct connection between the user and the SP, so that no central IDP knows which service is visited by the user. Altogether, these design decisions implemented in the German eID, give more technical complexity (in terms of interconnections) but allow strong privacy protection.

To conclude, from a strictly technical point of view, the German eID solution offers the best level of privacy protection, at the price of a relatively complex and expensive architecture. SuisseID offers an elegant and flexible solution with reasonable technical complexity and cost, but does not address the IDP knowledge of a user’s activities.

One could suppose that better privacy protecting solutions will get larger adoption by the public. In the present section, we put the levels of privacy protection described above into correspondence with the effective use of the eID systems by target populations, and analyze some of the factors that may influence the adoption rate.

5.1 Privacy Adoption Paradox

To assess the extent of usage, different parameters can be taken into account: the number of services available to eID authentication, the roll-out, and the usage rate (i.e. percentage of population which effectively use the eID services). We believe that only the last parameter is suitable to assess the real adoption rate. Indeed, the roll-out rate and to a lesser extent the number of available services may result from a voluntaristic policy without triggering the real usage by the population.

One methodological problem is that it is difficult to compare different eID solutions at a given point of time because they have different ages. To compensate for this, we will compare the usage rate with respect to the number of years of existence. The fact that the social and technical context pushes users to adopt digital solutions in 2013 faster than in 2002 cannot be taken into account with the publically available data. Another limitation is that data sources use different procedures: for Germany and Austria the evaluation is based on a representative sample, for Estonia on estimation by involved actors, for Switzerland on sales and estimations (see the Table 1 below). Finally, it should be emphasized that extensive, correct and yearly updated data on the subject is extremely difficult to find, probably because of their sensitive political nature.

Table 1 shows the roll-out and usage rates (as of 2013 for Estonia and Switzerland, as of 2014 for Germany and Austria). Figure 7 shows a graphical representation by country and outlines the rate of adoption which is the relative speed with which the innovation is adopted. More complete data sets could determine if indeed all the countries follow the same logistic s-curve [24, 25] which is classically used to study the rate of adoption.

Rate of adoption in 4 countries

Full size image

As the data suggest, we can see what could be called a “privacy adoption paradox”: there is no evidence that a higher level of privacy protection leads to a higher rate of adoption. It can then be hypothesized that the advantages offered by extended privacy protection solutions do not trigger an a priori increase in the rate of adoption, or are counterbalanced by other factors. The fact that the eID functionality follows an opt-out strategy (in Estonia, all the compulsory eID cards are delivered as active) or an opt-in strategy (in the other countries, the holder has to activate the eID functionality) does not seem to have a decisive influence on the adoption rate. These questions are discussed in the next sub-section.

5.2 Factors of Low Adoption Rate

A large number of factors influence the adoption of eID solutions; for example, [32] identifies no fewer than 20 of them. We will limit the discussion to two factors in the context of the most privacy protecting solution identified in the previous sections, the German eID. What may limit the adoption in the case where the eIDMS objectively offers a good level of privacy protection?

Lack of Applications.

One factor could be the lack of useful applications limiting the adoption by users. This issue is usually presented as a classic chicken-and-egg problem [15]. The take-off can only be envisaged if a sufficient number of services are offered to the user. On the side of SPs, the incentives to offer such services are however limited by the lack of users and thus by the lack of return on investment. No magic solution seems to be present in the countries studied here as well as in others.

Let’s analyze the German example in this light. On one hand, the available figures show that, as of 2013, there were 147 (40 % public and 60 % private) services supporting eID authentication [33], which could cover a large range of everyday usages; thus the lack of applications does not seem to be the main limiting factor.

On the other hand, there is indeed a certain general reluctance of private SPs to develop such eID-supporting services, especially when existing solutions (e.g. bank authentications) already fulfil their purpose [33]. Moreover, as of 2012, only 7 % of service providers did offer privacy-preserving functionality or intended to. The remaining 93 % did require full and true civil identity, while many of them did not belong to sectors where civil identity was required (e.g. banks) [34]. This reflects the specific reluctance of private SPs to offer privacy-preserving functionality.

While this specific reluctance should be addressed at the level of SPs, it is not sure that the usage rate is solely limited by this issue, in particular because users’ awareness on pseudonymisation is quite low, as will be shown below. We think that a broader question here is the way the articulation between e-Government and the private sector is thought of. Usually, and this seems to be the rationale behind the eIDAS Regulation, the eID-supporting public services are considered as a trigger for wider user adoption of private SPs. The underlying hypothesis is that the same eID, possibly pseudonymized, will be used across all the sectors and services. The question is however, does the user want to use the same eID in such different contexts? To take a historic parallel in the pre-digital age, does the user want to use the same key to gain access to his home, to his car and to his workplace? The answer is not as obvious as it may seem, and brings us to the user perception which may limit the eID adoption.

Perceived Privacy.

The notion of perceived privacy refers to the way the users foresee the outcome of their actions, and encompasses different factors, such as trust in the technical system and organizations, reluctance to personal data disclosure, etc. A growing body of literature addresses several counter-intuitive aspects such as the “control paradox” (more control over the publication of one’s own personal data increases an individual’s willingness to publish it and decreases privacy concerns) [35] and “reverse privacy paradox” (lower privacy concerns are combined with a greater use of protection strategies) [36]. These empirical results are always different across countries and age-groups [37].

The point here is that the perceived privacy has little to do with objective characteristics of an eIDMS. For example, [34] reports that in Germany there is a clear influence of the official nature (Identity Card) of the eID on the usage rate. Participants in this study have doubts about using an official and highly personal document to play around on the Internet, and see a “possible contradiction between being pseudonymously authenticated while using an ID card with their photo on it.” Moreover, when the pseudonymous authentication mechanisms are explained, they are quickly forgotten or judged not usable enough in the light of the above-mentioned issues.

That is, the usage rate of German eID depends not only on the presence of pseudonymity as an available feature, but also on the user’s perception of the system and reluctance to use the same eID deployer in different contexts. While people make little use of systems with poor privacy protection, the systems with good privacy protection, even when explained to citizens, does not necessarily trigger a significantly higher adoption rate if perceived privacy is low.

In this respect, an approach based on separate eID deployers, with distinct enrolments for each type of use (e.g. for e-Government and for e-Commerce), could be an interesting solution, allowing usage contexts to be dissociated, from the user’s point of view. Such could be the case if multiple eID deployers were allowed as with SuisseID. For example, there may be a way to authorize multiple eID deployers in the German eID infrastructure, if accompanied by appropriate legal provisions for lighter enrolment depending on usage contexts. This last consideration brings us to the state’s global policy guiding the degree to which the civil identity is linked to electronic authentication means. This question should be taken into account in future research.

In this paper, we developed the methodology and the grid of analysis of privacy protection in existing eIDMS, allowing past and future design decisions to be analyzed. We introduced the concept of the eID deployer and provided models for multiple digital identities.

The important structural differences in privacy protection can influence users’ predisposition to adopt better solutions in everyday usages. To verify if this is the case, we compared the rate of adoption in four European countries. Paradoxically, there is no evidence for significant influence of privacy preserving characteristics on the rate of adoption of eIDMS. We discussed then the factors that may counterbalance an eventual advantage of privacy protecting solutions and limit the rate of adoption. Among those factors, perceived privacy seems of particular importance.

This analysis is of particular interest in the recent context where national legislations reinforce personal data protection measures, both at the European (with the forthcoming General Data Protection Regulation [38]) and at the international level.