Privacy Directive – Principles and applicability Basic principles of the Directive

The main objective of the Privacy Directive is stated as being the protection of “the fundamental rights and freedoms of natural persons, and in particular their right to privacy with respect to the processing of personal data” (article 1.1). It is therefore not surprising that electronic identity management – which by definition revolves around the management of personally identifiable data – is greatly affected by the principles of the Directive.

These basic principles are summarised in article 6 of the Directive, and include the requirements that personal data must be:

(a) processed fairly and lawfully;

(b) collected for specified, explicit and legitimate purposes and not further processed in a way incompatible with those purposes. Further processing of data for historical, statistical or scientific purposes shall not be considered as incompatible provided that Member States provide appropriate safeguards;

(c) adequate, relevant and not excessive in relation to the purposes for which they are collected and/or further processed;

(d) accurate and, where necessary, kept up to date; every reasonable step must be taken to ensure that data which are inaccurate or incomplete, having regard to the purposes for which they were collected or for which they are further processed, are erased or rectified;

(e) kept in a form which permits identification of data subjects for no longer than is necessary for the purposes for which the data were collected or for which they are further processed. Member States shall lay down appropriate safeguards for personal data stored for longer periods for historical, statistical or scientific use.

For the purposes of identity management in an eGovernment context, a key consideration is the relative freedom of Member States to determine when the processing of personal data is authorised and proportional, what kind of guarantees with regard to privacy protection should be given, and who should be allowed to access the personal data (and under which conditions). Since these are essentially policy choices, established and cemented through formal legal sources (such as National Register Acts, Identity Card Acts, eGovernment Acts, and so forth), compliance with these principles is typically a non-issue.

From a cross-border interoperability perspective, articles 6(b)-(d) are of particular interest, as they determine on a high level the preconditions for lawful cross border authentication using public sector resources.

• Article 6(b) establishes the basic principle that personal data should be collected for specified, explicit and legitimate purposes which must thereafter be respected. This is relevant from an eGovernment context, as it precludes governments from using registers or other identity resources established for the purposes of national administration for any other purposes without a further explicit and lawful legal basis. As a general principle, its interpretation is subject to evolution and to local perceptions; however, it is clear that the use of identity resources in a cross border context should as a general rule only be possible with the data subject’s consent, i.e. it should be user centric. Any other solution risks violating this first basic principle.

• Article 6(c) formulates a proportionality test by stating that personal data should be adequate, relevant and non-excessive. For the purposes of authentication, this will mean that the data subject should not be required to yield more personal data than is strictly necessary for the

purposes of the application. For most applications, this will mean presenting a data set that allows the data subject to be uniquely identified (i.e. an identifier as defined above; see section 5.2.1.4. for a more detailed discussion on the implications of this principle). However, for some applications, the authentication requirements are sufficiently met by establishing a quality of the data subject (e.g. person X is an adult; person Y has citizenship Z), even if this does not allow a specific individual to be identified at every instance. Authentication should be dictated by informational needs, not by informational possibilities.

• Article 6(d) requires data controllers to watch over the accuracy over the personal data that they manage. While an important principle in general, it becomes crucial for information being managed by public sector bodies, as this data is usually relied upon to be accurate, both by public sector bodies and by private sector parties. This article requires governments to ensure that information resources under their control are accurate and kept up to date (an obligation which is also a natural part of public sector good governance obligations, and which is thus not limited to information regarding natural persons). From a cross border perspective, this implies that entities abroad must be able to rely on information being provided through an eIDM system, if appropriate through a system of legal guarantees and warranties. An eIDM system which cannot guarantee the accuracy of the authentication information it provides has no real value.

These principles are also closely linked to the authentic source principle discussed above (see section 4.2.), which is finding increasing acceptance in the surveyed countries. As noted above, this principle implies that for each given attribute (piece of identity data), one and only one source is considered to be authentic, i.e. correct. This information should be reused by any parties with a legitimate interest, so as to minimise user inconvenience (by not requiring him/her to provide the same information time and again), and to ensure that there is only one place in which altered information needs to be corrected (thus protecting the accuracy principle of the Directive).

Apart from these basic principles, article 7 of the Directive describes the conditions when personal data may be processed, including when:

