Title: LEGAL ASPECTS OF GLOBAL VS. SECTOR-SPECIFIC IDENTIFICATION NUMBERS

Legal aspects of global vs. sector-specific identification numbers

Xavier Huysmans, K.U.Leuven, ICRI 

After the historical sketch in the previous chapter, the legal aspects of the use of identifiers receive attention. In the setting of this deliverable, this description focuses especially on the usage of single ID numbers versus multiple ID numbers in the public domain. Point of departure is the European Data Protection Directive. Since in the public domain e-government development depends hugely on the use of ID numbers, this chapter starts by defining several concepts that play an important role in the tehnical area. It then elaborates from a legal perspective the most relevant principles in the Data Directive. The chapter rounds up by trying to find an answer to the question whether the usage of global identifiers within a sound legal framework can be acceptable from a legal perspective for the default data exchange between two or more government entities or not. 

Introduction

An identifier is an attribute or a set of attributes of an entity which uniquely identifies an entity in a certain context. For example, the attribute of wearing a hat is an identifier to distinguish both men in this figure from each other:

Figure . Identifiability © Prime Project, March 2006

In an online environment, identifiers are usually numerically structured and are therefore called identification numbers (ID numbers). The fact that they are uniquely identifying someone or something in a particular context is an important property, because they can be used to link data from one context to another, in both admissible and inadmissible ways.

Unlinkability is often said to be a privacy protecting feature. It can be defined as the state in which two items of interest (typically sets of personal data) in an identity management system are not more related after the observation by an attacker than they were related taking into account the a priori knowledge.

Our starting point is the finding that Privacy Enhancing Technologies (PETs) that focus on concealing the identity (anonymity) or on the usage of different sector or context- specific identifiers (pseudonymity) only have a limited sales potential, namely where the non-respect of privacy causes obvious direct damages, for instance, with sensitive data. For instance, in Belgium, discussions continue about adding specific context-specific identifiers for health and judicial data. Also, for some years, specific regulation exists for reusing personal data for scientific, historical or statistical purposes. It requires anonymization, encoding or limited unencoded disclosure, following consent of the data subject (depending on the situation at stake).

Besides these measures, the question remains what should be the default position for all other personal data in eGovernment. Is the usage of global identifiers – when surrounded by a sound legal framework – enough, or should technical unlinkability also be a requirement of an eGovernment architecture?

In this contribution we try to answer a small part of this question, by describing what we can learn from the Data Protection Directive and the European Convention on Human Rights on the topic of global identifiers in the public sector.We start by saying a few words on the reason why identifiers are necessary in eGovernment. It helps us to understand why eGovernment managers are clearly reluctant to restrain technically the opportunities they have to crosslink data sets about their clients.

Identifiers in the public sector

There are probably as many definitions of the term eGovernment as there are people working in that field. The Belgian definition is based on one from the World Bank. The Belgian Federal government defines it as ‘the continuous optimization of service delivery and governance by transforming internal and external relationships through technology, internet and new media’. This optimization of service delivery and governance relies on a number of important building blocks. One of them is the integration of back-offices.

In Belgium, integration is sought via a ‘Service Oriented Architecture’ (SOA) that spans multiple administrative contexts. Identity management components such as authentication and authorization mechanisms are being integrated as basic service components of a SOA, and compiled with other components to so-called value-added services. An important requirement to achieve back-office integration is to make sure that the stakeholders (i.e., the different government levels) agree on an interoperability framework. On the Belgian Federal level, this framework consists of technical and functional interoperability measures and the usage of common ID numbers for all relevant entities.

Against this background it is easy to understand why the usage of ID numbers is paramount for eGovernment:  

1. When government entities that do not share the same information infrastructure want to offer efficient, effective services to all their clients (citizens, enterprises etc.), they need to share data about these clients between the relevant administrative contexts of the ‘integrated back-office’. To make sure the data exchange concerns the correct clients, identifiers are needed.

2. When the exchanged data is personal, confidential or protected, sharing it has to be carefully controlled, among other things, in order to comply with data protection regulation and with information security best practices.  

Identity management systems are often designed to do exactly that, for instance, identifying and authenticating internal and external users of the organization, and managing their authorizations to perform actions on the information system.

Typically, these services are part of a lifecycle and thus strongly interconnected: authorization typically requires successful prior authentication and the latter typically requires a successful prior identification, which in its turn is normally based on a sound registration.

The registration process results in the assigning of a partial identity to the entity, and this typically includes identifiers that are valid at least in that context (context-specific) or sector (sector-specific). If the identifier needs to be used by the data owner itself (employee, citizen, enterprise…), it is then often used as username to uniquely identify the user in that context. During the registration process, the entity also receives the means to authenticate that identity in the future with one or more credentials (e.g., a password).

1. Very often, in eGovernment, the goal is not only to identify, authenticate and authorize users in respect of their own information system, but also that of other entities that are part of the so-called ‘circle of trust’. In practice, in an integrated back-office the available identity data of the users is also shared between the different members – in this case administrations – of this circle of trust.

As a result of this shared data, trust decisions can be made and cross-level, integrated identity management and eGovernment services can be offered to the users (e.g., single sign on).

The tension we’re pointing at in this contribution has nothing to do with the usage of identifiers as such, but with the usage of permanent identifiers that remain valid across several contexts and sectors of action. We call them ‘global identifiers’. As we will see below, it is absolutely not self-evident to use common (global) identifiers to refer to the same entity in different contexts and information systems.

Context specific, sector-specific and global identifiers

A context is a sphere of activity, a geographic region, a communication platform, an application, a logical, or physical (security) domain. Contexts are, for example, taxes, social security, health care, judicial, education, etc, and restrained to a geographic region, e.g. Belgium on the federal level.

In identity management we typically refer to its meaning as a communicational context. The latter is then qualified by roles and behavioral schemes participants in communication take over. The term is also often used in its meaning as a security domain. This is an environment defined by security models and a security architecture, including a set of resources and set of system entities that are authorized to access the resources. The traits defining a given security domain typically evolve over time. An example of a context is Belgian Federal Social Security. It is a sphere of activity (social security), a communicational context (e.g., two or more entities communicating via some form of platform (or interface) that is only available for social security purposes), and a security domain to which specific security policies apply.

When we refer to context-specific identifiers, we mean that the used (persistent or transient) identifiers are not common to the different contexts in which data is being exchanged. Alternatively, when we refer to global identifiers, we mean that the used identifiers are persistent and have global application (often but not necessarily on a national level), between two or more contexts or sectors.

The picture becomes more complicated when a context spans multiple sectors. A sector is a synonym for an administrative domain, i.e., an environment that is defined by a combination of:

1. one or more administrative policies,  

2. Internet Domain Name registrations,  

3. civil or public legal entities (for example, individuals, corporations, or other formally organized entities), and  

4. a collection of hosts, network devices and the interconnecting networks (and possibly other traits), and (often various) network services and applications running upon them.

In the mentioned example of ‘Belgian Federal Social Security’, the Federal Unemployment Allocation Fund, the Federal Service for Pensions and the Federal Children’s Allocation Fund are sectors of that context. In this example, the used identifier is common to all the sectors within this Social Security context. In other words: the identifier is not sector-specific.

As we will see in the Belgian country report, the problem in this case is not so much the non-usage of sector-specific identifiers, but the non-usage of context-specific identifiers: the used identifier – the Belgian National Registry number – is not limited to the context of Social Security either. It is a ‘global identifier’.

In addition to all this – and this is what makes the picture even more complicated – a sector of action (or administrative domain) is not necessarily limited to an action in exactly one context.  

In the mentioned example of Belgian Federal Social Security, the Belgian Crossroads Bank for Social Security acts in the first place as a facilitator for the exchange of social data within the Belgian Federal social security context (this is enacted in the articles 3, 3bis, 4 and 6 of the Law of 15 January 1990). However, in view of a decision of the Privacy Commission of 28 September 2005, it is clear that the Crossroads bank also has an identification function that exceeds the social security context. In other words, one part of a sector – the Crossroads Bank – plays a role in several contexts. For instance (1) it acts as a social data facilitator in the context of Belgian Federal Social Security and (2) it acts as an identification service provider with regard to a specific category of persons in Belgian (national) eGovernment.