“(a) the data subject has unambiguously given his consent; or

(b) processing is necessary for the performance of a contract to which the data subject is party or in order to take steps at the request of the data subject prior to entering into a contract; or (c) processing is necessary for compliance with a legal obligation to which the controller is subject; or

(d) processing is necessary in order to protect the vital interests of the data subject; or

(e) processing is necessary for the performance of a task carried out in the public interest or in the exercise of official authority vested in the controller or in a third party to whom the data are disclosed; or

(f) processing is necessary for the purposes of the legitimate interests pursued by the controller or by the third party or parties to whom the data are disclosed, except where such interests are overridden by the interests for fundamental rights and freedoms of the data subject which require protection under Article 1 (1).”

Keeping into account the aforementioned principle of user-centricity, use of identification data based on consent is obviously preferable. However, it should be noted that for eGovernment purposes a separate legal framework is often created with regard to the management of electronic source of personal data, typically in the form of National Register Acts, Identity Card Acts, eGovernment Acts, and so forth, which serve as an adequate basis for the processing of personal data even without emphatic user consent.

Obviously, this issue is only relevant in the broader context of identity management, but not when examining the narrower issue of authentication as such. After all, authentication by definition will be initiated by the data subject himself/herself, so that the only issue of consent is the determination of the data set required for authentication purposes. This issue will be further discussed below (see section 5.2.1.6.).

Identifiable data – identifiers in the surveyed countries

The notion of authentication has been defined above as ‘the corroboration of the claimed identity of an entity or of a set of its observed attributes’. A distinction should therefore be made between two situations:

• In the first situation, the application authenticates the entity only to verify whether he or she has a specific required quality, such as:

o Being an adult;

o Being a resident of commune X;

o Being a limited liability enterprise.

In these cases, it is not necessary for an application to know who a specific entity is, exactly.

The application determines the entity’s status, not his/her identity.

• In the second situation, the application needs to authenticate the entity by determining his/her exact identity, i.e. the authentication process in this case relates to identification. After the authentication phase, the application needs to have sufficient information to pick a specific entity out of the whole spectrum of possible candidates (e.g. one specific person out of all of mankind, or one specific enterprise out of all possible legal entities).

Thus, authentication can sometimes be done by merely establishing a quality (case 1), or by determining the precise identity of an entity (case 2). In both cases, the final goal would obviously be served by presenting any and all attributes regarding a specific entity. However, this would be inefficient and would certainly violate the provisions of the Privacy Directive with regard to natural persons.

Indeed, proper use of the first system will often³⁵ preclude the applicability of the Privacy Directive (or its national transposition) on the application, since the processed data will not allow a specific data subject to be identified, which is a precondition for applicability.

However, in practice, the surveyed countries only commonly use the second system, requiring an authenticating entity to present and corroborate a set of attributes which is sufficient for the application to be able to determine the exact identity of the authenticating entity. Determining the quality of the entity can be done thereafter by processing the provided attributes (e.g. processing date of birth to determine adulthood) or by linking back to a separate database (e.g. using a national register number to determine if a person has children). By definition, determining an identity uniquely requires the use of a unique identifier.

35 Allowance should be made for the situation where the authentication of a quality implies the unique identification of a specific person. E.g. an eIDM system which only verifies that one is an adult living in a specific street would uniquely identify an individual in the rare case where only one adult resident lives on that specific street. The example serves to illustrate that any authentication system that verifies only certain qualities will eventually become an identification system if a sufficient number qualities are tested. For instance, a regional subsidy system testing whether an entity is a limited liability company registered in commune X after 31 December 2007 may well result in the de facto identification of a single entity.

It is worth repeating that this study considers the notion of a unique identifier to mean ‘an attribute or a set of attributes of an entity which uniquely identifies the entity within a certain context’. This term is commonly misunderstood to be a specific number (such as a national register number, VAT number, certificate numbers, etc.). While such numbers are a common (and in fact the default) form of unique identifier, any sufficiently unique set of attributes pertaining to a specific entity can serve the exact same purpose.

For instance, a specific natural person might be uniquely identified through his/her national register number, which is then clearly a unique identifier. Alternatively, he/she may be identified by requesting last name, first name, date of birth, place of birth, nationality, gender and official address. The combination of this information as a whole can equally be considered as a unique identifier, despite the fact that no specific number is applied. This is illustrated in the German country profile, in which the correspondent noted that:

“State law on civil registers of residence may allow the collection of additional data and procedural provisions. Most states allow the registration authorities to assign reference numbers in the register. These may only be used for special purposes and not as unique personal IDs. This is not possible, anyway, because each registration authority can assign their own ID numbers.

The most important attributes for identifying a natural person in the register of a local authority are family name, first name, date and place of birth. Experts estimate that 95% of natural persons can be found in the citizens registers by these data.”

In practice, identification systems tend to revert to using specific identification numbers as unique identifiers, rather than combinations of information, as it such numbers can offer a greater guarantee of uniqueness. Either way, the processed information constitutes personal data when referring to natural persons.

Approaches in the surveyed countries

The choice of a suitable unique identifier is of course a matter of policy. As noted above (see specifically section 4.1.2.), the resulting choice varies widely. At the highest level, a distinction can be made between two approaches:

• General purpose identifiers: identifiers which are attributed to an entity outside of a specific context, typically at the time of creation or specific registration. Typical examples include national register numbers, personal identity numbers and enterprise numbers. Such numbers can be used (at least in theory) across any number of contexts.

• Context specific identifiers: in contrast, context specific identifiers are assigned for use within a more or less tightly defined context. Typical examples may include social security numbers, tax numbers, or VAT numbers. While such numbers are intended for use within their sector, if they are sufficiently unique there is of course no practical barrier to their application in other contexts, provided that they cover the envisaged target group in its entirety. For example, VAT numbers are commonly used as generic identifiers, even outside the VAT context.

However, the use of any unique identifier presents a possibility of abuse, since any party able to access it can potentially use it to link information on a single entity together as long as that information includes the specific unique identifier, thus linking small fragmented pieces of information together into a larger whole. This can particularly become a risk when a unique identifier becomes overly popular, and becomes a de facto standard identifier in public and private sector applications alike. In such situations, a number of countries consider that the risk of data leaks (where public sector information is accidentally lost) becomes significantly bigger, since private sector parties who obtain such information can more easily link it to other information that may be lawfully available to them.

Realising this risk, many governments have taken active steps (beyond the applicability of their generic data protection regulations) to subject some or all unique identifiers used in their administrations to additional protection mechanisms. These can be divided into the following categories:

• Unprotected: unprotected identifiers are not subject to any additional specific restrictions regarding their use. They are completely open for private sector uptake. This is most common for identifiers used for legal entities or only in a commercial context, such as enterprise numbers or VAT numbers; and for identifiers issued and/or managed by private sector entities, such as CSP certificate numbers and bank identifiers.

• Restricted: restricted identifiers may only be used within a specific context, i.e. a specific subject field. Typical examples might include protected social security numbers or tax numbers which are only used within tax administrations.

• Protected: protected identifiers may only be used after obtaining specific permissions, either directly by law, or through a specific public sector body. Typical examples include national identity numbers of natural persons which cannot be used in private sector applications, or only upon obtaining a suitable permission prescribed by law.

Another category that does not fall cleanly into one of the groups above is that of the obfuscated identifier, the only example currently being the Austrian sourcePIN. As noted above, this number is however never used directly to authenticate the user in eGovernment applications. As identifiers, the Austrian concept relies on sector-specific personal identification numbers (PINs) that are derived from the sourcePINs. Using cryptographic one-way functions the sector-specific identifiers are calculated so that the citizen is uniquely identified in one sector, but identifiers in different sectors cannot be lawfully cross-related. The Czech Republic plans to implement a comparable system, based on the introduction of a "basic personal identifier", which will be used to derive a set of personal identifiers for specific contexts, so that each individual will be identified by a different identifier in each context.

Comparable to the situation in Austria, the database of the basic personal identifiers will be managed by The Office for the Personal Data Protection. This Office will provide the transformation of the personal identifier for one context to a different context, but it will not be able to link any identifier to the personal data.

It is important to be aware of the qualification of a unique identifier when considering cross border use, as an incorrect choice could lead to a system being either unlawful or at least politically unacceptable.

This issue will be examined further below, in the discussion of interoperability barriers.