To sum up, government entities that are a sector of even a part of a particular sector can act in multiple contexts. The entities that act in one or more contexts can also act in multiple sectors. Typically, in eGovernment, the (relevant) entities that act in these contexts and sectors will be assigned either a global, sector-specific or context-specific identifier. The usage of these numbers is largely influenced by data protection rules, which we will explain in the following sections. 

Application field – ID numbers are ‘personal data’

Generally speaking, data protection regulation provides for a series of rights for natural persons. They generally demand good data management practices on the part of the data controllers and include a series of obligations. Even though some exceptions and limitations for the public sector are foreseen, these rules in principle apply to both public and private sector data processing.

The data protection Directive only applies to the processing of personal data. According to the Directive, personal data is any information relating to an identified or identifiable natural person (the data subject) (article 2 of the Directive). Recital 26 of the Directive further explains what should be understood with ‘identifiable’. For instance, it says that ‘to determine whether a person is identifiable, account should be taken of all the means likely reasonably to be used either by the controller or by any other person to identify the said person’.

In general terms, a natural person can thus be considered as ‘identified’ when, within a group of persons, if he or she is distinguished from all other members of the group. Yet, the natural person will be said to be ‘identifiable’ when, although the person has not been identified yet, it is possible to do it (that is the meaning of the suffix ‘-able’).  

Article 2 of the Directive further states that ‘a natural person can be identified, directly or indirectly, in particular by reference to an identification number or to one or more factors specific to his physical, physiological, mental, economic, cultural or social identity’. The extent to which certain identifiers are sufficient to achieve identification is something dependent on the context of the particular situation.

Identification through the name is the most common occurrence in practice. Nevertheless, a name may itself not be sufficient, nor necessary in all cases to identify an individual: 

1. In order to ascertain an identity, the name of the person sometimes has to be combined with other pieces of information (date of birth, names of the parents, address or a photograph of the face) to prevent confusion between that person and possible namesakes.

2. The name may also be the starting point (the key) leading to other information (e.g. about where the person lives or can be found). All these new pieces of information linked to the name may allow someone to zoom in on the flesh-and-blood individual, and therefore through the identifiers the original information is associated with a natural person who can be distinguished from other individuals.

3. The term ‘indirectly’ identified or identifiable persons, refers to the situation where the available identifiers do not allow anyone to single out a particular person. This is where the Directive comes in with the phrase ‘one or more factors specific to his physical, physiological, mental, economic, cultural or social identity’. Some characteristics are so unique that someone can be identified with no effort (e.g., the present Prime Minister of Spain), but a combination of details on categorical level (age category, regional origin, etc) may also be conclusive in some circumstances, particularly if one has access to additional information of some sort.

eGovernment information systems can typically be seen as ‘FIDIS type 1 IDM systems’, since the identity of its users, clients etc. is being assigned by the organization itself. In such information systems, it is nor feasible nor desired to choose for identification via the name. To avoid confusion between two persons in the database or file, they typically assign unique ID numbers to all the persons registered.

In other words, the individual’s personality is put together in order to attribute certain decisions to him or her. It is possible to categorize the person on the basis of socio-economic, psychological, philosophical or other criteria and attribute certain decisions to him or her since the individual’s contact point (a computer) no longer necessarily requires the disclosure of his or her identity in the narrow sense.

Important for our analysis, is that ID numbers that refer to natural persons can definitely be qualified as personal data in the sense of the data protection Directive. This is because – when we evaluate the reasonable means likely to be used by the data controller or by any other person – the purpose for which an ID number is assigned is an important factor.  This purpose is – obviously – to identify the natural person and as a result, ID numbers are personal data.

This has important implications. When we take into account the other criteria for the Directive to apply (not being set out here), we can conclude that the data protection rules normally also apply to ID numbers when they are used in the public sector. It means, among other things, that the processing of personal data – i.e., the ID number – is carried out in a fair and lawful way with respect to the data subjects:

Data processing is only lawful if it takes place in accordance with the law. In a nutshell, this means that the data controller should take into account: 

1. the legitimacy of the data processing;

2. special categories of data;

3. the data quality (including the ‘finality’ principle);

4. the data subject rights; 

5. confidentiality and security of the personal data;

6. notification and transparency; and  

7. export of personal data to third countries outside the European Union. 

In the next sections we briefly elaborate on the most relevant of these principles (underlined in the list) and on article 8,7° of the Directive (that refers to the usage of global identifiers).  

Legitimacy principle

In a nutshell, this principle means that data controller should verify that the processing falls under one of the criteria for making data processing legitimate. The general rule is that processing of personal data is not allowed, except when it is based on one of the following legitimacy grounds:

1. The consent of the data subject;

2. A legal obligation which the controller has to comply with; 

3. A task carried out for the public interest; 

4. A contract to which the data subject is or will be party;  

5. Protection of the vital interests of the data subject; or  

6. The legitimate interests pursued by the controller.

In the public sector, the processing of the ID number that refers to natural persons typically will need to comply with one of the first 3 grounds. This is so because the legitimacy grounds on which governments act can at times overlap the legitimacy grounds of the processing of personal data. 

Data quality and the reuse of personal data

The processing of personal data should be respecting the minimum data and data processing quality principles, such as the ‘finality’ and the ‘proportionality’ principle (article 6 of the Directive).  

Briefly summarized, the term finality refers to the obligation to only collect personal data for specified, explicit and legitimate purposes. Personal data shall not be further processed it in a way incompatible with those purposes. Further processing of data for historical, statistical or scientific purposes shall not be considered as incompatible if the appropriate safeguards are taken. The purpose of the processing should be defined the latest at the moment of the collection of the data.

The proportionality principle has to be understood in terms of:

1. storage duration: The processed data may not be kept in a form permitting identification of data subjects for longer than is necessary for the purposes for which the data were collected or for which they are further processed. 

2. necessity of the data: The processed data should be adequate, relevant and not excessive in relation to the purposes for which they are collected and further processed. 

3. further processing of the data: The purposes of further processing should not be incompatible with the purposes initially defined the data were collected.  

4. accuracy: personal data should further be accurate and, where necessary, kept up to date. 

Applied to ID numbers, it is clear that the data controller that decides to make use of a global, sector-specific or context-specific identifier should:  

1. make sure that the chosen data (for example, a global ID number instead of a sector-specific one) is adequate, relevant and not excessive in relation to the purposes for which it is being collected and/or further processed; 

2. make sure that the ID number is accurate and, where necessary, kept up to date and 

3. not kept in a form which permits identification of data subjects longer than is necessary for the purposes for which the data were collected or for which they are further processed.  

These findings are important for our analysis when we evaluate the question raised above with regard to technical unlinkability as a requirement of an eGovernment architecture.

In addition, on the topic of finality and proportionality, it is important to note that when two or more government entities integrate their back-offices, there will typically be a reuse of personal data for another purpose than the one that was originally indicated. For example, when a particular set of data has been collected from a citizen for unemployment allowance purposes, the idea of eGovernment would be to make that data directly available to the tax authorities – of course within the borders of the law – instead of asking it again to the citizen.

As mentioned, the finality principle requires the further processing to be compliant with the original purposes.

In Belgium, the legislator has clarified the criteria that should be taken into account at interpreting whether or not a planned data processing is compliant with the original purposes. The law says that account should be taken of ‘all relevant factors, in particular the reasonable expectations of the data subject and the applicable legal and regulatory provisions’ (article 4 of the Belgian Data Protection Act).

Yet, with or without this additional clarification, it is important to note that data processing purposes can be adapted by changing the legal provisions. We take this finding with us when we evaluate which technical and organizational security measures are ‘appropriate’ for ID numbers in eGovernment (see below).

Specific provision on the usage of global ID numbers

Before we come to that analysis, it is appropriate to say a few words on the specific provision on the processing of global ID numbers in article 8.7° of the data protection Directive. It runs as follows: 

‘Member States shall determine the conditions under which a national identification number or any other identifier of general application may be processed.’ (Article 8.7°)

At first sight, the article only seems to say that the EU Member States should decide if and how they protect ‘identifiers of general application’, i.e., global identifiers. Nevertheless, the location of the article in the Directive is also important here: it has been inserted in the chapter on ‘sensitive data’ (next to, for example, provisions on the processing of personal data revealing racial or ethnic origin). 

Therefore, it is not unrealistic to conclude that the authors of the Directive believed that global identifiers are indeed a special category of data, which might need additional protection. Nevertheless, when we take into account what we explained in the previous sections, we can at least conclude that it is surprising that they have left the matter up to the member states, especially given the (not necessarily illegal) linkage capacity that arise from the usage of global identifiers.

As a result, the following scenarios can be formulated:  

1. If the usage of global identifiers is forbidden in the Member State, the Data Protection Authority has the important task of verifying that context-specific numbers are indeed not being used outside their respective contexts.  

2. If the usage of some or all global identifiers is regulated, the Data Protection Authority mainly verifies whether the conditions under which that identifier can be processed are fulfilled.

3. If the usage of global identifiers is allowed or at least not being regulated, the Data Protection Authority only verifies whether the number is being processed within the limits of the data protection regulation (finality, proportionality, protection level etc.), as explained above.

Appropriate technical and organizational security measures

The fact whether the usage of global or other ID numbers is regulated or not by a Member State does not affect the application of the data protection rules. These rules serve as a minimum, from which the Member State cannot derogate.  

As a result, in addition to the rules briefly recapitulated in the previous chapters, the data controller should take the appropriate organizational and technical security measures to protect the personal data against a number of things (e.g. destruction, loss, alteration etc), including any unlawful form of data processing (article 17 of the Directive).

To evaluate the ‘appropriateness’ of the measures, three factors play a role, namely (1) the state of the art, (2) the cost of their implementation and (3) the risks represented by the processing and the nature of the data to be protected (article 17 of the Directive). This requires some additional explanation: 

1. The risks resulting from the nature of the data for example result from the data itself, the nature of the purposes of the data processing, the legal relation between the data controller and the data subject etc.

2. Risks represented by the data processing are, for example the location where the data are being processed, the fact that there are multiple data processors, the used technique etc.

3. The fact that account should betaken with the ‘state of the art’ means that the data processing should take into account the technological evolution. The security measures should progress accordingly. Recital 46 of the Directive further explains that the security obligation requires that appropriate technical and organizational measures are in place, both at the time of the design of the processing system and at the time of the processing itself, particularly in order to maintain security and thereby to prevent any unauthorized processing.

The whole idea is thus to ensure a level of security appropriate to the risks represented by the processing at stake. 

Interesting in a public sector context is that it is not possible to make exceptions to these security rules: exemptions and derogations are possible for the purpose of balance between fundamental rights as regard to legitimacy of data processing, measures on the transfer of data to third countries and the power of the supervisory authority, but not with regard to the security of the processing (recital 37 of the Directive).

Evaluation

Our basic finding and main point of departure is that identifiers are definitely needed in the public sector, especially to achieve the goals of eGovernment, for instance, ‘the integration of back-offices’. Without data protection rules, it seems obvious to choose common, global identifiers between these back-offices, and not technically to be constrained by context- and or sector-specific identifiers. The question we have raised is whether the usage of global identifiers within a sound legal framework can be acceptable from a legal perspective for the default data exchange between two or more government entities or not. The alternative would be to choose technical unlinkability as a requirement of an eGovernment architecture, which would imply the usage of context- and/or sector-specific identifiers.

At the other side of the spectrum, we also analyzed the data protection rules. From this perspective, we conclude that: 

1. If the usage of global identifiers is forbidden in the Member State (e.g., because it is unconstitutional), technical unlinkability should be a requirement of the architecture design. 

The Data Protection Authority has the important task of verifying that context-specific numbers are indeed not being used outside their respective contexts.  

1. If the usage of some or all global identifiers is regulated, the basic data protection rules still apply. The additional rules should take the data protection principles as a minimum. The Data Protection Authority here mainly verifies whether the conditions under which that identifier may be processed are fulfilled.

2. If the usage of global identifiers is allowed or at least is not forbidden, the Data Protection Authority only verifies whether the number is being processed within the limits of the data protection regulation (finality, proportionality, protection level etc.), as explained above.

We also conclude a number of additional, crucial issues when having a closer look at the data protection principles. From this analysis we indicate that: 

1. The data controller should make sure that the chosen data (for example, a global ID number instead of a sector-specific one) is adequate, relevant and not excessive in relation to the purposes for which it is being collected and/or further processed. In other words, a global identifier can be excessive in relation to the purposes for which the data is being collected. For instance, if no legitimate cross-context or cross-sector data exchange is present at the first processing the ID number, a context- or sector-specific identifier should suffice.

2. The data controller should make sure that the ID number is not kept in a form which permits identification of data subjects for longer than is necessary for the purposes for which the data were collected or for which they are further processed.

In practice, this means that when the purposes of processing the ID number have been realised, it should be anonymized. Encrypting or encoding the ID number will most probably not be sufficient if the reason why the ID number is being processed like that (encrypted …) is to be able to re-identify the person if needed. In that case, as explained, the ID number would still be identifiable data – and thus also personal data.

1. To evaluate the necessary, ‘appropriate’ technical and organizational security measures, 3 factors play a role, for instance: (1) the state of the art, (2) the cost of their implementation and (3) the risks represented by the processing and the nature of the data to be protected. We believe that the state of the art means that security measures should follow the technological evolution.

This means that if technologies to ensure unlinkability between contexts and sectors mature sufficiently (which is more and more the case today) they should be chosen if they are more conducive towards achieving the goals of the processing. It also means that it can be an unacceptable risk to not take unlinkability measures.  

Yet, this is also the tricky part of the answer to the above mentioned question on ‘technical unlinkability’: it depends on the evaluation of the case at stake.

1. Until now, in Belgium, the decision was taken to use only one global identifier as the default position in eGovernment. The usage of this identifier is legally controlled and in specific contexts with highly sensitive data (eHealth and justice data), negotiations are going on to add in context-specific identifiers.

All in all, at first sight we could argue that in Belgium the technical and organizational security measures seem ‘appropriate’ given the concrete risks vs. cost evaluation vs. measures taken to protect against these risks.

Nevertheless, there seem also to be valid arguments against the usage of global identifiers as the default position for every data exchange in eGovernment in Belgium. For instance, we should also take into account the fact that:

1. 1. All data processing is important, especially because the default position is that data processing is forbidden. 

   2. The technology to implement sector- / context-specific identifiers that is, for example derived from the existing global identifier is not expensive. 

   3. The data controller should at least make sure – by restraining the technological means used to process the data, in this case the ID number –  that he avoids any unlawful data processing. As we will explain in the country report, this is currently a problem in Belgian eGovernment.

   4. One important risk that should be taken into account, is that data processing purposes are more likely to be adaptable (and thus legitimate) in the public sector than in the private sector. When two or more government entities integrate their back-offices, there will typically be a reuse of personal data for another purpose than the one that was originally indicated.

There is a realistic risk that once the necessary infrastructure which includes global ID numbers is in place, data exchange based on that number will take place anyway, legitimately or illegitimately, based on ad hoc arguments or on different political choices. As a result, this seems to be a strong argument for context- and/or sector-specific identifiers, when we have to balance the cost of its implementation and the risks created by the nature of the data and the processing.  

Conclusion

To conclude, based on the mentioned data protection principles, there seems to be no general obligation to add in sector- or context- specific identifiers on a large scale, as the default position for every data exchange in eGovernment:

However, there are a number of arguments against the usage of global identifiers in eGovernment, as the default position as well.The evaluation takes into account a number of factors, being (1) the state of the art, (2) the cost of the implementation and (3) the risks created by the nature of the processing and the data itself. 

If we take Belgium as an example, the appropriate technical and organizational security measures here seem at first sight to be taken, because we can also take into account the legal framework that makes data exchange based on the global identifier subject to a prior authorization of the privacy commission (see the country report).

Nevertheless, it appears that there are also important risks created by the usage of global identifiers in Belgian eGovernment, among other things, because it is much more easy for the public sector to adapt the purposes and legitimacy grounds upon which a particular data processing is based. Therefore, it seems reasonable that the data controller should at least make sure – by restraining the technological means used to process the global ID number (in this case the ‘Rijksregisternummer’, see the country report), to avoid any unlawful data processing.

References

Law of 11 December 1998 on the transposition of the Data Protection Directive 1995, Belgian State Gazette 3 February 1999. 

Explanatory memorandum of the Reform of the Data Protection Law, session 1997-1998, document number 1566/1, available on the website of the Chamber of Representatives, available on www.dekamer.be.

Law of 8 December 1992 on Privacy Protection in relation to the Processing of Personal Data, Belgian State Gazette 18 March 1993, as modified by the law of 11 December 1998 implementing Directive 95/46/EC, Belgian State Gazette 3 February 1999, and the law of 26 February 2003, Belgian State Gazette 26 June 2003. 

Article 29 Data Protection Working Party 2007 

Opinion 4/2007 of 20th June 2007 of the Article 29 Data Protection Working Party on the concept of personal data, available at: http://ec.europa.eu/justice_home/fsj/privacy/ workinggroup/index_en.htm.

Bauer, Meints & Hansen 2005 

M. Bauer, M. Meints & M. Hansen (eds.), D3.1, Structured Overview on Prototypes and Concepts of Identity Management Systems, Deliverable 3.1 of the EU Funded FIDIS project, available at: http://www.fidis.net/fileadmin/fidis/deliverables /fidis-wp3-del3.1.overview_on_IMS.final.pdf, 15 September 2005, last visited: 20 August 2006.

Belgian Privacy Commission 2005 

Advice of the Belgian Privacy Commission with regard to the evocation of the files SCSZ /05/70, SCSZ /05/90, SCSZ /05/110 and SCSZ/05/113 on identification via the Crossroads bank for Social Security or via the RRN, number SA2/EV/2005/001, 28 September 2005, available at: www.privacycommission.be, last visited: 23 March 2006.

De Bot 2005 

D. De Bot, ‘Privacybescherming bij e-government in België. Een kritische analyse van het Rijksregister, de Kruispuntbank van Ondernemingen en de elektronische identiteitskaart.’, Vandenbroele, Brugge, 2005, 469 p.

Cuijpers 2006 

C. Cuijpers, ‘De Europese Privacyrichtlijn van 25 oktober 1995’, Afl. 20, Januari 2006, in P. De Hert (ed.), Privacy en Persoonsgegevens, Brussel: Politeia, losbladig.

Cullen International 1999 

Cullen International, a business guide to changes in European data protection legislation, The Hague: Kluwer Law International 1999.

Deprest & Robben 2003 

J. Deprest & F. Robben, eGovernment: the approach of the Belgian federal administration, available at: http://www.ksz.fgov.be/En/Como/2003%20-20EGovernment%20paper%20v%201.0.pdf, June 2003, last visited: 20 June 2006.

Deprest & Strickx 2005 

J. Deprest & P. Strickx, eGovernment initiatives, available at: http://www.ibbt.be/egov/pres/9._Jan_Deprest_-2005.10.26-_eGov_update_ initiatieven.ppt, 26 October 2005, last visited: 20 September 2006.

Directive 95/46/EC 

Directive 95/46/EC of the European Parliament and of the Council of 24 October 1995 on the protection of individuals with regard to the processing of personal data on the free movement of such data, Official Journal of the European Communities, L 281, 23 November 1995, 31-50. 

Hodges 2006 

J. Hodges (ed.), Liberty Technical Glossary, available at: http://www.projectliberty.org/specs/draft-liberty-glossary-v2.0-05.pdf, 9 June 2006, last visited: 15 June 2006.

Hodges, Philpott & Maler 2005    

J. Hodges, R. Philpott & E. Maler, Glossary for the OASIS Security Assertion Markup Language (SAML) V2.0, available at: http://docs.oasis-open.org/security/saml/v2.0/saml-glossary-2.0-os.pdf, 15 March 2005, last visited: 22 December 2005.

Hildebrandt, Gutwirth & De Hert 2005 

M. Hildebrandt, S. Gutwirth & P. De Hert (eds.), Fidis Deliverable 7.4, Implications of profiling practices on democracy and rule of law, available at: http://www.fidis.net/fileadmin/fidis/deliverables/fidis-wp7-del7.4.implication_ profiling_practices.pdf; 5 September 2005, last visited: 15 September 2006.

ITU-T 2005 

X, Security Compendium Part 2 - Approved ITU-T Security Definitions, available at: http://www.itu.int/ITU-T/studygroups/com17/def005.doc, May 2005, last visited: 20 April 2006.

Kissel 2006 

R. Kissel (ed.), NIST IR 7298. Glossary of Key Information Security Terms, available at: http://csrc.nist.gov/publications/nistir/NISTIR-7298_Glossary_Key _Infor_Security_Terms.pdf, 25 April 2006.

Meints 2005 

M. Meints, D3.5: Workshop on ID-Documents, Deliverable 3.5 of the EU funded FIDIS project, available at: http://www.fidis.net/fileadmin/fidis/ deliverables /fidis-wp3-del3.5.workshop_on_id_docs.pdf, September 2005, last visited: 19 September 2005.

Modinis IDM 2005 

X., Modinis IDM Terminology Paper, available at: https://www.cosic.esat.kuleuven.be/modinis-idm/twiki/pub/Main/GlossaryDoc/modinis. terminology.paper.v2.01.2005-11-23.pdf, 23 November 2005, last visited: 23 November 2005.

Nabeth 2005 

T. Nabeth (ed.) D2.3 Set of use cases and scenarios, Deliverable 2.3 of the EU funded FIDIS project, available at: http://www.fidis.net/fileadmin/fidis/ deliverables/fidis-wp2-del2.3.models.pdf, September 2005, last visited: 28 March 2006.

Nabeth & Hildebrandt 2004 

T. Nabeth & M. Hildebrandt (eds.), Inventory of topics and clusters, Deliverable 2.1 of the EU funded FIDIS project, available at: http://www.fidis.net/fidis-del/period-1-20042005/d21/, 28 October 2004, last visited: 25 January 2005.

Pfitzmann & Hansen 2006 

A. Pfitzmann & M. Hansen, Anonymity, Unlinkability, Unobservability, Pseudonymity, and Identity Management – , available at: http://dud.inf.tu-dresden.de/literatur/Anon_Terminology _v0.27.pdf, 20 February 2006, last visited: 20 February 2006.

Robben 2006 

F. Robben, Gebruik van de elektronische identiteitskaart in de sociale sector: concrete toepassingen en toekomstige visie, available at: http://www.ksz.fgov.be/documentation/fr/documentation/Presse/20060314a.ppt, 14 March 2006, last visited: 20 September 2006.

Robben 2005 

F. Robben: 1st Modinis Workshop on Identity Management in EGovernment, available at: http://www.law.kuleuven.ac.be/icri/frobben/presentations/ 20050504.ppt, 4 May 2005, last visited: 30 March 2006.

Rössler 2002 

Identification and Authentication in Networks enabling Single Sign-On, available at http://www.iaik.tu-graz.ac.at/teaching/11_diplomarbeiten/archive/roessler.pdf, October 2002, last visited: 15 October 2005.

Slone 2004 

S. Slone, Identity Management. A white paper, available at: http://www.opengroup.org/onlinepubs/7699959899/toc.pdf, March 2004, last visited: 11 November 2004.

Zucker 1986 

L.G. Zucker, ‘Production of trust: Institutional sources of economic structure, 1840-1920’, In, B.M. Staw & L.L. Cummings (ed.), Research of organizational behavior, London (UK): JAI Press Inc. 1986, pp. 53-111.