Study on eid Interoperability for PEGS: Update of Country Profiles Analysis & assessment report

Study on eid Interoperability for PEGS: Update of Country Profiles (D2.1 Report on analysis and assessment of similarities and differences; D2.2 Report on impact on eid interoperability)

This report / paper was prepared for the IDABC programme by: Coordinated by: Hans Graux (time.lex), Jarkko Majava (Siemens), Eric Meyvis (Siemens) Contract No. 1, Framework contract ENTR/05/58-SECURITY, Specific contract N 12 Disclaimer The views expressed in this document are purely those of the writer and may not, in any circumstances, be interpreted as stating an official position of the European Commission. The European Commission does not guarantee the accuracy of the information included in this study, nor does it accept any responsibility for any use thereof. Reference herein to any specific products, specifications, process, or service by trade name, trademark, manufacturer, or otherwise, does not necessarily constitute or imply its endorsement, recommendation, or favouring by the European Commission. All care has been taken by the author to ensure that s/he has obtained, where necessary, permission to use any parts of manuscripts including illustrations, maps, and graphs, on which intellectual property rights already exist from the titular holder(s) of such rights or from her/his or their legal representative. This paper can be downloaded from the IDABC website: http://ec.europa.eu/idabc/en/home http://ec.europa.eu/idabc/en/document/6484 European Communities, 2009 Reproduction is authorised, except for commercial purposes, provided the source is acknowledged. Page 2 of 228

Table of Contents EXECUTIVE SUMMARY 5 1 DOCUMENTS 14 1.1 APPLICABLE DOCUMENTS 14 1.2 REFERENCE DOCUMENTS 14 2 GLOSSARY 16 2.1 DEFINITIONS 16 2.2 ACRONYMS 18 3 INTRODUCTION 19 3.1 SCOPE AND OBJECTIVES OF THE PROJECT 19 3.2 GENERAL STRUCTURE OF THE PROJECT 19 3.3 GOAL OF THIS DOCUMENT 20 4 ANALYSIS 22 4.1 IDENTIFIED NATIONAL IDENTITY RESOURCES 22 4.1.1 IDENTITY TOKENS 23 4.1.2 NATIONAL IDENTIFIERS 46 4.1.3 IDENTITY REGISTERS 62 4.1.4 BIOMETRICS 74 4.1.5 MOBILE PHONE BASED IDENTIFICATION 77 4.2 AUTHENTIC SOURCE PRINCIPLE 81 4.3 AUTHENTICATION SECURITY EXISTING SYSTEMS AND POLICIES 85 4.3.1 AUTHENTICATION POLICIES 85 4.3.2 PKI BASED SYSTEMS 90 4.3.3 NON-PKI SYSTEMS 96 4.4 MANDATE MANAGEMENT AND AUTHORISATIONS 101 4.5 LEGAL / POLICY ANALYSIS 106 4.5.1 THE EUROPEAN LEGAL FRAMEWORK 107 4.5.2 NATIONAL REGULATORY APPROACH MODELS 118 4.5.3 PRIVACY ISSUES 123 4.5.4 AUTHENTICATION LEVELS: REGULATIONS AND POLICIES 130 4.6 E-GOVERNMENT APPLICATIONS USING EIDM 136 4.6.1 INTRODUCTION POSSIBLE AUTHENTICATION METHODS IN APPLICATIONS 136 4.6.2 EHEALTH APPLICATIONS 137 4.6.3 EJUSTICE 146 4.7 TECHNICAL / INFRASTRUCTURAL ANALYSIS 154 Page 3 of 228

4.7.1 COMMONLY USED TOKENS 154 4.7.2 AUTHENTICATION SYSTEMS (EIDM APPLICATIONS) 171 4.7.3 INTERNATIONAL INTEROPERABILITY APPROACHES 194 4.7.4 ADOPTED INDUSTRIAL STANDARDS 203 5 IMPACT ASSESSMENT 210 5.1 INTRODUCTION 210 5.2 IDENTIFIED INTEROPERABILITY ISSUES 210 5.2.1 AT THE LEGAL/POLICY LEVEL 210 5.2.2 AT THE TECHNICAL LEVEL 224 Page 4 of 228

Executive summary Introduction The current study entitled eid Interoperability for PEGS: Update of Country Profiles aims to collect information on eid practices and developments in the Member States, EEA countries and the candidate countries Turkey and Croatia, with a view of comparatively analysing these and providing specific inputs on quick wins that these countries could implement to establish a certain degree of interoperability. As the name indicates, the project builds on the information collected in the 2007 IDABC study on eid Interoperability for PEGS, in which similar information was collected. The current study aims to update that information, and to add specific new information, including specifically on authorisation/mandate management solutions, mobile identification, and eid in ehealth/ejustice applications. The present report contains the analysis and assessment of the collected national information, to determine any patterns in the national approaches and to derive a set of constraints with regard to electronic identity management for egovernment applications. Main findings with regard to the analysis and assessment of similarities and differences As with the 2007 edition, this report examines the available identity resources and solutions, along with the legal and technical choices made at the national level. The main findings can be summarised as follows. Identity resources With regard to identity tokens, the study found that 13 out of 32 surveyed countries are deploying government supported eid cards, including however a group of six countries relying on eid cards issued by private CSPs with a public sector mandate (Austria, Iceland, Liechtenstein, Luxembourg, the Netherlands and Sweden); in the seven others eid cards are issued by public bodies (Belgium, Estonia, Finland, Italy, Lithuania, Portugal and Spain). In addition to these, 12 countries currently have paper ID cards, but have eid card plans for the near future. Five countries currently do not issue identity cards (Denmark, Ireland, Latvia, Norway and the UK), but plans to issue eid cards in some form exist in all but Denmark. Thus, eid cards will become increasingly common in the next few years. When looking at the use of biometrics, 5 countries out of 32 report actually using biometrics (Italy, Lithuania, the Netherlands, Portugal and Spain), in each case relying on fingerprint data (in hashed form in the Italian case). Lithuania and the Netherlands did not yet have fingerprints stored or their eid means in the 2007 edition of this study; in both cases, the change relates to an update of their respective identity cards. A majority of the surveyed countries (20 of 32 countries, 63%) have not made any plans for biometrics yet, and the use of biometric data has not been reported as an authentication method for specific egovernment applications in any country. Usage of mobile phones for authentication purposes in egovernment applications is similarly still largely at an experimental stage: while eight countries (Austria, Estonia, Lithuania, the Netherlands, Norway, Poland, Slovenia and Turkey) have mobile phone based identification solutions available, a clear majority of 21 out of 32 countries are not using mobile phone identification and have no plans to change this in the near future. Apart from available authentication means, the study also examined the use of national identifiers, defined as any code, string or number that is assigned to a specific entity for the purposes of uniquely identifying that entity among all other similar entities within a specific user group defined below. All countries use general identifiers, i.e. identifiers that are not restricted to use within one specific application or sector; however, they apply vastly different standards for the lawful use of such identifiers. A number of countries consider that public sector issued identifiers should be protected Page 5 of 228

against trivialisation through private sector use, as this would create a privacy risk. Additional legal protection regimes were reported in 20 of the 32 surveyed countries (63%). Legal regimes in at least two countries (Germany and Hungary) oppose the use of general identifiers for identification purposes on constitutional grounds. This means that the systematic use of general identifiers for the cross border identification of natural persons is a legally complex issue. This study also examined the acceptance of an authentic source principle (i.e. the policy that each specific identity attribute should have one and only one authentic source, making all other sources for that attribute obsolete). Formal acceptance of an authentic source principle is thus altogether uncommon, and was reported in only 6 countries out of 32 (19%), virtually equal to the 2007 edition of the study (5 out of 32). A further 10 countries (31%) had informally adopted the principle (as compared to 9 in 2007), with another 3 (10%) planning to do so (idem as in 2007). Authentication systems Next, the study examined the use of authentication systems, both PKI systems and username/password systems. For PKI systems, a distinction is made between public sector controlled PKI systems and public/private partnerships. For the purposes of this report, the distinction lies in the allocation of the function of the registration authority who verifies the identity of the party requesting the PKI token. A total of 17 countries out of 32 (53%, 3 more countries than in 2007) reported using public sector controlled PKI systems as defined above, with a total of 22 systems being reported (+6 compared to 2007). Of these 22 systems, 15 were open to private sector use (68%). 20 countries out of 32 (62,5%, 4 more countries than in 2007) reported using public/private sector controlled PKI systems as defined above. Given the involvement of the private sector, it is unsurprising that all of these could also be used in the private sector. Combining both tables, a sizable majority of 27 out of 32 countries (84%, three more than in 2007) have reported using PKI systems (either public or public/private controlled) for the purposes of entity authentication. Username/password systems (including through two factor authentication and time specific password calculators) also remain very popular. In total, 22 countries out of 32 (69%) have reported using login systems as a key component of their eidm strategy (one more than during the 2007 study), with 28 systems in total being reported (+1 compared to 2007). Most of these (20) were single factor username/password systems; the others were multifactor systems relying on password lists (7 systems), password calculators (2 systems, in each case bank authentication systems); and mobile phone based authentication systems (2 countries; this excludes countries where mobile phones are used and presented as an electronic signature solution, rather than an electronic authentication solution. To classify the reliability of these systems, some countries have adopted authentication policies defining specific levels of reliability. In 18 out of 32 countries (56%) some form of multilevel authentication policy can be recognised (+3 compared to 2007). This could be indicative of an increasing professionalization/consolidation of eid infrastructures, as it shows that more countries are becoming aware of the need to differentiate between existing eid solutions on a transparent and consistent basis. However, the number of formally adopted authentication policies remains very limited, being in place in only 5 out of 32 countries. The practical impact of authentication policies has been relatively limited thus far. It is worth noting that all authentication policies are currently focused on nationally available solutions, with only one country Estonia noting its ambitions to launch a project to develop assessment methods and criteria for assessing different eids, including foreign ones, likely through a formalised system of authentication levels. Page 6 of 228

Mandate management and authorisations The study also showed that a systematic approach to mandate management and authorisation functionality i.e. the ability to allocate, retract or verify specific permissions of a specific entity - in the examined eidm systems was still altogether rare. 22 countries out of 32 (69%) have no form of mandate/authorisation management, other than the allocation of certificates or credentials to the representatives of a specific legal entity. 8 countries out of 32 (25%) have implemented an ad hoc form of mandate/authorisation management covering specific applications or service types; and only two countries have implemented systems of mandate/authorisation management which can be characterised as systematic: in Austria, an open approach to mandates based on signed XML records was adopted, and Belgium is currently implementing a systematic approach to managing authorisations. It should be noted however that both the Austrian and Belgian systems are operational, but are only taken up to a limited extent in egovernment applications at this stage. Legal/policy analysis One of the main questions of the questionnaire was whether or not the surveyed country had any specific legal framework with regard to entity authentication. The underlying goal of this question was the identification of any legal definition of the concept of an identity, and more importantly, how an identity can be established in an electronic environment. It was generally expected that most countries would not have explicitly addressed this issue through regulatory initiatives, and this appears to be correct: only in Austria is the concept of identification legally defined. In addition, the Finnish report noted that a new Act on Electronic Authentication and Signatures was expected to be passed by the Parliament in September 2009. Other than these examples however, the regulatory frameworks generally only referenced electronic identification indirectly, including notably via esignatures regulations; regulations in relation to available infrastructure (electronic identity cards and official registers, most notably); and regulations which reference any national authentication policies. As noted above, such policies are rarely elevated to more than nonbinding policy statements. However, their main appeal lies in the possibility of generalisation to abstract norms, allowing each common European eidm solution to be given an authentication level classification. As a final stage, applications could then request the use of specific authentication levels, rather than specific authentication solutions. It is worth noting that the Estonian report indicated the intention to launch a project to develop assessment methods and criteria for assessing different eids, including foreign ones, likely through a formalised system of authentication levels. Similarly, the Austrian egovernment Act already provides for the option of recognising the equivalence of foreign eid solutions based on qualified electronic signatures, and in Estonia plans exist to explore this possibility to create a policy for accepting foreign qualified certificates both for authentication and for digital signing. Thus, at least in some countries, there is a strong support for exploring the interoperability potential of qualified signatures for authentication functionality as well. Technical/infrastructural analysis The study examined the current level of technical eid infrastructures in the surveyed countries. The main focus of the study was to build a complete picture of the used eid infrastructure. This was achieved by layering eid infrastructure into three main layers. The first examined layer was the user (citizen) and how he/she is affected by the surveyed country eid infrastructure, including the implications of the citizen aspect for interoperability in general. The citizen aspect needed to answer both local user (user accessing services from home country) challenges and visiting citizen (user accessing services from another county) challenges. The received responses (as examined in section 4.6) indicated that no common specification exists for tokens and application middlewares. The study showed that hardware tokens were not specified in 19 countries out of 32 (59.5%) and middleware applications were not specified in 20 countries out of 32 (62.5%), apart from the fact that some of the surveyed countries had specified which type of tokens (in Page 7 of 228

some cases other that hardware based) and middleware applications were accepted in the country. Only few of the surveyed countries had specified their tokens with a deep and strict set of standards. The second examined layer was the actual operational layer, in which identity provider and service provider play the key role. The operational layer needed to answer what forms of electronic identities are used in the surveyed countries and how these are controlled and managed. This layer also needed to answer which types of services are used with electronic identities. The received responses (as examined in section 4.6. indicated that 28 countries out of 32 (87.5%) are either using or planning to use some sort of certificate based identities. Only 4 out of 32 (12.5%) have no close future plans to integrate certificates into their national identity infrastructure. The other examined section in operational layer were the real egovernment applications used in the surveyed countries, and this survey also confirmed the popularity of the certificate based solutions. The national infrastructure tables showed high numbers of PKI based egovernment applications. 22 (68%) of the 32 surveyed countries have implemented some level of certificate based authentications into their egovernment services and only 7 of the surveyed countries did not have any specific egovernment applications to present (it should be taken into account that there is an obvious uncertainty in this figure, because deployment in this area is rapid). The third examined layer was the back-office layer, in which industrial identity management standards play the key role. The correspondences were asked, which of the recognised (previously studied in other reports of this project) industrial identity standards were used (if any). The received responses (as examined in section 4.7.1.1) indicated that in the area of the industrial identity management standards the surveyed countries have still lot to do. It should also be noted that because of the complexity of such systems there could be some implemented and selected standards which were not reported by the correspondents. The study showed that only 9 countries out of the 32 (28%) had selected some of the specified standards; the main finding is thus that 23 out of the 32 (72%) did not have any expressed preference for specific industrial standards. The only standard showing some popularity between the surveyed countries was SAML, as the study indicated that 7 out of the 32 (22%) preferred SAML as a protocol). eidm in ehealth and ejustice applications At the application level, the country profiles also examined the maturity of eid solutions in two specific application fields, namely ehealth and ejustice. With respect to ehealth, 18 operational applications were reported in 16 countries. 10 of these related to the general ehealth eid infrastructure, reusable across a number of ehealth application fields; 2 reported on predominantly social security/administrative applications; and 6 reported specific applications (typically applications allowing the management of and access to electronic health records). Looking at the authentication means reported in these 16 countries, hard crypto tokens are the predominant form of electronic authentication, being reported in 11 out of 16 countries. Obviously, the availability of ehealth cards or health care professional cards is a strong enabler in this respect, as is e.g. the case for Croatia (CIHI card), Germany (EGK and HBA card), Italy (EIC and NSC card), and the Netherlands (UZI-card). These cards serve to determine the capacity of the signatory (e.g. the UZIcard is only available to health care professionals registered in the Dutch UZI-Register), meaning that interoperability is much harder to achieve in this field. Soft crypto tokens are significantly less common, being used in three countries. In relation to ejustice, 14 operational applications in 13 countries were reported, 6 of which related to court proceedings and court administration; 3 related to the establishment and management of companies; and 5 related to authentic document archiving services. Here too, hard crypto tokens were again the predominant form of electronic authentication, being reported in 8 out of 12 countries. Page 8 of 228

Main findings with regard to the impact on eid interoperability Legal/policy findings As noted above, while specific regulations exist that refer to the need to identify a specific entity (such as the national transpositions of the e-signatures Directive) or that prescribe which documents and registers are kept to identify specific entities (such as laws with regard to identity cards, national numbers, national registers etc.), the concepts of identity, identification and authentication as defined for the purposes of this study have remained largely unregulated in most countries. From a crossborder perspective, this means that a number of fundamental building blocks are missing, including notably a consensus on which types of information could be used to establish or corroborate an identity, and how the reliability of identity infrastructures could be determined. Electronic signatures can fill this void to some extent. An examination of national authentication policies shows that a number of countries indicate that the concept of a qualified signature is considered to be the highest level of authentication, with anything else being considered a lower level. Thus, the status of a qualified certificate is also used de facto as a quality label in an authentication context. As the concept of a qualified certificate is a European one, at least this top level of an authentication policy could be applied in a cross border context to establish trust. However, it should not be overlooked that the esignatures Directive itself does not directly address entity authentication: while e-signatures can be used as a tool for entity authentication, the more fundamental question of how an entity is identified is not resolved. This also implies that there is no clear national concept of electronic identity in most countries, nor a European one. None the less, a common European interpretation on the semantics behind the concept of electronic identity is necessary, if only to ensure that a consistent set of identity information can be exchanged when needed and permissible. Without this, at a minimum for legal persons and natural persons, application owners are forced to decide on a case by case basis which information they need, and how they should interpret the information they received. One of the key remaining interoperability barriers is the cross border use of protected unique identifiers for electronic identity management. Several countries actively oppose the use of generic and nonsector specific identification numbers for natural persons, including e.g. Germany and Hungary (which both oppose generic identity numbers on constitutional grounds), or only permit the use of such identifiers in specific authorised contexts, which never include cross border use cases. This is also one of the key problems currently being explored in STORK: how can users be uniquely identified, other than by relying on national identity numbers which may not be re-usable at the cross border level for legal reasons? Several options are being explored at the present stage, but it is not yet clear how these will be used in practice. This is one of the open issues which will also be explored in the remainder of this study, including possibly through the drafting of a Memorandum of Understanding. A second remaining challenge is the fact that a country offering an authentication mechanism must offer sufficient guarantees that the information that its system provides is correct and reliable. Currently, this is not always the case, neither in relation to unique identifiers (where accidental double allocations of one number to two different entities are rare, but not completely unheard of) nor in relation to identity databases (where duplicate/incorrect data is still occasionally observed). This is a particularly thorny issue in the field of identity management in a cross border perspective: regardless of the authentication solution being used (smart card, username/password, two factor,...), there must be some form of legal guarantee with regard to the accuracy of the identity information being provided through the system. This implies that a European level authentication assurance policy is needed, and that national identity infrastructures must be ensured to be sufficiently reliable. These are also questions that are currently also being explored in the STORK project, via the definition of a Quality Authentication Assurance scheme that can be used to classify national identification solutions. In addition, STORK is assessing to what extent national assurances are needed in relation to Page 9 of 228

the national components of a cross border identity infrastructure, and how these can be formalised (e.g. via supervision or accreditation processes)? Finally, cross border eidm requires that sufficient safeguards should be built in to ensure that the identity attributes of natural persons remain under their control as far as possible; i.e. the data subject remains the data owner, and he/she alone can decide to give her identity attributes in stewardship to private sector users. In practical terms however, this is extremely challenging at the cross border level, since all existing challenges that already exist at the national level remain (including lack of knowledge and awareness with participants in the systems), and new challenges are added (including language barriers when attempting to obtain informed consent from an end user for an authentication process and the possible clash between national legal regimes). These issues are being explored in the context of the STORK project as well, and will also be a part of the remaining work planned for the present study. Technical/infrastructural findings During the previous study the technical survey we sent to the correspondents followed a three layered approach to pan-european identity management architecture. These layers were the citizen layer, the operational layer and the back-office layer. So the presented questions and impact of the analysis result will be presented using same approach. On the citizen layer the most challenging question is achieving true interoperability on the citizen token, the citizen identity and the middleware levels, as analysis shows that the underlying technical framework around the citizen layer is incomplete. A consensus should be reached on the hard token level, since this is the token model gaining the most popularity around the surveyed countries, but the current implementations are not interoperable. There are two possible solutions for this problem. A commonly agreed hard token standard should be used, specifically in countries which are implementing new eid schemes (i.e. harmonisation of new solutions). The second challenge is to build interoperability around the already implemented eid schemes (i.e. creating interoperability between existing solutions). As the analysis shows there already has been some effort to create interoperability between the surveyed countries around the middleware application layer. These effort should be studied and more focus and pressure should be put on already existing European level standards, both on middleware and on tokens. From the operational layer the analysis shows that there is currently a high variety of authentication methods in use. This was noticed already in previous (year 2007) study and due to that a authentication policy model was created. The resulting pan-european interoperable authentication mechanism should support all variations of authentication methods, more focus should be put on introducing this authentication level model to Member States. It is clear that there is a real need on a common concept of authentication levels. These levels should indicate that citizens will be able to access different egovernment services based on the security level of their authentication mechanism. On this study we can see that this is still a valid question, it is true that more countries are selecting the certificate based authentication, but we can also see that this is not happening in all countries. Instead some of the countries have tightened their internal implementation around their own token type. A consensus must be reached on how to connect different eid and token approaches. The analysis shows that two different eid approaches are used. A pan-european eid system needs to connect both decentralized and centralized approaches. Thus as the centralized model becomes more popular in Member States, it becomes more important to find ways of making single authentication point solutions (gateway models) available in each country. Connecting countries with decentralized approaches that do not have any (federated) singe authentication point solutions available will require more complicated trust structures at the European level as well. At the same time guidance for best practices needs to be built. In respect of interoperability it is important to have a common pan-european solution to suggest to the countries currently without any eid infrastructure. Page 10 of 228

On the back-office layer the analysis shows that there is no commonly agreed direction for industrial identity management standards. As described above, the survey shows that only few of the surveyed countries have selected any of the many available standards. The lack of commonly agreed tokens and eidm profiles is challenging. A common structure of tokens needs to be drafted during the ongoing projects. In some cases transformation services might still be required on a gateway level, so that current or future usage of other standards can be supported. Finally, it is essential to include future infrastructural plans of Member States within a European Level identity Management scheme. It is important to create a basic proof of concept, an informational model for Member States how European level interoperable system can be built, and to specify a set of rules that evolving Member States should take into account what developing their identity frameworks so that interoperability would be realized in the most efficient manner and require a minimum level of additional development. Semantic interoperability needs to be achieved. Member States need to commonly agree on a set of rules on how eid schemes are developed. System interoperability in communication and syntax of transmitted data needs to be stable. Once achieved, the interoperability in the exchange of data should not be adversely affected by evolutions of one Member State s eid infrastructure. Page 11 of 228

Table of Contents EXECUTIVE SUMMARY 5 1 DOCUMENTS 14 1.1 APPLICABLE DOCUMENTS 14 1.2 REFERENCE DOCUMENTS 14 2 GLOSSARY 16 2.1 DEFINITIONS 16 2.2 ACRONYMS 18 3 INTRODUCTION 19 3.1 SCOPE AND OBJECTIVES OF THE PROJECT 19 3.2 GENERAL STRUCTURE OF THE PROJECT 19 3.3 GOAL OF THIS DOCUMENT 20 4 ANALYSIS 22 4.1 IDENTIFIED NATIONAL IDENTITY RESOURCES 22 4.1.1 IDENTITY TOKENS 23 4.1.2 NATIONAL IDENTIFIERS 46 4.1.3 IDENTITY REGISTERS 62 4.1.4 BIOMETRICS 74 4.1.5 MOBILE PHONE BASED IDENTIFICATION 77 4.2 AUTHENTIC SOURCE PRINCIPLE 81 4.3 AUTHENTICATION SECURITY EXISTING SYSTEMS AND POLICIES 85 4.3.1 AUTHENTICATION POLICIES 85 4.3.2 PKI BASED SYSTEMS 90 4.3.3 NON-PKI SYSTEMS 96 4.4 MANDATE MANAGEMENT AND AUTHORISATIONS 101 4.5 LEGAL / POLICY ANALYSIS 106 4.5.1 THE EUROPEAN LEGAL FRAMEWORK 107 4.5.2 NATIONAL REGULATORY APPROACH MODELS 118 4.5.3 PRIVACY ISSUES 123 4.5.4 AUTHENTICATION LEVELS: REGULATIONS AND POLICIES 130 4.6 E-GOVERNMENT APPLICATIONS USING EIDM 136 4.6.1 INTRODUCTION POSSIBLE AUTHENTICATION METHODS IN APPLICATIONS 136 4.6.2 EHEALTH APPLICATIONS 137 4.6.3 EJUSTICE 146 Page 12 of 228

4.7 TECHNICAL / INFRASTRUCTURAL ANALYSIS 154 4.7.1 COMMONLY USED TOKENS 154 4.7.2 AUTHENTICATION SYSTEMS (EIDM APPLICATIONS) 171 4.7.3 INTERNATIONAL INTEROPERABILITY APPROACHES 194 4.7.4 ADOPTED INDUSTRIAL STANDARDS 203 5 IMPACT ASSESSMENT 210 5.1 INTRODUCTION 210 5.2 IDENTIFIED INTEROPERABILITY ISSUES 210 5.2.1 AT THE LEGAL/POLICY LEVEL 210 5.2.2 AT THE TECHNICAL LEVEL 224 Page 13 of 228

1 Documents 1.1 Applicable Documents [AD1] Framework Contract ENTR/05/58-SECURITY 1.2 Reference Documents [RD1] [RD2] [RD3] [RD4] [RD5] [RD6] [RD7] [RD8] [RD9] egovernment in the Member States of the European Union 5th Edition May 2006 http://ec.europa.eu/idabc/servlets/doc?id=24769 European Electronic Signatures Study http://www.law.kuleuven.ac.be/icri/itl/es_archive.php?where=itl Decision 2003/511/EC of 14 July 2003 on the publication of reference numbers of generally recognised standards for electronic signature products in accordance with Directive 1999/93/EC of the European Parliament and of the Council, OJ L 175, 15.7.2003, p.45 IDABC Study on eid Interoperability for PEGS http://ec.europa.eu/idabc/en/document/6484 DIRECTIVE 2004/18/EC OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 31 March 2004 on the coordination of procedures for the award of public works contracts, public supply contracts and public service contracts DIRECTIVE 2004/17/EC OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 31 March 2004 coordinating the procurement procedures of entities operating in the water, energy, transport and postal services sectors DIRECTIVE 1999/93/EC OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 13 December 1999 on a Community framework for electronic signatures http://eurlex.europa.eu/lexuriserv/lexuriserv.do?uri=celex:31999l0093:en:not http://eurlex.europa.eu/lexuriserv/lexuriserv.do?uri=oj:l:2003:175:0045:0046:en:pdf http://eurlex.europa.eu/lexuriserv/lexuriserv.do?uri=celex:32004l0018:en:not http://eurlex.europa.eu/lexuriserv/lexuriserv.do?uri=celex:32004l0017:en:not IDABC Work programme 2005-2009 (sixth revision) http://ec.europa.eu/idabc/servlets/doc?id=32115 CROBIES study http://ec.europa.eu/information_society/policy/esignature (expected to be published by 1 Page 14 of 228

November 2009) Page 15 of 228

2 Glossary 2.1 Definitions 1 In the course of this report, a number of key notions are frequently referred to. To avoid any ambiguity, the following definitions apply to these notions and should also be used by the correspondents. o Entity: anyone or anything that is characterised through the measurement of its attributes in an eidm system. This includes natural persons, legal persons and associations without legal personality; it includes both nationals and non-nationals of any given country. o Identity: the dynamic collection of all of a single entity s attributes; by definition, an entity has only one identity. o Electronic identity or eid: an electronic representation of a certain subset of one or more attributes pertaining to an entity. While an entity has only one identity, it may have many electronic identities. It should be noted that eids can take many forms, and can be stored on many different types of media. An electronic identity or eid is not synonymous with an eid card: an eid card is only one of many tokens that can be used to support an eid. o eidm system: the organisational and technical infrastructure used for the definition, designation and administration of identity attributes of entities. This Profile will only elaborate on eidm systems that are considered a key part of the national eidm strategy. Decentralised solutions (state/region/province/commune ) can be included in the scope of this Profile if they are considered a key part of the national eidm strategy. o eidm token (or token ): any hardware or software or combination thereof that contains credentials, i.e. information attesting to the integrity of identity attributes. Examples include smart cards/usb sticks/cell phones containing PKI certificates, o Authentication: the corroboration of the claimed identity of an entity and a set of its observed attributes. (i.e. the notion is used as a synonym of entity authentication ). o Authorisation: the process of determining, by evaluation of applicable permissions, whether an authenticated entity is allowed to have access to a particular resource. o Unique identifiers: an attribute or a set of attributes of an entity which uniquely identifies the entity within a certain context. Examples may include national numbers, certificate numbers, etc. 1 Based on the Modinis Common Terminological Framework for Interoperable Electronic Identity Management; see https://www.cosic.esat.kuleuven.be/modinis-idm/glossary/ Page 16 of 228

o Official registers: data collections held and maintained by public authorities, in which the identity attributes of a clearly defined subset of entities is managed, and to which a particular legal of factual trust is attached (i.e. which are generally assumed to be correct). This includes National Registers, tax registers, company registers, etc. o egovernment application: any interactive public service using electronic means which is offered entirely or partially by or on the authority of a public administration, for the mutual benefit of the end user (which may include citizens, legal persons and/or other administrations) and the public administration. Any form of electronic service (including stand-alone software, web applications, and proprietary interfaces offered locally (e.g. at a local office counter using an electronic device)) can be considered an egovernment application, provided that a certain degree of interactivity is included. Interactivity requires that a transaction between the parties must be involved; one-way communication by a public administration (such as the publication of standardised forms on a website) does not suffice. o esignature: data in electronic form which are attached to or logically associated with other electronic data and which serve as a method of authentication with regard to this data, as defined in the esignatures Directive 2. o Advanced electronic signature: an electronic signature which meets the following requirements, as defined in the esignatures Directive: (a) it is uniquely linked to the signatory; (b) it is capable of identifying the signatory; (c) it is created using means that the signatory can maintain under his sole control; and (d) it is linked to the data to which it relates in such a manner that any subsequent change of the data is detectable; o Qualified electronic signature: advanced electronic signatures which are based on a qualified certificate and which are created by a secure-signature-creation device, as defined in the esignatures Directive. o Validation: the corroboration of whether an esignature was valid at the time of signing. 2 See http://eur-lex.europa.eu/lexuriserv/lexuriserv.do?uri=celex:31999l0093:en:html Page 17 of 228

2.2 Acronyms A2A...Administration to Administration A2B... Administration to Businesses A2C... Administration to Citizens CA... Certification Authority CRL...Certificate Revocation Lists CSP...Certificate Service Provider eid...electronic Identity eidm...electronic Identity Management IAM...Identity and Authentication Management IDM...Identity Management OCSP...Online Certificate Status Protocol OTP...One-Time Password PEGS...Pan-European egovernment Services PKCS...Public-Key Cryptography Standards PKI...Public Key Infrastructure SA... Supervision Authority SOAP... Simple Object Access Protocol SCVP...Server-based Certificate Validation Protocol SSCD...Secure Signature Creation Device USB... Universal Serial Bus TTP...Trusted Third Party XAdES... XML Advanced Electronic Signature XML... extensible Markup Language XML-DSIG... XML Digital Signature Page 18 of 228

3 Introduction 3.1 Scope and objectives of the study The current study entitled eid Interoperability for PEGS: Update of Country Profiles aims to collect information on eid practices and developments in the Member States, EEA countries and the candidate countries Turkey and Croatia, with a view of comparatively analysing these and providing specific inputs on quick wins that these countries could implement to establish a certain degree of interoperability. As the name indicates, the project builds on the information collected in the 2007 IDABC study on eid Interoperability for PEGS, in which similar information was collected. The current study aims to update that information, and to add specific new information, including specifically on authorisation/mandate management solutions, mobile identification, and eid in ehealth/ejustice applications. 3.2 General methodology of the study As with the 2007 edition, the current update study consists of 3 different phases. In a first stage comparable country profiles for each country were collected and validated. These should describe the main egovernment policies and ambitions in relation to electronic identity management, and will serve as the input for further analysis. These country profiles were collected and validated as a part of WP1 of this study, and have been published on-line at http://ec.europa.eu/idabc/en/document/6484. Secondly, the profiles must be analysed and assessed, to determine any patterns in the national approaches and to derive a set of constraints with regard to electronic identity management for egovernment applications. This aspect is dealt with by the current report, which is an update of the comparable 2007 report. Finally, based on the first two phases, the study team will try to identify and describe any quick wins that could be taken up at the national level, and will try to draft an MoU that Member States could adopt to improve cross border acceptance of eid tokens/resources. Efforts in relevant projects (including specifically the STORK project) and any barriers identified therein will be considered to ensure the effectiveness and impact of this work. Of course, reports such as these are only possible through the assistance of local experts who are capable and willing of providing information with regard to their legal frameworks and administrative practices. The Study team especially wants to acknowledge the contributions of the following authors for each of the country profiles: E.U. Member States Profile draft Country Author(s) date (date of receipt or last update) Austria Herbert Leitold (A-SIT) 14/05/2009 Belgium Prof. Jos Dumortier and Hans Graux (time.lex Law Offices) 01/09/2009 Bulgaria George Dimitrov (Dimitrov, Petrov & Co Law Offices) 16/05/2009 Cyprus Olga Georgiades (Lexact Business & Legal Solutions) 11/05/2009 Czech Republic Lucie Urbanova (Ministry of Interior, Czech Republic) 15/05/2009 Page 19 of 228

Denmark Dr. Henrik Udsen (University of Kopenhagen) 09/09/2009 Estonia Tarvi Martens (AS Sertifitseerimiskeskus) 15/05/2009 Finland Teemu Rissanen (Conseils Oy) 14/05/2009 France Fanny Coudert (time.lex Law Offices) 01/09/2009 Hajo Bickenbach (2B Advice GmbH) and Jörg Apitzsch (bremen 11/06/2009 Germany online services GmbH & Co. KG) Greece Eleni Kosta (time.lex Law Offices) 18/05/2009 Mr. Tibor Szabó (Hungarian Senior State Secretariat for 22/06/2009 Hungary Infocommunication) Profs. Maeve McDonagh and Fidelma White (University College 20/05/2009 Ireland Cork) Italy Davide M. Parrilli (time.lex Law Offices) 1/09/2009 Latvia Agris Repss and Inese Rendeniece (Sorainen Law Offices) 22/05/2009 Sergejs Trofimovs and Renata Beržanskienė (Sorainen Law 10/12/2009 Lithuania Offices) Luxemburg Claire Léonelli (Molitor, Fisch & Associés Law Offices) 15/05/2009 Malta Paul Gonzi and Antonio Ghio (Fenech and Fenech Law Offices) 27/05/2009 The Netherlands Dr. Nathan Ducastel (HEC Het Expertise Centrum) 20/05/2009 Poland Marcin Kalinowski (Unizeto) 25/08/2009 Portugal Pedro Simões Dias 14/05/2009 Romania Peter Buzescu (Buzescu Ca. Law Offices) 18/05/2009 Slovakia Zuzana Halasova 01/09/2009 Alenka Zuzek (Dr. Alenka Zuzek Nemec, Dept. of International 12/09/2009 Slovenia Relations, Ministry of Public Administration) Spain Cristina De Lorenzo (Sánchez Pintado & Núñez) 31/07/2009 Prof. Christine Kirchberger (Swedish Law and Informatics 19/05/2009 Sweden Research Institute, University of Stockholm) United Kingdom Richard Trevorah (xidm Limited) 15/05/2009 EEA Country Author(s) Iceland Haraldur A Bjarnason (Ministry of Finance) 19/05/2009 Norbert Ospelt ( IT-Technology, IT-Security, EU/EEA" Unit, 24/08/2009 Liechtenstein Information Technology Service, Office of Human and Administration Resources) and Hans Graux (time.lex Law Offices) Norway Thomas Myhr (Norwegian Broadcasting Corporation (NRK)) 02/09/2009 Candidate countries Country Author(s) Croatia Dr. Leda Lepri (Central State Office for Administration) 13/05/2009 Turkey Prof. Leyla Keser (Istanbul Bilgi University) and Ilhan Hatipoglu ( Turkish General Directorate of Civil Registration and Nationality - Department of Data Processing) 30/10/2009 3.3 Goal of this document This document ( Analysis and Assessment of similarities and differences ) concerns the second phase outlined above. Apart from the general introduction, this report entails two main sections: Page 20 of 228

Section 4: Report on analysis and assessment of similarities and differences. Based on the information in the country profiles, this section will analyse the similarities and differences in the planned eid schemes in each country both with regard to the legal framework, and on the technical implementation aspects. This analysis will identify any common trends, approaches or strategies in deploying eidm solutions on a national scale. Section 5: Report on impact on eid interoperability. This section contains an impact assessment of the similarities and differences, along with potential issues in relation to interoperability of eid solutions and hence of the supported egovernment applications. Page 21 of 228

4 Analysis 4.1 Identified National Identity Resources In this first section of the analysis report, we will describe the identity resources (both electronic and traditional) commonly used for the purposes of identity management in each of the surveyed countries. The main purpose of this section is to illustrate the resources that the countries have at their disposal to create and maintain eidm systems. Both electronic and non-electronic solutions have been included in this overview, since the Study is not merely concerned with current solutions, but also with future possibilities. For this reason, it is important to know what the main components of a country s identity infrastructure are (including identity cards, national registers, etc.), even if these are not (yet) being used in an electronic context. In order to determine the use of such resources for European interoperability purposes, any doubts or reservations expressed by the correspondents with regard to any particular resource have also been noted in the tables below (usually in the Status column). It should be noted that the correspondents were asked to report the main means of identification (electronic or otherwise) being used in their countries. The tables below are therefore not necessarily exhaustive; however, all identification means which form a substantial part of a country s electronic identification plans are included. Five different categories of identity resources will be examined in the section below: Section 4.1.1: identity tokens, i.e. eidm tokens as defined in the glossary above which are made available to the end users (natural persons and/or business) for the purpose of identifying or authenticating them towards an egovernment application; Section 4.1.2: national identifiers, i.e. unique identifiers as defined in the glossary above which are used to identify an entity in a specific egovernment context; Section 4.1.3: identity registers, i.e. official registers as defined in the glossary above which contain specific attributes in relation to specific entities; Section 4.1.4: biometrics, i.e. an analysis of the extent to which biometric identification/authentication tools are being used in egovernment applications (other than the mandatory biometric passports); Section 4.1.5: mobile phone based identification, i.e. an analysis of the extent to which mobile phone based identification/authentication tools are being used in egovernment applications. In each section, we will provide a summary overview, along with preliminary conclusions on key trends and observations. Page 22 of 228

4.1.1 Identity Tokens This section will describe which identity tokens (if any) are commonly distributed to entities in the surveyed countries. As defined above, tokens include any hardware or software or combination thereof that contains credentials, i.e. information attesting to the integrity of identity attributes. Apart from identity cards, examples can thus include USB sticks or cell phones containing PKI certificates, or the certificates themselves. Each of these will be examined separately in the section below. 4.1.1.1 Traditional (paper based) cards This section provides an overview of paper card tokens without electronic token functionality (i.e. plain paper cards without smart card functionality that makes it suitably for electronic identification/authentication in egovernment applications) being used in the surveyed countries. Specifically, the overview reports: Any government issued national ID cards in use. If the card is being replaced or is planned to be replaced by an electronic ID card, this is reported in the Status column; with further details provided in section 4.1.1.2. below); Any other paper cards which are not generic ID cards and contain no chip or electronic component, but which are none the less used for electronic authentication. Specifically this includes paper cards with codes printed on them for the purposes of two factor authentication (password lists). It should be noted that these can also be issued by private sector entities. The overview does not include smart cards (section 4.1.1.2.), sector specific tokens (section 4.1.1.4.), user group specific tokens (section 4.1.1.5.); or paper cards that are not used for electronic authentication in egovernment applications (such as chipless drivers licenses, social security cards, etc.). The main purpose of this table is to determine which countries issue identity cards (and might therefore show a smaller socio-cultural barrier to introducing electronic ID cards as an authentication token, if they are not already doing so); and to determine to what extent that paper tokens are used as authentication tools in e-government applications. In the table below, changes in comparison to the 2007 edition of the study are marked in yellow. The following countries have been found to issue paper based identity cards (or other paper card types): Country Description User group Mandatory / Roll-out Status Belgium National ID card Belgians over the age of 12; nonnationals mandated to reside in Belgium Federal token (not an identity card) Persons with an ID card (see above) and SIS card (see below) Mandatory Optional Replacement by the eid card (see below) will be complete by the end of 2009. Similar cards exist for non-nationals, which are also being replaced by equivalent eid cards. Is being phased out in favour of the eid card Bulgaria National ID card Bulgarian nationals Mandatory Deployed. eid cards for Page 23 of 228

and natural persons with permanent residence in Bulgaria BULSTAT card Companies, nonprofit organisations, public institutions, other kinds of legal entities, branches of foreign company, and self-employed Croatia National ID card Croatian nationals over the age of 14 Cyprus National ID card Cyprus nationals and natural persons with permanent residence in Cyprus Czech Republic Estonia National ID card Czech nationals and natural persons with permanent residence in the Czech Republic Bank token (not an identity card) Finland Finnish Banker s Association paper token (TUPAS) France National ID card French citizens over the age of 16 (non-nationals receive a residence card) Germany Identity Card (Personalausweis) Mandatory (although holders may elect to receive an electronic BULSTAT card instead of a paper one). Mandatory natural persons are not yet planned. Holders may elect to receive an electronic BULSTAT card instead. Deployed. eid cards are planned for 2010. Mandatory Deployed. Smart cards 3 were traditionally deemed unlawful, but in March 2008 procedures were initiated to introduce eids / smart cards for public services. These plans are still in an early stage. Mandatory Deployed. New ID cards are proposed in the draft Act on ID cards. A new plastic ID card should replace current paper ID cards. This card will come into two versions a plastic card without chip and a smart card. 4 Banking customers Optional Currently used more frequently than the eid card in a number of egovernment applications; public policy favours the eid card in the future Banking customers Optional Currently used more frequently than the eid card. German citizens over the age of 16 Optional Mandatory Scheduled to be replaced by an eid card Scheduled to be replaced by an eid card in November 2010 (delayed by 1.5 years) Greece National ID card Greek citizens over Mandatory Deployed. No specific 3 In March 2008, the Cyprus Government has initiated the procedures to introduce electronic identification/authentication (eid, smart cards) for public services in order to realize seamless access to public services across borders. 4 It hasn't been decided yet what will be stored on a chip of a smart card version of the ID card. Page 24 of 228

the age of 12 Hungary National ID card Any person in the population register over the age of 14 Personal identification and address certificate Any person in the population register over the age of 14 Iceland National ID card Any person in the population register over the age of 14 Italy National ID card Italian citizens over the age of 15; foreigners mandated to reside in Italy Liechtenstein National eid card Liechtenstein citizens Lithuania National ID card Lithuanian citizens over the age of 16 Luxembourg National ID card Luxembourg citizens over the age of 15 Malta National ID card Maltese citizens over the age of 14 The Netherlands National ID card Dutch citizens over the age of 14 Poland National ID card Polish citizens over the age of 18, or over the age of 15 if they are employed or legally independent Portugal National ID card Citizens over the age of 6 (and Brazilian citizens covered by the Treaty of Porto Seguro) Romania National ID card (Carte de identitate) Citizens over the age of 14 Slovakia National ID card Citizens over the age of 15 Slovenia National ID card Citizens over the age of 18 (or Optional plans for eid cards yet. Likely to be replaced by an eid card in the future. Optional Contains the personal identification number Mandatory Optional Optional Mandatory Deployed. Contains the SSN, which is the basis for identity management. Gradually being replaced by the eid card on a region by region basis (see below). Deployed on 23 June 2009 Currently being replaced by an eid card (since 1 January); see below. Mandatory Deployed. No specific plans for an eid card yet. Mandatory Optional (citizens must carry an identity document; but this may also be e.g. a passport or drivers license). Mandatory Mandatory Mandatory Mandatory Optional (citizens must carry an Planned to be replaced by the eid card. Plans to replace the card with an eid card are currently under (re- )consideration. Scheduled to be upgraded to an eid card by 2011. Gradually being replaced by an eid card since 14 February 2007. Scheduled to be replaced by an eid card from 2011. Planned to be replaced by an eid card. 5 Planned to be replaced by an eid card. 6 5 The chip will only be included if the person will apply for it. Otherwise they will receive only the polycarbonate card with data and a picture. Page 25 of 228

Spain National ID card ( Documento Nacional de Identidad, DNI ) younger if the parents apply for it) Spanish citizens over the age of 14 identity document; but this may also be e.g. a passport or drivers license). Mandatory Turkey National ID card Turkish citizens Mandatory Deployed UK National ID card All person over the age of 16 who is or wishes to be resident in the United Kingdom. Currently being replaced by the eid card. Optional For UK citizens, the intention is that the first identity cards will be issued in 2009. The table above shows that: Out of 32 countries, 24 have a paper token identified as a identity card; 17 of which are mandatory, and 7 of which are optional; Of the countries which have a paper identity card, 17 have decided to introduce electronic identity cards (eid cards): 6 of these are already issuing eid cards to the public (Belgium, Italy, Liechtenstein, Lithuania, Portugal and Spain); and 11 have scheduled to do so in the near future or are presently running pilots on a smaller scale. In addition, the introduction of an eid card is under consideration in the Netherlands, but without specific plans yet at the present stage. Finally, in 3 out of 32 countries, a paper card other than a national ID card plays a significant role in on-line authentication. Interestingly, in all of these countries (Belgium, Estonia, and Finland), smart cards are already available to the public. Additionally, in Estonia and Finland the popularity of the paper cards is reported to exceed those of the smart card. However, the examples of Belgium, Estonia and Finland illustrate that eid cards do not necessarily become the sole option for electronic authentication: while the Belgian eid card is intended to replace the paper token in the medium term, the timing for the phase-out for Estonia has not been determined, and no specific plans for eliminating the paper token have been identified for Finland. In comparison to the 2007 edition, some interesting developments can be noted: Since the previous edition, two countries have begun issuing eid cards: Liechtenstein and Lithuania both began issuing eid cards in the first half of 2009. For a number of countries (including Cyprus, the Czech Republic, Malta, Slovakia, Slovenia and the UK), plans for an eid card have moved forward significantly, although no cards are issued yet at the present stage. 6 In 2008 existing regulations were amended with provisions regarding introduction of an eid card enabling integration of an ID card, qualified certificates and a health insurance card. However, since the project was suspended these provisions aren t being used yet and it is anticipated that they will have to be changed if (when) the project continues because the project of introducing the new generation of health insurance cards continues independently. Page 26 of 228

The Portuguese eid card moved from issuing in a limited number of regions to a generalised availability across the Portuguese territory. Some delays were also noted, including in Germany, Romania and the Netherlands, with the former two delaying eid cards by a year or more, and the Netherlands reconsidering its eid plans altogether on the basis that private sector cooperation might prove to be a suitable and more cost effective approach. In Germany, a general concept for an eid card has been published in 2008. The ID Card Act (Personalausweisgesetz) containing all necessary legal changes has passed parliament in February 2009 and will be published soon. Pilots have been started, and issuance is expected to begin in 2010. Important note: this table cannot be used as a overview of eid cards in the surveyed countries. It only provides information with regard to eid cards for countries that are issuing national paper ID cards, and does not include countries such as e.g. Austria or Estonia where eid cards have fully replaced paper ID cards or where national ID cards were not issued to begin with, such as Denmark. Therefore, to assess the popularity of eid cards, section 4.1.1.2. directly below should be consulted, where a full overview and analysis of the ID card situation is provided. Page 27 of 228

4.1.1.2 Electronic identity cards In this section, we will take a closer look at electronic identity cards (i.e. smart cards, containing a chip or other electronic component that can be used for electronic authentication) being issued or considered in the surveyed countries. It should be noted that it is possible for a country to be present in section 4.1.1.1. directly above but not in section 4.1.1.2. (i.e. because it has no eid plans yet); and inversely that a country is in the table below but not above (i.e. because it has an eid card, but not a paper national identity card, such as Austria or Estonia). Additionally, it should be noted that the table below uses a broad notion of electronic eid card: it includes any eid card issued by public administrations, but also cases where the eid card was issued by a private CSP with a specific government mandate (e.g. in Luxembourg and Liechtenstein), or where smart cards can be activated to be used in egovernment applications though a decision from a governmental body (e.g. the Austrian Bürgerkarte can be issued by private sector parties, but it must be activated as a Bürgerkarte by a decision of the Austrian SourcePIN authority, which is part of the Austrian data protection authority). Finally, it should be noted that in a number of instances (e.g. in Hungary and Italy), the presented solution is not a specific smart card, but a series of standards that can be used to create compliant cards. In the case of Austria, the solution need not even be a card per se (although for the purposes of the table below, only smart cards are considered). The following countries have been found to issue electronic identity cards, or are planning to do so in the near future: Country Description User group Mandatory / Roll-out Austria Citizen Card (Bürgerkarte) note: the citizen card can also take other forms than a smart card; it is a concept (i.e. a series of norms that can be implemented as several possible tokens). Natural persons registered in Austria Belgium National eid card (BELPIC) Belgian citizens over the age of 12; nonnationals mandated to reside in Belgium Czech Republic Optional Mandatory National eid card Czech citizens Optional - non electronic and electronic cards will be made available, and each citizen can decide which one to use. Status Deployed. Note that the system relies on signature certificates in combination with unique identifiers. Deployed Planned. The Act on ID cards 328/1999 is in the draft phase. Croatia National eid card Citizens over 14 Mandatory Planned for 2010 Page 28 of 228

FINA eid card All businesses and natural persons Estonia National eid card Estonian citizens; foreigners residing permanently in Estonia Finland National eid card (FINEID) Finnish citizens and nonnationals registered in Finland. France National eid card (INES planned; not yet deployed) Germany Electronic Identity Card (Personalausweis) (planned for 2010; not yet deployed) Hungary National eid card (HUNEID). Note that this is a standard for smart cards, and can have any number of implementations (national ID card, health card, health practitioner card, ) Iceland National eid cards issued by private CSPs under a common root Ireland Public Service Card (planned; not yet deployed) Italy National eid card (carta d identità elettronica - CIE) French citizens (no age limit) German citizens over the age of 16 Natural persons registered in Hungary Natural persons having a SSN in Iceland To be decided; likely natural persons subject to Irish health care and social services Italian citizens and foreigners Optional Mandatory over the age of 15; optional below 15 Deployed, issued by the Croatian Financial Agency; contains two certificates: authentication and signature. Deployed; rollout complete Optional Deployed, but rarely used 7 Under consideration Design stage Mandatory Final design stage Depends on the implementation Design stage Optional Deployed, but limited uptake so far. To be decided Optional is A bidder was selected in June 2008; issuance will likely not begin before next year, subject to budgetary constraints. Deployed in a number of 7 In Finland the current plan is to change from smart card based eid to certificates stored on USBmemory devices. Page 29 of 228

Latvia National Service Card (CNS). Note that this is a specification for smart cards, mainly aiming to ensure interoperability, not a card in itself 8. National eid card (planned; not yet deployed) that have been authorised to reside in Italy of 15 years or older. Depends on the implementation, which is largely determined at the regional level Citizens that have reached the age of 15. Liechtenstein National eid card Citizens of Liechtenstein Lithuania National eid card Lithuanian citizens over 16 Luxembourg Malta The Netherlands Private sector smart cards (LuxTrust cards) National eid card (planned; not yet deployed) All natural and legal persons Maltese citizens over the age of 14 Depends on the implementation, which is largely determined at the regional level regions since 1 January 2006, but not yet universally available. Availability to foreigners is subject to local interpretation. Deployed. Conceived largely as a temporary solution until the CIE is universally available. Mandatory Design stage; introduction of eid cards is planned for the first half of 2010. 9 Optional Deployed on 23 June 2009 Mandatory Optional Mandatory National eid card (ENIK) Dutch citizens Optional (citizens must carry an identity document; but this may also be a passport or drivers license). Deployed since 1 January 2009 Deployed Design stage Under (re-) consideration 10. PKIoverheid certificates are qualified certificates issued on a SSCD with a 8 The main examples of NSCs are the SISS 8 project (Health card of Region Lombardy, with more than 9 million cards issued) and the NSC issued in the Region Friuli Venezia Giulia 8. 9 Was planned for the second half of the year 2008, but in the end of 2008, under a governmental action plan the Secretariat of Special Assignments Minister for Electronic Government Affairs was assigned to redraft the previous concept regarding eid Cards. 10 Plans for a Dutch eid card were set back when the procurement process for an eid solution was successfully challenged before a Dutch court, meaning that the procurement would need to be restarted. Since then, debates have reopened on the benefits of an eid card solution, and specifically whether an extended and more systematic use of the existing DigiD-scheme might not be a preferable option. Page 30 of 228

Certificates issued under the PKIoverheid (http://www.pkioverheid.nl/), trust infrastructure for CSPs which meet certain quality requirements. Norway National eid card Natural persons registered in Norway Poland Portugal National eid card (pl.id) (planned; not yet deployed) National eid Card (Cartão do Cidadão) public sector mandate and that can be used for egovernment applications. Currently four (private party) PKIoverheid certification service providers are operational. Unrestricted Optional Deployed Polish citizens over the age of 18, or over the age of 15 if they are employed or legally independent Portuguese citizens over the age of 6 (and Brazilian citizens covered by the Treaty of Porto Seguro) Romania National eid card Romanian citizens over the age of 15 Slovakia National eid card Slovakian citizens over the age of 15 Slovenia National eid card Slovenian citizens over the age of 15 Optional Mandatory Mandatory Planned. Regulation and technical specifications are presently being finalised. Design stages; will likely be issued around 2011 Nationally distributed since 14 February 2008; will be fully deployed in 2012. Mandatory Design stage; to be deployed in 2011 (changed from 2009. Optional (citizens will be allowed to choose the nonelectronic ID card) Mandatory Design stage; to be deployed in the end of 2009 (changed from 2008). Design stage. Page 31 of 228

Spain Sweden National eid card ( DNI electrónico or DNI-e ) Private sector smart cards containing authentication and signature certificates Electronic ID cards issued by companies selected in a government frame agreement procurement (can also be soft certificates) National Swedish identity card issued by the police (still not fully initiated for electronic use). Spanish citizens over the age of 14, and nonnationals that have been authorised to reside in Spain Natural and legal persons. Swedish citizen and others that have been introduced in the population register can get cards. Most issuers today are banks. Age limits can vary from issuer to issuer The National Swedish identity card can be acquired by any citizen eligible for a passport. Mandatory Optional Optional Optional Deployed; currently being rolled out. By the end of 2009, it is estimated that about 14,000,000 eid cards shall have been issued. Deployed Deployed Deployed Turkey National eid card To be decided To be decided Early study stages United Kingdom National eid card UK citizens and non-nationals planning to reside in the UK for more than three months. Voluntary, but under consideration to be made mandatory in the future. Final design stages; to be deployed in 2009 Page 32 of 228

Therefore, by linking the two tables above (paper identity cards and eid cards) together, the situation with regard to identity cards can be summarised as follows: Country Identity card Mandatory / Roll-out Austria eids issued by private CSPs (Citizen card concept) Optional Status Deployed (Bürgerkarte note: not necessarily in card form). Note that the system relies on signature certificates in combination with unique identifiers. Belgium National eid card Mandatory Deployed (BELPIC); replacement of the paper ID card will be complete by the end of 2009. Bulgaria National ID card Mandatory. Deployed. There is an electronic BULSTAT card for legal entities; but this is not commonly used; eid cards for natural persons are not yet planned. Croatia National ID card Mandatory Deployed. eid cards are planned for 2010. Certain public officials have access to user group specific smart cards. Cyprus National ID card Mandatory Deployed. Smart cards are under consideration for the future. Czech Republic National ID card Mandatory Deployed. New ID cards are proposed in the draft Act on ID cards. A new plastic ID card should replace current paper ID cards. This card will come into two versions a plastic card without chip and a smart card. 11 Denmark No ID card N.A. The OCES signature is used for electronic authentication system; however, this is not a smart card based system (and thus not an identity card) Estonia National eid card Mandatory Deployed; rollout is complete Finland National eid card Optional Deployed (FINEID), but rarely used France National ID card Optional Deployed. A national eid card (INES) is in its design stage but not yet deployed Germany National ID card Mandatory Deployed (Personalausweis). A national eid card is in its design stage but not yet deployed; planned for 2010. Greece National ID card Mandatory Deployed. No specific plans for an eid card yet. 11 It hasn't been decided yet what will be stored on a chip of a smart card version of the ID card. Page 33 of 228

Hungary National ID card Optional Deployed. A national eid card (HUNEID) is in its design stage but not yet deployed. Iceland eid cards issued by private CSPs under a common root Mandatory Deployed. The first eid cards issued by private CSPs under a common root have been issued. Ireland No ID card N.A. A Public Service Card is planned; but not yet deployed Italy National eid card Optional Deployed (CIE), but not systematically taken up yet. Latvia No ID card N.A. Introduction of eid cards is planned for the first half of the year 2010 Liechtenstein eid card issued by private CSPs (li.sign card) Optional Deployed on 23 June 2009 Lithuania National eid card Mandatory Deployed; the eid card is being issued as a replacement for the paper card since 1 January 2009. Luxembourg eid card issued by private CSPs (LuxTrust cards) Optional Deployed. Malta National ID card Mandatory Deployed. A national eid card is planned, but not yet deployed. The Netherlands National ID card Optional Deployed. A national eid card (ENIK) is currently under (re- )consideration. In addition, certificates from private CSPs issued under the PKIoverheid trust infrastructure act as eids in a substantial number of applications. Norway National eid card Optional Planned (was: under consideration). Regulation and technical specifications are presently being finalised. Poland National ID card Mandatory Deployed. A national eid card (pl.id) is in its design stage, and will likely be issued starting in 2011. Portugal National ID Card Mandatory Deployed. An eid card (Cartão do Cidadão) is currently being deployed nationally, and will be fully deployed in 2012. Romania National ID card Mandatory Deployed. A national eid card is in its early design stage but not yet deployed. Slovakia National ID card Mandatory Deployed. A national eid card is in its late design stage but not yet deployed. Page 34 of 228

Slovenia National ID card Optional Deployed. A national eid card is in its late design stage but not yet deployed. Spain National eid card Mandatory Deployed; the DNI electrónico or DNI-e is currently being rolled out. Sweden eid card issued by private CSPs Optional Deployed. Can also be soft certificates. Turkey National ID card Mandatory Deployed. An eid card is being considered for the future. United Kingdom No ID card. N.A. An eid card is in its final design stages; to be deployed in 2009. Based on this table, the following global conclusions can be drawn: Out of 32 countries, 27 issue identity cards (84%), including 6 which are eid cards issued by private CSPs with a public sector mandate (Austria, Iceland, Liechtenstein, Luxembourg, the Netherlands and Sweden). Out of these 27: o o o 3 are deploying paper ID cards, and have no specific plans for national eid cards: Bulgaria, Greece and the Netherlands. Advanced plans for an eid card (the so-called enik) were reported in the Netherlands in the previous edition of the study, but these are currently being reconsidered in favour of more extensive cooperation with private sector identity issuers. 13 are deploying paper ID cards, but have more or less concrete eid card plans for the near future: Croatia, Cyprus, Czech Republic, France, Germany, Hungary, Latvia, Malta, Poland, Romania, Slovakia, Slovenia and Turkey. 13 are deploying eid cards, including however the aforementioned group of six relying on eid cards issued by private CSPs with a public sector mandate (Austria, Iceland, Liechtenstein, Luxembourg, the Netherlands and Sweden); in the seven others eid cards are issued by public bodies (Belgium, Estonia, Finland, Italy, Lithuania, Portugal and Spain). There are thus 5 countries that currently do not issue identity cards: Denmark, Ireland, Latvia, Norway and the UK. As noted above however, plans to issue eid cards in some form exist in all but Denmark. In the UK and Latvia, these will likely take the form of government issued eid cards, and in Norway and Ireland private sector issued smart cards with a governmental mandate. Denmark traditionally relies on a combination of the social security card (sygesikringsbevis) and driver s license or passport or banking cards. In an electronic context, the authentication function is performed by the OCES electronic signature solution (a soft certificate solution; see below). While the OCES will be upgraded in the future, the use of smart cards is not currently envisaged in this respect. Thus, it is clear that identity cards are a dominant identification solution in the surveyed countries, being present in 84% of countries, with only Denmark not discussing their introduction in any form for the foreseeable future. It is clear that, while certainly not all-encompassing, eid cards will become increasingly common in the next few years. It is however also interesting to note the strong role that private sector issued eids are playing in this sphere. While paper based ID cards were always exclusively issued by public bodies, this is clearly no longer the case for eids, with six countries reporting a strong reliance on smart cards issued by private CSPs under more or less strong public sector supervision or control. Indeed, one could certainly Page 35 of 228

question whether these can/should be labelled as national eid cards, given the private sector involvement. However, for the purposes of the present study the debate is largely semantic: the relevant consideration is that the 13 identified eid card approaches are all issued with a public sector mandate, and are considered as sufficiently trustworthy for use in egovernment applications with higher security needs. In addition, it should be stressed that the distinction is frequently hard to make, as the management of a PKI infrastructure often requires specific expertise which is contracted from private sector bodies. For instance, when looking at the eid cards which are identified explicitly as national eid cards in the national reports, the Belgian report indicates that the CSP for the eid card is Certipost, a subsidiary of the Belgian Post, which is substantially privately held. Similarly, as noted in the Estonian report, the issuance process and development of PKI infrastructure is managed through a tight cooperation with public and private agencies. The production and personalization of ID-cards, as well as certification services are outsourced by service contracts to TRÜB AG. TRÜB AG has two subcontractors: AS Sertifitseerimiskeskus (hereinafter: SK) and Trüb Baltic AS. TRÜB AG as main contractor is producing ID-cards, which are then personalized by Trüb Baltic AS. SK, founded by two major Estonian banks Swedbank and SEB and two telecom companies Elion and EMT, functions as a certificate service provider and validation authority, and maintains the electronic infrastructure necessary for issuing and using the card, and develops the associated services and software. Similar considerations are true for most national eid cards ; thus, it seems that it is a valid approach to interpret this concept as covering any eid cards issued by public administrations, or by a private CSP with a specific government mandate or recognised as such though a decision from a governmental body. Page 36 of 228

Non-card tokens As noted above, tokens are not restricted to smart cards. Other tokens include PKI certificates in soft form or stored on another (non-card) physical carrier, such as a USB stick. Such solutions offer the benefit of greater flexibility. It should be noted that the table includes only solutions that have currently been deployed; not solutions that are planned/considered for the future (unlike the eid card table above). The following countries have been reported to issue non-card tokens for identification/authentication purposes: Country Description User group Mandatory / Roll-out Austria Citizen Card (Bürgerkarte), which can also take other forms than a smart card; it is a concept. Belgium Private sector soft signature certificates (qualified and nonqualified) Denmark OCES soft signature certificates Natural persons registered in Austria Natural and legal persons Natural persons registered in Denmark (i.e. with a Danish Central Personal identification number) Estonia Bank PIN calculators Banking customers Mobile PKI/Mobile-eID Lithuania Private sector issued qualified signature certificates (either on smart card of soft); and bank PIN calculators Luxembourg The LuxTrust Signing Stick (USB stick with two digital certificates) Poland Private sector issued qualified signature certificates (either on smart card of soft) Customers of the relevant mobile operators Natural and legal persons All natural and legal persons Natural persons (using the PESEL or NIP number for Status Optional Deployed. Note that the system relies on signature certificates in combination with unique identifiers. Optional Active use, but in a limited number of applications. Optional Deployed. Note that the system relies on signature certificates in combination with unique national identifiers. Optional Currently used a lot; public policy favours the eid card in the future Optional Deployed (see analysis of mobile identification in section 4.1.5. below) Optional Optional Optional Deployed. Deployed. Deployed. Page 37 of 228

Slovakia Private sector issued qualified signature certificates (either on smart card or other SSCD) Slovenia Spain Sweden Public and private sector issued qualified signature certificates (either soft or on a smart card) Public and private sector issued qualified signature certificates (either soft or on a smart card) Soft certificates issued by recognised private sector partners (today mostly banks). Issuance to mobile phone SIMcards about to start. Turkey Qualified signature certificates on smart cards issued by accredited CSPs United Kingdom Soft signature certificates from accredited CSPs identification) Natural persons Optional Deployed. Natural and legal persons Natural and legal persons Swedish citizen and others introduced in the population register. Uses the personal identity number for unique identification.. Optional Optional Optional Deployed Deployed Deployed Natural persons Optional Deployed Natural and legal persons Optional Deployed The table allows for some interesting conclusions: In 13 countries out of 32 (40%) the use of non-card tokens was reported. This is lower than might have been expected, given that such solutions can include the use of soft signature certificates, which have been reported to exist in 19 out of 32 countries in the related Update of the Preliminary Study on Mutual Recognition of esignatures for egovernment applications. However, this difference can be explained by (1) the fact that signatures are not by definition universally suitable as authentication mechanisms (see also sections 4.5.1.1.) which leads some correspondents to exclude them; and (2) the fact that CSPs often offer both authentication certificates and signature certificates, which will lead correspondents to report only the authentication certificate as the relevant solution for entity authentication. All reported solutions are purely voluntary. This is not particularly surprising, given that their use requires a certain degree of skill, or at least a willingness to use them, which renders them ill suited to mandatory issuing (contrary to an eid card, which is understandable and usable in a non-electronic context as well, on the basis of text printed on the card). All of these solutions are offered by private sector parties, albeit in one case (the Danish OCES) on the basis of an agreement with the government. Page 38 of 228

9 out of 13 solutions do not rely on residence, registration or establishment in a specific country, and are thus at least in theory open to use by non-nationals. Page 39 of 228

4.1.1.3 Sector/application specific eidm tokens Correspondents were asked to report all electronic authentication means that were considered to be key attributes for one or more eidm systems in the country. While this would exclude most sector/application specific systems/tokens/identifiers, a number of correspondents none the less reported the existence of such tokens as an important part of their national eid strategy. The following countries have been found to issue sector/application specific eidm tokens: Country Description User group Mandatory / Roll-out Austria A multitude of variations of Citizen Card (Bürgerkarte); including the health insurance card Belgium SIS card (social insurance card) Croatia CIHI health insurance card isprava 2 Denmark Social security card (sygesikringsbevis) Natural persons registered in Austria Natural persons subject to Belgian social security Natural persons subject to Croatian social security Natural persons subject to Danish social security France Vitale Card Any Social Security beneficiary older than 16 Germany Electronic Health Card (elektronische Gesundheitskarte - egk) Hungary Electronic Health Card Italy National Service Card (CNS). Note that this is a specification for smart cards, mainly Natural persons subject to German social security. Optional Mandatory Mandatory Mandatory Mandatory (but its use is optional; paper based forms are still possible) Mandatory Not yet determined Not yet determined Depends on the implementation Depends on the implementation Status Deployed. Note that the system relies on signature certificates in combination with unique identifiers. Deployed. Deployed. Deployed Deployed Pilot stage Design stage (The planned start of issuance is the end of 2009.) Deployed Page 40 of 228

Poland aiming to ensure interoperability, not a card in itself 12. Electronic Card for Health Insurance EKUZ Romania National Health Insurance Card (NHI card) Slovenia Health insurance cards Natural persons (patients) in the Silesian Voivodeship Department of National Health Fund Natural persons insured in the social health system of Romania Mandatory Mandatory Deployed Design stage; delayed since 2007. Entire population Mandatory Deployment stage (same project schedule with healthcare professional cards) Thus, all in all 11 solutions were reported, with only 7 being currently deployed, corresponding to a response rate of 22%. This limited response rate is likely indicative of the fact that sector/application specific tokens are generally not considered to be a key part of a government s eidm strategy. The main application case relates to social security and ehealth solutions, which account for 6 of the 7 deployed solution; with the remaining case being the Austrian Citizen Card (Bürgerkarte), which has a multitude of variations, including a health insurance card. 12 The main examples of NSCs are the SISS 12 project (Health card of Region Lombardy, with more than 9 million cards issued) and the NSC of Region Friuli Venezia Giulia 12. Page 41 of 228

4.1.1.4 User group specific eid tokens As with the preceding section, the fact that correspondents were asked to report only on those electronic authentication solutions that were considered to be key attributes for one or more eidm systems in the country excludes most user group specific systems/tokens/identifiers. None the less, a number of correspondents reported the existence of such tokens. The following countries have been found to issue user group specific tokens: Austria Country Description User group Mandatory / Roll-out Public servant card (which is a form of Citizen Card (Bürgerkarte); see above) Belgium Foreigners eid Card Finland France Germany Status Public servants Optional Deployed. Note that the system relies on signature certificates in combination with unique identifiers. Non-nationals who are not eligible for a national eid card Kids-ID (eid card) Children under 12 Healthcare professional cards (Valvira) Healthcare professional cards (Carte professionnelle de la Santé) Daily life card (Carte de la vie quotidienne) Healthcare professional cards Greece Syzefxis smart cards Health care professionals Health care professionals Users of services of local administrations (user group and identifiers may vary) Health care professionals Mandatory Optional Mandatory Mandatory (paper based forms are still possible) Optional Not yet determined Civil servants Not yet determined Deployed (was: pilot stage) Deployed (was: pilot stage) Pilot stage Deployed. (A new generation of CPS cards is to be released by the end of 2009) 13 Deployed Design stage. Deployment stage. Hungary Student card Students in Mandatory Deployed 13 It will include two main changes: a wireless reading mode will be added and the card will be merged with the card delivered by the Order to which the health professional belongs to, and eventually will support the European card for healthcare professionals as foreseen in EC Directive 2005/46 of 7 December 2005 on the recognition of professional qualifications. Page 42 of 228

Italy Lithuania Healthcare professional cards eid Card of the Public Employee, or AT-E model ; Carta Multiservizi del Dipendente i.e. Multiservice (Public) Employee Card Electronic Residence Permit, or PSE ( Permesso di Soggiorno Elettronico) Civil Servant eid cards The Netherlands UZI-card (Unique Healthcare Provider Identification, Unieke Zorgverlener Identificatie) Portugal Soft qualified signature certificates for specific professions Slovenia PKI certificates issued by the Ministry of Public Administration Spain Health professional cards Electronic Foreigners Identity public schools (including higher education) Health care professionals Not yet determined Pilot stage. (The planned start of issuance is the end of 2009.) Public employees Mandatory Deployed Non-EU persons that have been authorised to reside in Italy Mandatory Deployed Public employees Optional Deployed Health care professionals Lawyers, solicitors and notaries public Depending on the certificate type; one category consists of public employees All healthcare professionals Non-nationals that have been Optional Optional Optional Mandatory Optional Deployed Deployed Deployed Deployment stage (The replacement project started 2007) 14 Design stage. 14 The project started in 2007 to upgrade the system and replace them with smartcards containing certificates used for user authentication and digital signature. The development phase of the project has finished and the replacement of the cards is already in progress. Page 43 of 228

Turkey Card electrónico NIE-e ) ( NIE or PKI certificates for specific professional groups Soft authentication certificates for lawyers authorised to reside in Spain Depending on Optional Deployed the certificate type: laywers, notaries, Lawyers Optional Deployed Thus, 14 of 32 countries (44%) of countries report the availability of user group specific eid tokens, the majority of which (reported in six countries) relate to health care professional cards; however, only three of these are currently being issued (France, the Netherlands and Slovenia), with the other three still being at the pilot stage. Other significant use cases were civil servant cards (Austria, Italy, Lithuania and Slovenia), foreigners eid cards (Belgium, Italy and Spain), and lawyers credentials (Portugal, Spain and Turkey). Again, the relatively low response rate is indicative of the fact that user group specific tokens are generally not considered to be a key part of a government s eidm strategy. In addition, the fact that the usage is restricted to certain qualifications means that they are hard to generalise into a cross border model, since the key problem that such systems resolve is not just authentication, but also authorisation. Page 44 of 228

4.1.1.5 Preliminary conclusions with regard to tokens As a provisional conclusion, it is clear that identity cards constitute the main token for identification being promoted in the surveyed countries, and that eid cards relying on PKI systems are an increasingly popular choice for the future. They do not constitute the only solution however, as noncard tokens (predominantly PKI certificates) also represent a frequent choice. Public-private partnerships are an important factor in most PKI-based authentication implementations, as can be seen by the larger number of authentication solutions issued by private CSPs. A smaller number of countries have also reported the use of sector/user group specific solutions, such as electronic social security cards or PKI certificates issued to specific professional groups such as civil servants, notaries public or lawyers. However, the prevalence of such solutions still appears to be limited in scale at this point, except in countries where a broader electronic authentication infrastructure has already been set up, such as France, Spain and Italy. Clearly, due to the way tokens have been defined above, this section of the report had a strong focus on PKI solutions, notwithstanding a few exceptional multifactor authentication systems. However, it is essential to note that this first section only deals with authentication means relying on tokens eid cards, paper cards, USB sticks, password calculators, etc. Lower level authentication solutions which rely only on knowledge but not on possession of a token such as username/password systems are not considered in this overview. Such systems will be examined in more detail below. Page 45 of 228

4.1.2 National identifiers This section of the report will describe which unique identifiers are commonly used to identify specific entities in each of the surveyed countries, what their target user group is and what their legal status is. For the purposes of this section, a national identifier is considered to be any code, string or number that is assigned to a specific entity for the purposes of uniquely identifying that entity among all other similar entities within the user group defined below. The tables only include identifiers which are used in an eidm context i.e. which are used in e-government applications to identify a user or to exchange information between administrations. 4.1.2.1 General identifiers All countries use general identifiers, i.e. identifiers that are not restricted to use within one specific application or sector. Such identifiers would in principle be more suitable for identification purposes than sector/application specific sectors, since they are less likely to be restricted to a limited user group. However, in some countries their use is restricted by law, precisely in order to avoid that governments can link personal data about a specific person across different sectors, which is considered to be a privacy threat in some countries. This can render them unusable for cross border authentication purposes. For this reason, the tables below indicate each identifier s legal status as being either unprotected or protected. In the latter case, the table also indicates the type of protection (legal/technical) and the scope of the protection. If the identifier is used within a specific token, this is also indicated in the table. However, this need not be the case, since an identifier can also be used exclusively within administrations for the purposes of internal data exchange. The following countries have been found to have adopted general (application/sector neutral) identifiers: Country Description User group Included in token(s)? Austria SourcePIN (not accessible see below) Tax number (Umsatzsteuer- Identifikationsnu mmer - UID) Register Number of the Register of Company Names or the Central Register of Associations,(Fir menbuchnumme r and Zentrales Natural persons registered in an Austrian register. Legal persons and self-employed natural persons Registered persons legal Yes, in the identity link within the Bürgerkarte see below. No. No. Legal status / privacy issues Protected number; is not accessible under normal circumstances see below. Not protected. Not protected. Page 46 of 228

Belgium Vereinsregistern ummer National Register Number Identity number card Belgian nationals and non-nationals registered in Belgium Belgian nationals and non-nationals that have been authorised to reside in Belgium SIS card number Natural persons subject to Belgian social security Enterprise number Bulgaria Unified Citizen Number BULSTAT number Identification Code (UIC) Croatia The Personal Identification Number (osobni identifikacij ski broj - OIB) Unique Personal Identification Number Legal persons established in Belgium and natural personsentrepreneurs Bulgarian citizens and foreign citizens permanently residing in Bulgaria All entities in the BULSTAT Register All entities in the Commercial Register Croatian citizens and any legal persons registered in Croatia In the certificates on the eid card, SIS card and private sector PKI certificates. No. In the certificates on the SIS card. In private sector PKI certificates issued to enterprises. In PKI signature certificates. In the certificates of the BULSTAT card. No. Not yet, but under consideration. Croatian citizens Stored in the certificates of the CIHI card. Protected number; contains semantic information; may not be used without prior authorisation Unprotected. Not commonly used for eid purposes. Protected. Not commonly used. Unprotected Unprotected. Typically extracted from a signature certificate. Unprotected. When issued to an entrepreneur (a natural person), the BULSTAT number is identical to the Unified Citizen Number Unprotected. Not yet universally used; allocation is planned to be completed in 2010. Introduced 2008. in To be gradually replaced by the aforementioned Page 47 of 228

(Jedinstveni matični broj građana - MBG) Cyprus Unique ID number Czech Republic Denmark Estonia Personal identity number (AKA Birth number) Central personal identification number (CPIN) Central Business Number / Enterprise number Personal Identification Code Centre Registers Infosystems Number of and Citizens, persons of Cypriot descent and aliens who are legally residing in Cyprus Czech citizens and foreigners who have received a residence permit Danish citizens and non-nationals registered in Denmark Entities in the CVR-register Estonian citizens over the age of 15; foreigners residing permanently in Estonia Legal entities and entrepreneurs established in Estonia Finland FINUID number Holders of the FINEID card Business Identity Code Organisations registered in the Business Information System No. No (social security number is typically used) No (OCES signature certificates rely on a serial number which can be mapped to the CPIN, but the CPIN itself is not stored in the token). In the OCES signature certificate issued to legal entities. In the certificates of the eid card. OIB, due to data protection reasons. Unprotected. Unprotected, always used internally as an identification key in egovernment. Protected; may generally not be used in the private sector (although use in the finance sector is common). Unprotected Unprotected No. Unprotected, but not used as an eidm tool In the certificates of the FINEID card. No. Unprotected; derived from the social security number, but contains no sensitive information and has no use outside of authentication Unprotected. Page 48 of 228

France National registration number for physical persons (NIR number) Every individual born on French territory or who becomes a beneficiary of French Social Security SIREN number Legal entities which are economically active in France SIRET number Legal entities which are economically active in France Germany AZR number Non-German persons that have been authorised to reside in Germany Enterprise number (UnternehmensI D) Legal persons established in Germany No (opposed by the Data Protection Authority, CNIL) In certificates issued to legal entities. In certificates of the CPS card. No. No. ID Card number ID card holders No. The use of general identifiers for natural persons for identification purposes is forbidden. Turnover Tax Identification Number Legal entities established in Germany and trading in goods in the E.U. No. The use of general identifiers for natural persons for identification purposes is forbidden. Greece ID Card number ID card holders No (used in registration procedures, but not stored on a token). Hungary Personal Identification Number Any registered Hungary entity in No. The use of general identifiers for natural persons for identification Protected number; contains semantic information; may not be used without prior authorisation Unprotected. Used as the basis for other numbers (e.g. VAT) Unprotected. Consists of the SIREN number with an additional 5 ciphers indicating the economic sector Unprotected Unprotected Protected on constitutional grounds (see below). Protected against use outside the tax sector unless legal provisions to the contrary exist Unprotected. The number is used in the TAXISnet system. Protected against use outside of very specific cases; de facto sector specific; Page 49 of 228

Iceland Social Security Number (SSN#) Ireland Latvia Personal Public Service (PPS) number Personal identity number Natural and legal persons registered in Iceland Irish nationals and any other individuals who have had reason to deal with the public services in Ireland Persons registered in the population register Liechtenstein ID card number Identity card carriers Lithuania Personal code Persons registered in the Residents Register Legal code person s Persons registered in the Register of Legal Persons Luxembourg Identity number Natural and legal persons registered in the general directory RCS number Legal persons and entrepreneurs registered in the Register of Commerce and Enterprises of Luxembourg Malta Identity Number Holders of an ID card (Maltese citizens over the purposes forbidden. is In soft PKI certificates issued by private sector CSPs. No (although it will likely be included in the certificates of a future smart card). No. No. No (although it can be required for registration to receive an authentication means, e.g. for a bank password calculator that can also be used in public sector applications). In the PKI certificated issued to representatives of legal persons. semantic number. Protected, but not strongly. Constitutes the standard ID number in Icelandic egovernment applications. Protected; may only be used by certain entities designated by law. Protected; and not used in eidm systems Unprotected Protected Unprotected No. Protected. Not presently used in eidm systems. No. Unprotected No. Protected under the general Data Protection Act; Page 50 of 228

age of 14 and non-nationals authorised to reside in Malta contains semantic information. Is normally used as an identifier in egovernment applications. Doubles as a tax number for natural persons. Registration Companies Number Legal entities established in Malta No. Unprotected The Netherlands Citizen Service Number (BurgerServiceN ummer) Dutch citizens No (although this may change in the future). Protected; usable in the private sector in certain circumstances Public Register Number ( Anumber ) Dutch citizens No (but used as the identification number of the Municipality Basic Administration) Protected; largely being replaced by the Citizen Service Number Norway Personal Identification Number ( Dnumber ) All natural persons registered in Norway (including non-nationals) No. However, the number is required for registration to some applications; and when using PKI solutions the certificate must include a link to a catalogue containing the number. Protected. Used as the key identifier for all natural persons in eidm solutions Organisation Number Entities in the Central Coordinating Register for Legal Entities No. Unprotected. The number is also granted to entities that voluntarily decide to register. Poland PESEL number (Powszechny Elektroniczny System Ewidencji Ludności General Electronic System for Citizens Evidence) Polish citizens and foreigners authorised to reside in Poland or subject to Polish health insurance or social security Included in the certificates of the EKUZ card, and in some private sector issued PKI certificates. Protected. There have been incidents where the same PESEL number has been allocated twice to different persons; the planned PESEL2 system would resolve this. Also, the PESEL number can change when identity data (birth Page 51 of 228

date, gender) is changed. National Judicial Register number (KRS number) Legal persons and entrepreneurs who are economically active in Poland No. Unprotected. REGON number Legal persons and entrepreneurs who are economically active in Poland No. Unprotected. Overlaps will KRS number, and will therefore be retired. Portugal Personal identification number / Population register number Portuguese citizens and natural persons that have been authorised to reside in Portugal In the certificates of the eid card. Protected Romania Personal Numeric Code Romanian citizens, and foreign persons upon the request of a competent public authority No Unprotected. Slovakia Personal identification number (Birth number) Natural persons born in Slovakia or that have been authorised to reside in Slovakia, either permanently or temporarily (e.g. refugees) No, the inclusion of the number as an identifier in a token is considered unlawful. Unprotected. Unsuitable as an identifier, as it is semantically composed and namespace clashes can occur; is none the less used as the key identifier. Will be replaced for eidm purposes. IČO number (identification number of business entity) Legal entities established in Slovakia No. Unprotected. Slovenia Personal Registration Number (PRN) Slovenian citizens and non-nationals wishing to exercise their rights in Slovenia No, although private sector CSPs will maintain databases to link the certificate serial number to the PRN or tax number. Protected Identification number Legal entities established in Slovakia In private sector PKI certificates issued to legal Unprotected Page 52 of 228

Spain Personal ID number (ID card number) Sweden Turkey United Kingdom Foreigners number (NIE (número de identificación de extranjeros)) Tax Enterprise Number (CIF: Código de Identificación Fiscal ) Personal identification number of the population register Swedish enterprise number issued by the Swedish Companies Registration Office Turkish Republic Identification Number Enterprise number National Identity Registration Number ID card holders Non-nationals that have been authorised to reside in Spain Legal entities established in Spain Swedish citizen and others having a Swedish personal identification number. Business enterprises established Sweden in persons. In the certificates on the eid card. No. used in PKI qualified certificates issued to legal persons In the PKI certificates issued by the recognized private sector partners (today mostly banks). Used in server and organisation certificates ( stamp certificates ). Protected Unprotected Unprotected Protected. Used as the unique identifier in Swedish eid certificates issued by recognized private sector partners (today mostly banks). Partly semantic (date of birth). Unprotected Turkish citizens No. Unprotected Legal entities established in Turkey UK citizens and all natural persons wishing to reside in the UK No. No, although it will likely be included in the certificates of the future eid card. Unprotected Protected Provisionally, the table above allows a number of conclusions to be formulated. Specifically: The table shows a wide variety of approaches, with most countries relying on legacy identifiers traditionally used in paper administrations (e.g. Belgium, the Czech Republic, Poland); while others have introduced specific identifiers for the explicit purpose of authentication (e.g. Finland, The Netherlands), or in the Austrian case even an obfuscated identifier which is used Page 53 of 228

internally to generate context specific identifiers, but which is never used for authentication purposes in an uncoded form. More importantly, the table shows that the countries have different standards for the legal protection of identifiers. While identifiers for natural persons are by definition personal data and thus subject to the provisions of local data protection laws, this is not considered sufficient in some countries. As will be further commented below (see section 4.5.3.1.), a number of countries consider that public sector issued identifiers such as those above should be protected against trivialisation through private sector use, as this would create a privacy risk by allowing parties to more easily link data from various sources together without due permission. Additional legal protection regimes were reported in 20 of the 32 surveyed countries (30%). In such countries (such as e.g. France and Belgium) these identifiers can only be used after authorisation has been granted by or under law. It should be noted that in a number of countries, correspondents have expressed doubts with regard to the reliability (specifically the unique character) of the reported identifiers, even when these were considered of key importance for eidm purposes. It goes without saying that a lacking reliability would render these identifiers unsuitable for authentication purposes (as, in effect, they no longer meet the definition of an identifier). Such doubts were reported in Poland and Slovakia, where initiatives have begun to rectify this situation. It is also interesting to note that a number of these identifiers have been reported as being (partially) semantic in nature in 7 out of 32 countries; i.e. the identifier reveals the date of birth and/or gender of the subject. Oddly, this is not considered to be a problem in some countries (e.g. Belgium), whereas in others (e.g. Croatia, Slovakia and Poland) it is considered that this makes the identifier unsuitable for authentication purposes, as it would be insufficiently secure. From an interoperability perspective, the main conclusion appears to be that semantic identifiers should be avoided, as they are considered politically unsuitable in some countries. Inclusion of key identifiers in tokens is not as common as one might expect: 18 identifiers were reported to be stored in a token, whereas 36 were not. While this might appear counterintuitive, this can be the case where such an identifier is required for registration purposes (e.g. to obtain a username/password), or where an administration uses an identifier to obtain additional information after a successful authentication. From an interoperability perspective, the main conclusion is that the importance of such identifiers is difficult to assess: the identifier may be crucial for an administration even if it is not stored on a token; and inversely it may be unused even when it is. However, the most important conclusion for the purposes of European interoperability stems from the fact that legal regimes in at least two countries (Germany and Hungary) oppose the use of general identifiers for identification purposes on constitutional grounds; with similar but more limited objections existing in other countries such as Portugal and France (see section 4.5.3.1. below for a more detailed analysis). In effect, this renders the examination of general unique identifiers somewhat moot, as the use of general identifiers for the identification of natural persons would at any rate be unacceptable in these countries. Page 54 of 228

4.1.2.2 Sector specific identifiers Apart from the general (sector/context agnostic) identifiers mentioned above, the surveyed countries have also adopted identifiers that were intended for a specific use (e.g. VAT numbers) or for a specific context (e.g. tax numbers or social security numbers). The correspondents were asked to report these, to the extent that such identifiers were a significant part of their country s eidm strategy. Such identifiers can be significant within a specific context, especially in countries where the use of general identifiers for identification purposes is considered to be unlawful, and where sector specific identifiers thus fill a clear need. This resulted in the overview below. Again, the table indicates if the specific identifier is subject to a legal protection regime that bars the identifier from being used outside of its context. Country Description User group Included in token(s)? Austria Sector specific identifiers derived from the SourcePIN see below Social number VAT number security Natural persons Yes (calculated through the identity link on the Bürgerkarte; see below). Persons registered to Austrian social security Persons subject to Austrian VAT regulations Belgium VAT number Persons subject to Belgian VAT regulations Cyprus Czech Republic Taxpayer s Identification Code Social number security Finland Social security number All natural persons registered with the Tax Archive of the Inland Revenue Department Natural persons who have registered Czech Republic social security Natural persons subject to Finnish social security No. No. In private sector PKI certificates issued to enterprises. No; but used for registration for username/ password In most private sector issued PKI certificates. In civil servant smart cards (and used as an identifier when using the paper TUPAS token, although the number is not stored on this token). Legal status / privacy issues Protected number; cannot normally be used outside of its sector. Not protected. Not protected. Identical to the Enterprise Number (see above) Unprotected; used as a general identifier. Protected; however, it is often used as an identifier in qualified signature certificates Protected, due to semantic information in the identifier. Used as an identifier in TUPAS authentication. Page 55 of 228

VAT number France RNIAM number (National repertory interregimes of Health Insurance beneficiaries) Germany Greece Organisations registered in the Business Information System Any Security beneficiary than 16 Social older ADELI number Health care professionals Social Insurance number (Sozialversicheru ngs-nummer) Natural persons subject to German social security No. No (used on forms and in registers, but not directly on a token). Stored in certificates of health care professional cards. Unprotected. Protected (consists of a concatenation of the NIR and a key of 3 ciphers) Protected (only used by health care professionals) No. Protected (only used within pension insurance funds unless legal provisions to the contrary exist)) Tax number German taxpayers No. Protected (only used within tax sector, unless legal provisions to the contrary exist) Tax Identification number Hungary Social Security Identification Number Tax Identification Number Greek taxpayers (natural and legal persons) Natural persons subject to Hungarian social security Hungarian taxpayers (natural and legal persons) Italy Fiscal Code Italian taxpayers (natural and legal persons) Luxembourg VAT number Legal persons and entrepreneurs subject to VAT No, but the number is required to register for a username/ password No. The identifier is often asked after logging in with a username/ password, but it is not stored on a token. No. The identifier is often asked after logging in with a username/ password, but it is not stored on a token. Yes, in the certificates of the eid card. No. Unprotected. The number is the basis for the TAXISnet system. Unprotected. Unprotected. Unprotected. Unprotected. Page 56 of 228

Fiscal number Malta Social Security number The Netherlands Poland Employer number Social Security Number (SoFinumber) Tax Identification Numbers (Numer Identyfikacji Podatkowej - NIP) Portugal Social Security number obligations Luxembourg in Legal persons and entrepreneurs subject to tax obligations in Luxembourg All persons economically active in Malta Maltese employers Natural persons subject to Dutch social security All persons (natural and legal) paying taxes in Poland Natural persons subject to Portuguese social security Tax number All persons (natural and legal) paying taxes in Portugal Health number user Slovakia Social Security number Natural persons subject to Portuguese health services Natural persons subject to Slovakian social security Tax number All persons (natural and legal) paying taxes in Slovakia Health number user Slovenia Tax number (TIN) Natural persons subject to Slovak health services All natural persons paying taxes in Slovenia No. No. In PKI certificates for certain tax/social security declarations. No (but needed to request a DigiD username and password). In PKI certificates issued by private sector CSPs In the certificates of the national eid card. In the certificates of the national eid card. In the certificates of the national eid card. No. No. No. In some private sector issued PKI certificates (can also be stored in a Unprotected. Unprotected Unprotected Protected Unprotected Unprotected Unprotected Unprotected Unprotected Unprotected Unprotected Protected Page 57 of 228

separate database). Health insurance number Natural subject Slovenian services persons to health In the certificates of the health insurance card (which is not used for authentication in egovernment applications). Protected VAT number All legal persons subject to VAT in Slovenia Yes, in CIGEN-CA PKI certificates issued to a legal person. Unprotected Spain Tax Enterprise Number (CIF: Código de Identificación Fiscal ) Legal entities established in Spain Used in PKI qualified certificates issued to legal persons, and as the main company identifier used by the Tax Agency to identify a legal entity. Unprotected Social Number Security Natural and legal persons registered in Spain for Social Security purposes No. Unprotected. United Kingdom National Insurance number All persons eligible for employment in the UK No, although this might change in the future. Unprotected. Used for social security and tax administrations. National Service number 15 Health (NHS) All persons eligible for health care in the UK No, although this will likely change with the introduction of electronic health records.. Unprotected. Presently not linked to a central database. The main findings with regard to sector/context specific identifiers can be summarised as follows: Only a fairly small number of correspondents reported such identifiers as being a key part of their governments eidm strategy: only 19 countries out of 32 (59%) reported relying on such identifiers, with 35 identifiers being reported in total (as compared to 60 in the overview of general identifiers above). Only 14 of these 31 (44%) were reported as being stored in a token; with the remainder mostly being important for internal administrative reasons (i.e. data collection and exchange between or within administrations). Principally, this can be indicative of insufficient role management/mandate management in the surveyed countries, as these identifiers by definition require a link to a certain context, (i.e. as being registered as a social security beneficiary, or as being the representative of a legal entity). This issue will be examined in more detail below (see section 4.3.). 15 Referred to as the Community Health Index in Scotland. Page 58 of 228

Protected identifiers are less common for sector specific identifiers (11 out of 35 identifiers were reported as being protected, or 31%) than for general identifiers (66%, as noted above). Mostly this can be explained by the inclusion of VAT numbers (5 out of 32, or 16%), which indeed by their very nature are not compatible with specific legal protection. Legal protection is occasionally granted to social security numbers or tax numbers, especially in countries where the use of general identifiers is traditionally opposed for reasons of privacy (e.g. Germany, Hungary and France). Page 59 of 228

Alternative approach obfuscated identifier in Austria As noted above, Austria relies on a specific identifier approach which is (thus far) unique in Europe, and requires some further explanation. Austria uses a source PIN number, which is however never used directly to authenticate the user in egovernment applications. The sourcepin is a unique identifier that is derived from base register identifiers for natural persons, i.e. the Central Register of Residents Number or the Supplementary Register for Natural Persons Number. Then, the sourcepin Register Authority applies a TripleDES encryption step to the base identifiers to create the sourcepin (128 bit binary or 24 digit base64 number). This calculation is done by the so called sourcepin Register, which is however not a traditional register (i.e. a database of sourcepins), as sourcepins are created just on demand and only stored in the identity link in the citizen card. The sourcepins are only stored in a so-called identity link (Personenbindung) in the citizen card. The identity link is a data structure that is created by the sourcepin Register Authority during the issuance process of citizen cards. A signature of the sourcepin Register Authority attests the link between the unique identifier sourcepin and an electronic signature provided to the entity by the citizen card issuer. The identity also holds the name and data of birth. These data are frequently needed in official proceedings and intelligent forms can be pre-filled with the name and data of birth. The sourcepin may only be stored in the identity link in the citizen card, thus is under sole control of the citizen. The Austrian eidm model using the citizen cards is thus based on sector-specific 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 unlawfully cross-related. The Sector Delineation Regulation (E-Government-Bereichsabgrenzungsverordnung - E-Gov- BerAbgrV) defines 26 sectors of State Activity so that within each sector using the same identifier no data protection issue is caused. Examples for such sectors are taxes, health, or sports. Nine further spanning delineators are defined that may involve or be used by distinct sectors, such as legal protection, electronic delivery, or human resource management. The eidm model is open for the private sector. Companies can use the citizen card to derive private sector-specific PINs that are unique within their sphere, but cannot be cross-linked with identifiers of other entities. The company s identifier is used as a delineator during the cryptographic calculations similar as the sectors described above are used for calculating sector-specific PINs for the public sector. Once an application introduces the citizen card, its sector-specific identifiers are paired with the traditional number. To give an example, when accessing the pension record with the citizen card, a sector-specific identifier for the sector social insurance is created and linked to the traditional identifier social security number. Several methods to carry out such pairings are used, such as prepopulating databases with the sector-specific identifiers, or the citizen entering identifiers or matching attributes accompanied by plausibility checks. The use of a similar system is also being planned in the Czech Republic, but has not yet been implemented. In this case, the new Act on central registers (approved on 26th March 2009, planned to come into effect on 1st July 2010) foresees the introduction of a "basic personal identifier" from which will be derived 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. Thus, data protection guarantees seem to be taking a more important role in national eidm policies. Page 60 of 228

4.1.2.3 General conclusion with regard to identifiers As shown in the overviews above, while all countries use identifiers in some form or other, their national policies vary widely, ranging from the use of general unprotected identifiers (e.g. the Finnish FINUID), over general protected identifiers (e.g. the Belgian National Register Number), to banning general identifiers in preference of sector specific ones (e.g. Hungary and Germany), to the use of an obfuscated general identifier which is used to calculate context specific ones (Austria). This inevitably makes identification numbers difficult to use in a cross border context: general identifiers are constitutionally and politically unacceptable as an identification solution in some countries, while this may simply be the only identifiers that some countries have and want. In addition, it is very difficult to accurately assess the importance of such identifiers for the purposes of electronic identity management. As show above, 36 of the 95 examined identifiers (38%) were reported to be commonly stored in tokens. However, even when this was not the case, such identifiers might still play a crucial role for the purposes of identity management. Sometimes such an identifier is needed to obtain a token or to obtain credentials (see e.g. the Slovenian example, where identifiers themselves are not necessarily stored in a PKI certificate, but CSPs are required to ensure that they can link each certificate serial number to a corresponding identifier such as a tax number); or the identifier is used internally to exchange information between different branches of one or more administrations (see e.g. the Hungarian system of reidentification, discussed in section 4.5.3.1., where identity attributes can be obtained from databases after authentication based solely on the name and e-mail address of a person). However, there is a more fundamental conclusion to be drawn from the analysis above: while the public sector issued identifiers can be (and often are) vital for the internal identity management within a country, they are of limited use in an international context. Unlike a national administration, a foreign administration will never be able to obtain the identity information that its applications require based on an identity number, unless access to national identity information databases would be enabled to foreign administrations. This is currently exceedingly difficult, as not all countries have centralised reliable identity sources exist (see below). From this perspective, it can only be concluded that the identifiers mentioned above are a vital part of national identity infrastructure in each distinct country, but that the European level use of these identifiers for the purposes of electronic identification is extremely complicated, from a legal, political and practical perspective. Page 61 of 228

4.1.3 Identity registers Apart from tokens and identifiers, a third important identity resource to draw upon are the existing official registers (defined above as data collections held and maintained by public authorities, in which the identity attributes of a clearly defined subset of entities is managed, and to which a particular legal or factual trust is attached (i.e. which are generally assumed to be correct) ). The definition already indicates why these registers are important for the purposes of cross border identity management: identity registers are the most basic resource on which a government can draw to create an electronic identity management system. In addition, there is an explicit or implicit assumption of correctness to the data in these registers, as they are used for essential government tasks. This section will describe for each of the surveyed countries which types of identity registers are commonly used for the purposes of identity management, including registers targeted at natural persons, legal persons and foreigners. 4.1.3.1 Natural persons This first section focuses on the main registers for natural persons, and specifically natural persons who are citizens of each specific country or foreigners who have been authorised to reside in the country. Country Description User group Status / details Austria Central Register of Residents (Zentrales Melderegister) Austrian nationals and non-nationals registered in Austria Belgium National Register Belgian nationals and non-nationals registered in Belgium Bulgaria Croatia Crossroads Bank of Social Security Unified System for Civil Registration and Administrative Service of the Population Birth/Death and Marriage Registers, Citizenship Register, and Register of Residences Natural persons subject to Belgian social security Bulgarian citizens and foreign citizens permanently residing in Bulgaria Croatian citizens and non-nationals registered in Croatia Cyprus Civil Registry System Cyprus nationals and non-nationals registered in Cyprus Czech Republic Population Register Czech nationals and non-nationals registered in the Czech Republic Operational Operational Operational. It should be noted that this is a reference database; i.e. it refers to other databases, but contains no actual data on the subjects. Operational. Operational. Operational. Operational. Information is however not always considered reliable. Page 62 of 228

Denmark National Register Danish citizens and nonnationals registered in the Denmark Estonia Population Register Estonian citizens and foreigners who have obtained residence permits Finland Population Information System France National directory of natural person s identification Germany Finnish citizens and nonnationals registered in Finland Every individual born on French territory or who becomes a beneficiary of French Social Security ADELI Register Health care professionals Registers of residence (Melderegister) Civil Status Register (Personenstands-buch) German citizens Operational. Operational. Operational. Also accessible to private entities under specific circumstances. Operational; used predominantly as a tool to prevent administrative errors. Operational Operational. Held only at the municipal level (approx. 5.000 registers in total); is expected to be centralised in 2010 into a Federal Civil Register (Bundesmelderegister). German citizens Operational. Contains only civil status information; is expected to be transformed to an electronic register in 2009. Greece Registers of inhabitants Greek citizens Operational. Held only at the municipal/commune level. Hungary Register of personal data and address Social security register Hungarian citizens and non-nationals that have been authorised to reside in Hungary Natural persons subject to Hungarian social security Tax register Persons subject to Hungarian taxes Operational Operational Operational Iceland National Population Register Ireland Public Service Identity (PSI) database Natural persons that have been authorised to reside in Iceland Irish nationals and other individuals who have had reason to deal with the Operational Operational. Page 63 of 228

Italy Central residents database public services in Ireland Italian citizens and nonnationals that have been authorised to reside in Italy Latvia Population Register Latvian citizens and nonnationals that have been authorised to reside in Latvia Liechtenstein Civil Registers (Zivilstandsregister) Liechtenstein citizens Lithuania Residents Register Lithuanian citizens and non-nationals that have been authorised to reside in Lithuania Luxembourg General directory (Répertoire general) Natural persons that have been authorised to reside in Luxembourg, and legal persons established or economically active in Luxembourg. Malta Public Registry Maltese citizens and non-nationals registered in Malta The Netherlands Social Security Register Register of Taxpayers Municipality Basic Administration (Gemeentelijke Basisadministratie) Norway Central Population Register (Folkeregisteret) All persons economically active in Malta All persons who are required to pay taxes in Malta All persons who are registered as residents in the Netherlands All persons residing in Norway (including nonnationals) Poland PESEL system All Polish citizens and all natural persons authorised to reside in Poland Operational. Note that the database is kept centrally, but that all data is encrypted using the public key of the originating municipality, so that only this municipality can access the data. Operational. Operational. Operational. Operational. Operational Operational Operational Operational; the A- number is used as the unique identifier. Operational Register of Tax All natural and legal Operational Operational. To be replaced by the PESEL2 system in 2010, which is expected to be centralised and more reliable than the existing PESEL system. Page 64 of 228

Identification Numbers persons economically active in Poland Portugal Population register Portuguese citizens and Brazilian citizens covered by the Treaty of Porto Seguro Romania National Registry of Natural Persons (Registrul National de Evidenta a Persoanelor) Natural persons that have been authorised to reside in Romania Slovakia Population Register Citizens of the Slovak Republic (i.e. natural persons that have been authorised to reside in the Slovak Republic) Slovenia Slovenian Central Register of Population (CRP) Slovenian citizens and non-nationals wishing to exercise their rights in Slovenia Spain Civil Registry Spanish citizens and natural persons that have been authorised to reside in Spain Sweden Population register Swedish citizens and natural persons that have been authorised to reside in Sweden Turkey MERNIS database Turkish citizens and natural persons that have been authorised to reside in Turkey United Kingdom National Identity Register UK citizens and all persons wishing to reside in the UK over 16. Operational Operational Operational Operational Operational Operational. Also accessible to private entities under specific circumstances. Operational. The MERNIS database bundles the existing Turkish population registers. To be established; currently identity data is not systematically collected in a single database in the UK. The following main conclusions can be drawn from the table above: Obviously, all countries have implemented basic population registers (regardless of the specific name) in which all citizens are registered with their basic identity information. Natural persons are registered in these databases at birth, or upon a judicial or administrative decision from a competent authority in that country, which ensures that the stored information can generally be relied upon. Despite this implied guarantee, correspondents in two countries none the less reported occasional errors impairing the reliability of these registers, specifically Poland and the Czech Republic. However, in both cases initiatives are underway to rectify this situation. It is interesting to note that the basic registers are often held at a regional or municipal level. This has been reported inter alia in Germany, Greece and Italy. The latter case is somewhat Page 65 of 228

exceptional, as the actual database is held centrally, but the stored data is encrypted in a way that impedes access to the information except for the commune which had provided the information to begin with. Thus, information leaks are prevented. A number of context specific registers for natural persons were also reported, including the Belgian Crossroads Bank of Social Security which contains references to a multitude of databases with social security related information (but no information on the subjects as such), the French ADELI database containing information on health care professionals, or the Maltese Register of Tax Payers. Obviously, such databases have only been reported in countries where they are considered to be a key component of the country s eidm strategy. For instance, tax registers can be reasonably assumed to exist in all countries, but have only been reported in countries where tax information is considered a fundamental resource for identity management. Page 66 of 228

4.1.3.2 Legal entities Similar to the table above, the section below provides an overview of available identity registers, now covering legal entities. This includes legal entities which have been established within a given country, or which have a local branch that is subject to registration on account of its economical activities. Country Description User group Status / details Austria Belgium Register of Company Names (Firmenbuch) Central Register of Associations (Zentrales Vereinsregister) Supplementary Register of Other Data Subjects (Ergänzungsregister für sonstige Betroffene) Crossroads database of enterprises Limosa Austrian legal persons Austrian legal persons Entities not covered by registers mentioned above Legal persons established in Belgium or required to register in Belgium Foreign persons wishing to employ someone in Belgium or to pursue a temporary or partial activity as a selfemployed person. Bulgaria BULSTAT Register Companies, non-profit organisations, public institutions, other kinds of legal entities, branches of foreign company, and selfemployed Croatia Cyprus Commercial Register Companies, non-profit organisations, public institutions, other kinds of legal entities, branches of foreign company, and selfemployed Court register and the Register of Associations Companies Registration System Legal entities including trading companies, coops, and institutions established in Croatia Companies, overseas companies, partnerships and business names Operational Operational Operational. Operational. Also contains natural persons who are entrepreneurs in Belgium. Operational. Also mandatory for natural persons who wish to be active as entrepreneurs in Belgium. Operational. To be integrated into one central database, the Commercial Register. Operational since 2008. Operational; accessible via the internet. Operational. Page 67 of 228

Czech Republic Administrative Register of Economic Subjects (ARES) Denmark Central Business Register (CVR-register) Estonia Centre of Registers and Infosystems Finland Business Information System France National directory of legal persons (SIRENE) Germany Commercial Registers (Handelsregister) Companies Register (Unternehmens-register) Legal entities established in the Czech Republic Legal entities and entrepreneurs established in Denmark Legal entities and entrepreneurs established in Estonia Businesses and organisations entered in the Trade Register, Register of Foundations, VAT register, Prepayment Register, Employer Register or the Client Register of the Tax Administration Legal entities which are economically active in France Legal entities established in Germany Legal entities established in Germany Greece Trade registers Legal entities established in Greece Hungary Company register Legal entities established in Hungary Iceland National Business Register Legal entities established in Iceland Operational. ARES is actually not a register, but a system that draws its information from a series of other registers (the Companies Register, the Trade Register, the Economical Subjects Register and 120 smaller registers). ARES can be consulted online. In the long term, ARES will likely be transformed into one central register, Register of Subjects. Operational. Operational. Operational. Operational. Operational Operational (supplement to the Handelsregister) Operational. To be centralised in an electronic General Register for legal persons, but this register is not yet operational. Operational as a distributed database with sources at 20 District Courts. Operational. Page 68 of 228

Ireland Business registers Legal entities established in Ireland Italy Commercial Register (registro delle imprese) Legal entities established in Italy Latvia Commercial Register Legal entities established in Latvia Liechtenstein Company Register Legal entities established in Liechtenstein Lithuania Register of Legal Persons Legal entities established in Lithuania and Lithuanian branches and representations of foreign legal persons Luxembourg Commercial Register Legal entities and entrepreneurs established or economically active in Luxembourg Malta The Netherlands Register of commercial partnerships and companies Register of Employers Legal entities a established in Malta All employers in Malta (including natural persons) Trade Register Legal entities established in The Netherlands Norway Central Coordinating Register for Legal Entities Poland National Judicial Register (KRS) Portugal National Company Registry (Registo Nacional de Pessoas Entities subject to registration obligations in Norway. Legal entities and entrepreneurs economically active in Poland Legal entities established in Portugal Operational. Operational; managed by the Chamber of Commerce (one per province) Operational Operational. Accessible via the internet. Operational. Open to the public. Operational. Open to the public. Operational Operational Operational Operational. Note that the register contains information on entities subject to registration obligations as employers, VAT payers, tax payers, etc. ; but that entities can (and do) also register voluntarily. Operational. Operational Page 69 of 228

Romania Colectivas) Trade Registries of the County Tribunal Registry of Legal Persons Commercial legal entities established in Romania Legal entities established in Romania Slovakia Trade Register Legal entities established in Slovakia Commercial Register Legal entities established in Slovakia Slovenia Business Register Legal entities established in Slovenia Spain Companies Registry Legal entities and entrepreneurs established in Spain Sweden Trade and Industry Register Turkey United Kingdom Ministry of Finance Tax Number (Maliye Bakanlığı Vergi Numarası Companies database House Legal entities and entrepreneurs established in Sweden Legal entities established in Turkey Limited liability entities established in the UK Operational; available online 16 on the National Trade Registry online database (RECOM) Operational Operational Operational Operational Operational Operational. Consists of a number of subregisters, including the Limited Companies Register and the Business Register. Operational Operational Again, all countries have implemented some form of database for legal entities. It should be noted that these registers typically also include entrepreneurs (natural persons who are economically active as self employed). An important difference with the registers for natural persons is that the managers of legal entities must take active steps themselves to become registered, whereas natural persons become registered at birth or as a part of the process of obtaining a permission to reside in a country. This means that identity information is yielded on a voluntary basis, in exchange for the ability to exercise an economic activity. This difference in motivation (automatic registration vs. voluntary registration) has been exploited in Belgium, where a separate database under the name of Limosa was created with the express purpose of being able to identify legal entities and entrepreneurs across borders. Limosa aims to register foreign companies, organisations or self-employed persons wishing to employ someone in Belgium, or wishing to establish themselves in Belgium in order to pursue a temporary or partial activity as a self-employed person. For persons already registered in a Belgian official register, there was already a requirement to register such changes electronically using the so called Dimona application 17. However, for other persons (natural or legal) who are not subject to Belgian social security, this obviously presents a problem if no prior entry in an official register exists. 16 See http://recom.onrc.ro/indexe.htm, (in English) 17 See https://www.socialsecurity.be/site_nl/applics/dimona/index.htm Page 70 of 228

For this reason, the Limosa application 18 was created, which requires temporary/partial employees to register electronically before they can begin any professional activities. The declaration must be done by the employer or organisation that sends somebody to Belgium, or by the person himself if he is selfemployed and coming to work temporarily/partially in Belgium. After an electronic registration process, the person receives a username and password which can be used to electronically declare the activity, after which a so called Limosa-1-certificate is issued electronically. This certificate must be printed out and carried at all times by the foreign worker in Belgium. The interesting element in this application is the registration process, which merely requires the registering entity to fill out a web form, providing one of four possible identification numbers (national number, passport number, social security number or pension number) from the country of origin, or a Belgian social security number (if available). The provided information is not formally checked. While the system is inherently weakly protected against abuse (since it depends on unverified claims from the registering party), the approach is none the less considered viable, because the target user group is precisely economic entities who wish to comply with Belgian social and fiscal law, and who therefore have no real benefit in defrauding the system by providing inaccurate information. 18 See https://www.socialsecurity.be/foreign/en/employer_limosa/home.html Page 71 of 228

4.1.3.3 Foreigners registers Finally, a number of countries have also reported the existence of specific registers for foreign natural persons, which are not covered by the general registers above (e.g. asylum seekers). Country Description User group Status / details Austria Supplementary Register for Natural Persons Foreigners or expatriates that are not covered otherwise Belgium Non-nationals Register Foreigners that have been authorised to reside in Belgium Waiting Register Foreigners who have applied for but not yet received permission to reside in Belgium Bisregister Persons who are subject to Belgian social security but who are not registered in the National Register Estonia Aliens Register Non-Estonian citizens that have been authorised to reside in Estonia France Foreigners register (AGDREF) Germany Central Register for Aliens (Ausländerzentralregister, AZR) Non-French citizens who have not (yet) been authorised to reside permanently in France Non-German citizens who have not (yet) been authorised to reside permanently in Germany Ireland Register of non-nationals Non-Irish citizens that have been authorised to reside in Ireland Lithuania Register of Foreigners Non-Lithuanian citizens regardless of mandate to reside in Lithuania Romania Foreigners registers Non-Romanian citizens that have been authorised to reside in Romania Spain Central Registry of Foreigners Operational Operational. Information is integrated into the National Register. Operational. Information is integrated into the National Register. Operational Operational. Operational Operational Operational Operational Operational Non-Spanish citizens Operational that have been authorised to reside in Spain Page 72 of 228

Only 9 correspondents have reported the existence of such registers. While the actual number is likely to be higher, this can be taken as being indicative for the smaller interest for non-national users in eidm systems, which were the main focus of the reports. Page 73 of 228

4.1.4 Biometrics This section will summarise briefly in which countries the use of biometrics for identity management (other than biometric passports) is being used/planned/considered/not considered. The reason for the principal exclusion of biometric passports was the observation that these are currently not used as means of identification/authentication in egovernment applications (although this could obviously change in the future). The prevalence of biometric information in eid means is relevant as an assessment of the technical status of biometrics as an enabling technology for electronic authentication (i.e. to determine what countries, if any, consider biometrics to be suitable for use in their applications); but also to gauge the socio-cultural attitudes with regard to biometrics (i.e. to determine in which countries biometrics have not met with political controversy). The countries have all been described as either: Not under consideration: use of biometrics has not been seriously considered; Under consideration: use of biometrics is under consideration as explained in the column Description/Details, but no specific plans have been made yet; Planned: use of biometrics is being planned as explained in the column Description/Details, but no specific implementation exists as of yet; and Used: biometrics are actively being used in the form as explained in the column Description/Details. The following situation was reported by the correspondents: Country Status (Used / Planned / Under consideration / Not under consideration) Austria Not under consideration N.A. Belgium Not under consideration N.A. Bulgaria Not under consideration N.A. Croatia Not under consideration N.A. Cyprus Not under consideration N.A. Czech Republic Not under consideration N.A. Denmark Not under consideration N.A. Description / Details Estonia Planned The inclusion of biometric support for nextgeneration ID-cards (2011+) is planned, at least in ID-cards for foreign residents. Whether biometric elements will also be included on the Estonian citizen card is yet to be decided. France Planned The future eid card is currently planned to contain biometric features (picture and two fingerprints), which will also be stored in a central database. Note that fingerprints are currently already taken when requesting a paper ID card, but the data is presently not further processed. Page 74 of 228

Germany Under consideration The expectation is that the future eid card will contain biometric features (picture and optionally 2 fingerprints). These will be accessible only for official bodies by means of special built-in security features technically based on card-verifiable certificates. Greece Not under consideration N.A. Hungary Not under consideration N.A. Iceland Not under consideration N.A. Ireland Not under consideration N.A. Italy Used Hashes of biometric data in the form of fingerprints can be used in the eid card (CIE), electronic Residence Permit (PSE), and public employee card (CMD). After 1 January 2010, fingerprints in the CIE will be mandatory. Latvia Not under consideration N.A. Liechtenstein Not under consideration N.A. Lithuania Used Biometric identity cards with fingerprint images in a contactless chip are issued since 2 January 2009. Malta Not under consideration N.A. Luxembourg Not under consideration N.A. The Netherlands Used Fingerprints are included on the Dutch identity card since 21 September 2009. Norway Not under consideration N.A. Poland Under consideration Biometrics are being considered as a possibility for the future eid card, although there are no specific plans in this regard yet. Portugal Used Biometric data in the form of photo and fingerprints is included in the new eid card. Romania Under consideration The inclusion of (as of yet unspecified) biometric data on the future eid card is being considered. Slovakia Not under consideration N.A. Slovenia Not under consideration The planned eid card should be capable of having biometric functionality integrated into it at a later point. Spain Used The national eid card uses MoC functionality based on fingerprints. Sweden Not under consideration N.A. Turkey Planned Fingerprints are planned to be included on a future electronic health card. United Kingdom Planned The future eid card is planned to hold Page 75 of 228

fingerprints and facial images. The table shows that biometrics are presently not very pervasive yet in the surveyed countries; however, there appears to be increasing support: Five countries out of 32 report actually using biometrics (Italy, Lithuania, the Netherlands, Portugal and Spain), in each case relying on fingerprint data (in hashed form in the Italian case). Lithuania and the Netherlands did not yet have fingerprints stored or their eid means in the 2007 edition of this study; in both cases, the change relates to an update of their respective identity cards. Four additional countries are planning to introduce biometrics (France, Estonia, Turkey and the UK), again relying on fingerprints. Of these, only France already has a tradition of collection fingerprints in the issuing of identity cards. Three countries (Germany, Poland and Romania) are considering the use of biometrics in future technologies, notably in their planned eid cards, but no exact details are available yet. Thus, a majority of the surveyed countries (20 of 32 countries, 63%) have not yet made plans for biometrics. As biometrics have not been reported as an authentication method for specific egovernment applications in any of these countries, the presence or absence of biometrics should not have any impact on interoperability. Page 76 of 228

4.1.5 Mobile phone based identification This section will summarise briefly in which countries the use of mobile phones for identity management is being used/planned/considered/not considered/abandoned. This is particularly relevant due to the generalisation of roaming agreements, meaning that there is already a basic cross border trust infrastructure between telephone operators present that could theoretically serve as a basis for interoperability. The countries have all been described as either: Not under consideration: use of mobile phones has not been seriously considered; Under consideration: use of mobile phones is under consideration as explained in the column Description/Details, but no specific plans have been made yet; Planned: use of mobile phones is being planned as explained in the column Description/Details, but no specific implementation exists as of yet; and Used: mobile phones are actively being used in the form as explained in the column Description/Details. Abandoned: mobile phones have been used in the past in e-government applications, but have since been abandoned. If the reason is known, this will be indicated in the column Description/Details. The following situation was reported by the correspondents: Country Status (Used / Planned / Under consideration / Not under consideration / Abandoned) Description / Details Austria Used Since Q4 2009, mobile phone based identification is possible in certain egovernment application (e.g. income tax declaration), using qualified certificates in which a hardware security module (HSM) managed by the operator functions as an SSCD storing the cryptographic keys, making the solution an application of the generic Austrian citizen card concept resulting in qualified signatures 19. Belgium Not under consideration N.A. Bulgaria Not under consideration N.A. Croatia Planned Use of SMS based authentication is currently being examined, and is expected to be implemented in 2010. Cyprus Not under consideration N.A. 19 Information kindly provided by M. Peter Kustor of the Austrian Federal Chancellery after the finalization of the Austrian country profile. Page 77 of 228

Czech Republic Not under consideration N.A. Denmark Planned Within the next couple of years a mobile solution for the next generation digital signature is planned. The solution will be based on wireless PKI (wpki), where digital signatures are stored on the mobile phone s sim card. Estonia Used Mobile PKI called Mobile ID was introduced in May 2007 by the largest mobile operator EMT. Although take-up of Mobile ID has not been very rapid, user satisfaction is high. The general policy has been to accept the eidcard and Mobile-ID equally. Finland Abandoned The so called multiplatform eid, which refers to the use of the FINEID in a SIM format card with mobile telephone interface, has been terminated in the autumn of 2008 due to lack of public interest and apparently high operational costs. France Not under consideration N.A. Germany Not under consideration N.A. Greece Not under consideration N.A. Hungary Not under consideration N.A. Iceland Not under consideration N.A. Ireland Not under consideration N.A. Italy Not under consideration N.A. Latvia Not under consideration N.A. Liechtenstein Not under consideration N.A. Lithuania Used Two major Lithuanian public mobile operators UAB Omnitel 20 and UAB Bite Lietuva are also providing a service based on the use of qualified digital mobile esignature to the public. Malta Not under consideration N.A. Luxembourg Not under consideration N.A. The Netherlands Used Supported as a part of the DigiD identification scheme (2 nd level of this scheme), using SMS. A private authentication provider (Diginotar) has announced it will also start offering mobile ID, called EazyID in 2009 21. Norway Used Mobile phone identification is available as a 20 In the case of Omnitel, the operator functions as a RA on behalf of the Estonian CA AS Sertifitseerimiskeskus. 21 http://www.diginotar.nl/producten/themas/eazyidmobile/tabid/1217/default.aspx Page 78 of 228

part of the Buypass and BankID schemes. Poland Used At the end of 2008 the MobiTrust 22 company activated services for mobile qualified electronic signatures. A mobile esignature is created using SIM cards and mobile phones. Portugal Not under consideration N.A. Romania Not under consideration N.A. Slovakia Not under consideration N.A. Slovenia Used Mobile signatures are offered by the MOBITEL operator; the service was only recently introduced, and take-up is therefore limited so far. Spain Not under consideration N.A. Sweden Not under consideration N.A. Turkey Used As of May 2009 two mobile e-signature infrastructures have been completed and users can create legally binding e-signatures using their SIM cards. United Kingdom Not under consideration N.A. Generally, the table above shows that mobile phone based identification is still only used at a relatively small scale, and that several countries are still largely at an experimental stage: A clear majority of 21 out of 32 countries are not using mobile phone identification and have no plans to change this in the near future; Two countries (Croatia and Denmark) are planning to deploy mobile signatures in the near future; Inversely, two countries (Austria and Finland) had mobile phone based identification solutions in place in the 2007 edition of the study, but these were abandoned in 2008. In the case of Finland, high operational costs were indicated as the reason for the shutdown; whereas Austria has replaced its system with a new approach which uses qualified certificates in which a hardware security module (HSM) managed by the operator functions as an SSCD storing the cryptographic keys, making the solution an application of the generic Austrian citizen card concept resulting in qualified signatures. Users can create signatures using their secret PIN codes, which are used to decrypt and trigger the private key for the electronic signature. Possession of the corresponding mobile phone is proven by a transaction number (TAN) sent via text message (SMS). This procedure ensures that the private key is under the sole control of its owner. The service provider is A-Trust, and the functionality can be integrated into any existing mobile phone. o Eight countries (Austria, Estonia, Lithuania, the Netherlands, Norway, Poland, Slovenia and Turkey) have mobile phone based identification solutions available. However, it is interesting to note that only two of these (the Netherlands and Norway) are clearly profiled as multifactor authentication solutions, whereas the other six are in fact presented primarily as signature solutions. In the first case, the mobile phone is used simply to support two-factor 22 See: http://www.mobitrust.pl. Page 79 of 228

authentication, with an SMS providing a time restricted password to allow the end user to log on to a specific service. The second approach, which is e.g. seen in Estonia and Lithuania, requires a SIM-card which is PKI-enabled, thus allowing the SIM-card to act as a signature creation device. In these two examples (and also in the Austrian example commented above), the certificate was labelled as qualified, and the SIM-card was considered to meet the requirements of an SSCD (although without having been formally assessed as such). These specific examples are also of interest because it is an example of cross border services, with the Estonian CA SK being one of the certificate issuers for both examples (other CAs are active in this domain in Lithuania as well). In addition, it is noteworthy that the mobile phone operator s registration process was not considered trustworthy enough by default, and that the user therefore needs to activate the signature solution using his/her eid-card in a web environment. In this manner, the service provider noted that the issuance of the Mobile-ID became implicitly bound to the security and quality of the ID-card. Page 80 of 228

4.2 Authentic source principle This section will summarise briefly which countries subscribe to an authentic source principle (i.e. the policy that each specific identity attribute should have one and only one authentic source, making all other sources for that attribute obsolete), and to what extent that this principle has impacted their identity management policies. This is relevant from a cross border interoperability perspective, because a consistent application of the authentic source principle means that a single correct source exists for each bit of information, which can facilitate the access and exchange of this information. The status is reported in each country as: Not accepted: no steps have been taken towards adopting the principle in any form yet; Under consideration: while no specific policy has been adopted yet, the potential benefits of the authentic source principle or an equivalent policy is being considered for the future, but without specific plans as of yet; Planned: while no specific policy has been adopted yet, plans are being drafted to adopt the authentic source principle or an equivalent policy in the future; Informally accepted: a policy decision has been made expressing a preference towards an authentic source principle or towards a set of guidelines that are equivalent to the authentic source principle, but without any formal commitment to the principle; and Accepted: a formal policy decision has been made to observe the principle in the country s administrative organisation. Country Status (Accepted / not accepted) Austria Not accepted No formal adoption. Description / Details Belgium Accepted Authentic sources (e.g. the National Register) are identified by law, and their (re-)use by public administrations is mandatory. Bulgaria Planned Enshrined in the draft egovernance Act, which has not yet entered into force. Croatia Not accepted No formal adoption. Cyprus Not accepted No formal adoption. Czech Republic Under consideration Several draft acts have been proposed, but none have been accepted yet. Denmark Not accepted No formal adoption. Estonia Accepted Improving access to authentic sources was one of the goals of the eid card project. Finland Accepted Generally accepted for base identity registers (mainly the Population Information System), although data sharing between national and local governments is not yet optimal. Page 81 of 228

France Accepted The National Register functions as an authentic source of civil status information. Germany Not accepted No formal adoption. However, under the 2007 Personal Status Law (Personenstandsgesetz) data storage in electronic form in civil status registers (Personenstandsregister) is allowed as of January 2009. Structured data exchange on the basis of an XML schema "X-Personenstand" is under development. In 2014, electronic data storage and exchange will be the obligatory procedure to maintain civil status registers. Greece Not accepted No formal adoption. Hungary Not accepted No formal adoption. Iceland Not accepted No formal adoption. Ireland Accepted All personal information relating to the PPS number is stored in a central authentic database (the Public Service Identity (PSI)). In early 2009 the Department of Finance initiated a project to build a central identity repository which will locate matches within and between the various data sources and create master records each linking to one or more records from the sources. Italy Not accepted Not formally adopted; however, Italian egovernment services can use the INA ( Indice Nazionale delle Anagrafi )-SAIA ( Sistema di Accesso e di Interscambio Anagrafico ) system. The INA system is an application for the exchange of citizens data between Municipalities and other public authorities. The identification of the citizen on all databases of the public administration is guaranteed by the Fiscal Code. INA does not contain citizen s personal data that are kept exclusively by the Municipality where the citizen is registered, but only the minimum data that allow the public authorities to find such personal data and to know where (i.e. in which local database) they are. SAIA operates on top of INA, since it is the architecture that allows the exchange of information between Municipalities and other public authorities. Latvia Not accepted No formal adoption. Liechtenstein Planned Will become a part of future eidm policy in Liechtenstein. Lithuania Accepted The main state registers together with the related registers form the system of registers of Lithuania. The core of the system of registers is their interaction. As regards the system of registers, an authentic source principle applies as the data of related registers may not be repeatedly collected from the primary sources and registered. Page 82 of 228

Luxembourg Informally accepted No formal adoption, but implicit through the Répertoire general, which contains the official identity data for natural and legal entities. Malta Planned The authentic source principle is one of the pillars of Maltese IDM plans for the future The Netherlands Informally accepted No formal adoption, but implicit through the Municipality Basic Administration, which contains the official identity data for natural entities who are registered as residents in the Netherlands. Norway Informally accepted Taken up through horizontal integration of identity resources, inter alia through the registry with the Brønnøysund Register Centre Poland Informally accepted The State Informatisation Plan for 2007-2010 envisions interlinking existing identity databases, therefore establishing single authentic sources of the data concerning natural and legal persons. Portugal Informally accepted A central database containing attributes of eid card holders is considered to contain authentic information (Instituto da Tecnologia da Informação na Justiça (ITIJ) - Sistema de Gestão do Ciclo de Vida de Cartão do Cidadão) Sistema de Gestão do Ciclo de Vida de Cartão do Cidadão -, which contains a key set of authentic attributes for citizens registered in it. The attributes stored in the authentication certificate of the eid card are obtained directly from the ITIJ, the other data being collected from: (a) the Identification Services (Serviços de Identificação Civil da Direcção-Geral do Registos e Notariado) in relation to the identification number ; (b) regarding the tax number, from the Tax authorities (Direcção-Geral de Contribuições e Impostos); (c) regarding the health number, from the Ministry of Health (Ministério da Saúde); (d) data referring to the Social Security, from the Social Security (Segurança Social). Romania Not accepted N.A. Slovakia Not accepted N.A. Slovenia Informally accepted Informal adoption through the SEP2010 Action Plan. Spain Informally accepted Informal adopted through the so called unique counter (ventanilla única) Sweden Informally accepted Generally accepted for base identity registers on different levels that most often are derived from the central national population register. Excerpts from this register is also available to private entities under specific regulations. Turkey Informally accepted The MERNIS database constitutes a de facto authentic source of population data. Page 83 of 228

United Kingdom Informally accepted Informal adoption through horizontal integration of identity sources. Formal acceptance of an authentic source principle is thus altogether uncommon, and was reported in only 6 countries out of 32 (19%), virtually equal to the 2007 edition of the study (5 out of 32). A further 10 countries (31%) had informally adopted the principle (as compared to 9 in 2007), with another 3 (10%) planning to do so (idem as in 2007). However, most countries do not fall cleanly into a specific category, especially when no decision has been made with regard to authentic sources, but where local practices mean that there is a de facto authentic source for identity information. This is e.g. the case in Portugal or Spain, where no specific formal decision has been made, but where specific identity sources none the less function largely as authentic sources. Generally, the table shows that 60% of countries have formally or informally decided to adhere to the authentic source principle, or are planning to do so. As the quality of the underlying identity infrastructures continue to improve, this number can be expected to rise, which could prove to be enabling to cross border authentication, as it would become easier to obtain accurate identity information or to verify it. Page 84 of 228

4.3 Authentication security existing systems and policies This section will describe for each of the surveyed countries what kind of systems are commonly used to authenticate specific entities. 4.3.1 Authentication policies Many countries have embraced multiple authentication systems (login systems, two factor authentication, soft PKI systems (i.e. PKI certificates which are not stored on a fixed hardware token), eid cards,...), some of which may be more secure than others. This can be a strong point of a country s eidm policy, as it allows public authorities to define multiple security levels which correspond to a specific authentication method, and to require an application to use a specific security level. Such authentication policies can assist in rationalising a country s eidm policies, as it gives application owners an objective standard against which they can measure their security needs, and allows them to select the appropriate authentication means. This section will briefly describe if each of the surveyed countries has formally or informally adopted an authentication policy to assess the security/reliability of its eidm systems, and what form such a policy takes. A policy is considered to be formally adopted if a specific government decision has been made to embrace the policy and to use it in practice; whereas a policy is labelled as informally adopted if it is occasionally quoted without any formal government support or systematic impact in practice. Country Status (Formally adopted / Informally adopted / Non-existent) Description / Details Austria Formally adopted The Austrian egovernment Act strongly emphasises the citizen card concept based on qualified signatures as the only security level. Thus, one level (the citizen card) is explicitly recognised. Belgian Informally adopted The federal public service for ICT (FedICT) acknowledges 23 that there are two tiers of authentication for natural persons: Bulgaria Non-existent N.A. Where security is advised but not crucial, username/password systems should be used. Where security is crucial, either the federal token or the national eid card should be used. Croatia Non-existent There is a legal requirement (Regulation on the scope of operations, content and responsible authority for operations of electronic signature 23 See http://www.fedict.belgium.be/fr/informatisation_etat/de_basis/gebruikersbeheer/index.jsp Page 85 of 228

Cyprus Non-existent N.A. Czech Republic Non-existent N.A. certification for state administration bodies) that requires the use of FINA s certificates in the development of egovernment applications that use electronic signatures. However, this is strictly speaking related to signatures, and not to authentication. Denmark Formally adopted A policy was created and confirmed as a public sector recommendation in 2005, based on the US Government E-Authentication Guidance for Federal Agencies 24. It establishes and describes four levels of identity assurance: little confidence, some, high, and very high. Estonia Non-existent No system currently exists; however, it is expected that a project will be launched in 2009 which will develop assessment methods and criteria for assessing different (foreign) eids. Most probably, a system of authentication levels will be developed and endorsed that would cover both domestic and foreign eids. Finland Informally adopted A four level system exists, but is not formally adopted by application owners. France Formally adopted A three tier system has been formally adopted through the General Security framework of reference (référentiel général de sécurité) 25, which distinguishes three levels: middle (indicated as * ), strong/standard ( ** ) and strengthened ( *** ). The level of security required for each service offered is defined by the public authority providing the service; this principle (gradual security principle) is also formally endorsed by the CNIL (the National Data Protection Authority). Germany Non-existent No nation-wide eidm system exists yet; the issue is therefore premature.. Greece Informally adopted An informal two tier system can be deduced, the first based on a username/password system; the second using the Syzefxis PKI system. Hungary Informally adopted A four tier system has been referred to in policy documents; but there is no formal consequence to this. 24 The US policy regarding E-Authentication Guidance for Federal Agencies is communicated in memorandum M-04-04 from the Office of Budget and Management, December 16, 2003 25 Decree nº2007-284 of 2 March 2007 on Interoperability general frame of reference [relatif au referential general d interopérabilité], J.O. nº 53 pf 3 March 2007, page 4060. Based on version 0.98 of the RGS available on the website http://www.references.modernisation.gouv.fr/rgs-securite. Page 86 of 228

Iceland Non-existent N.A. Ireland Non-existent N.A. Italy Informally adopted De facto, a two level system is used, where lower security applications use usernamepassword systems; and higher level systems are based on one or more smart card solutions. Latvia Non-existent N.A. Liechtenstein Non-existent N.A. Lithuania Non-existent N.A. Luxembourg Non-existent N.A. Malta Informally adopted Maltese authentication plans revolve around a three tier system (above public access): Level 1: restricted authentication (login, password and PIN); Level 2: confidential authentication (digital certificate); Level 3: maximum authentication (qualified digital certificate). However, only Level 1 is currently deployed. The Netherlands Informally adopted An three tier system can be deduced from the DigiD scheme, the first based on the DigiD username/password system, the second on the mobile phone assisted two factor authentication system; and the third using the future eid card ENIK as a PKI device. However, it is unclear whether this third level will be developed in the future. Norway Formally adopted A fairly detailed informal policy has been adopted through the Strategy on eid and e- signature in the Public Sector policy document. This document describes a four level security system, keeping into account registration requirements, management policies and potential risks. This system has been referred to in related legislation. Poland Informally adopted The Ministry Council approved (on May 26th 2009) the project worked out by the Ministry of the Interior and Administration, proposing a new method for administration clientsauthentication so called trusted epuap profile ( zaufany profil ), a password solution to enter the electronic platform of public administration(e-puap 26. The trusted epuap profile will include at least: name and surname, PESEL, login name, e-mail address. Globally, qualified signatures can be considered as the top tier, with password solutions taking a 26 Trusted epuap profile the set of information identifying and describing an entity or a person who has epuap account, confirmed in a trusted manner by an authorized public administration entity. Page 87 of 228

Portugal Non-existent N.A. secondary role. Romania Informally adopted On the e-guvernare 27 website two means of authentication are mentioned: qualified signatures are considered as the top tier, with password solutions taking a secondary role. Slovakia Informally adopted No formal system, but an informal three tier system can be deduced (username/password, qualified signature with prior personal identification, and qualified signature with a unique identifier in the certificate). Slovenia Informally adopted An informal three tier system has been adopted (direct input of personal data, username/password, and qualified certificates) Spain Informally adopted An informal three tier system can be derived (username/password, two factor authentication with a random password, and authentication certificate) Sweden Non-existent High standardisation (through the bank issued eids) makes multilevel policies largely unnecessary. Turkey Informally adopted The egovernment Gateway project implies the recognition of a three tier system: login based on unique ID number, two factor authentication using a random string, authentication certificate. United Kingdom Formally adopted The UK government s Strategic Action Plan distinguishes a number of authentication means based on damage risks through the Registration and Authentication - e- Government Strategy Framework Policy and Guidelines Version 3.0, but does not implement a strict hierarchy between these. Thus, in 18 out of 32 countries (56%) some form of multilevel authentication policy can be recognised, which is an increase of 3 countries compared to the 2007 edition of the study. This could be indicative of an increasing professionalization/consolidation of eid infrastructures, as it shows that more countries are becoming aware of the need to differentiate between existing eid solutions on a transparent and consistent basis. However, the number of formally adopted authentication policies remains very limited, being in place in only 5 out of 32 countries (versus 4 in 2007), namely Austria, Denmark, France, Norway and the UK) can a formal authentication policy be identified. In addition, it is interesting to observe that a number of countries indicate that the concept of a qualified signature is considered to be the highest level of authentication, with anything else being considered a lower level. This was observed e.g. in Austria, Italy, Malta, Poland, Romania, Slovakia, and Slovenia. Thus, the status of a qualified certificate is also used de facto as a quality label in an authentication context. It is clear that this opens certain perspectives in relation to interoperability, as the concept of a 27 See http://www.e-guvernare.ro/default.aspx?langid=1 (this section is available only in Romanian) Page 88 of 228

qualified certificate is a European one, meaning that at least this top level of an authentication policy could be applied in a cross border context without much additional effort. From a practical perspective however, in most of these countries the acceptance (formal or informal) of an authentication policy has had a limited impact on the use of the applications, in the sense that the policies are mainly used as internal guidelines for policy discussion, rather than as classifications that application owners can use to determine the required authentication levels. This is however not always the case, as can be seen in France and Norway, where the importance of available policies is strengthened through supporting legislation referencing its concepts. Thus, the practical impact of authentication policies has been relatively limited thus far. It is worth noting that all authentication policies are currently focused on nationally available solutions, with only one country Estonia noting its ambitions to launch a project to develop assessment methods and criteria for assessing different eids, including foreign ones, likely through a formalised system of authentication levels. Page 89 of 228

4.3.2 PKI based systems Having examined the prevalence of authentication policies, we will next examine the countries which have deployed some form of PKI system to authenticate a group of entities as a key part of their eidm policy. Only functioning systems are described; not planned ones. As noted above, it is not uncommon for a signature certificate to be used to achieve authentication functionality. When the correspondent has reported that such signature certificates are used as an important means of entity authentication, such certificates have also been included in the tables below. A distinction is made between public sector controlled PKI systems and public/private partnerships. For the purposes of this report, the distinction lies in the allocation of the function of the registration authority who verifies the identity of the party requesting the PKI token. It should thus be noted that it is perfectly possible (and in fact quite common) that a system is classified as public sector controlled in the tables below despite the fact that the certification authority is a private entity. The reason for this distinction lies in the fact that offline authentication tends to rely on documents that originate from public sector bodies. In offline situations, the trust that is accorded to such documents does not depend on the actual producer of the document (which might e.g. be a private sector printing company which does not enjoy any specific trust relationship), but rather on the fact that the verification and issuing procedure is in the hands of a public sector body. For the same reason, this is the criterion that was also withheld for these systems. For the same reason, the tables also indicate the entity which issues the authentication token. In order to determine the scope of each token, the tables also indicate whether or not the PKI system is accessible to private sector partners, i.e. whether the token, hardware and middleware has been designed with use by private sector partners in mind, or whether the PKI system was only designed for use within one or more specific egovernment applications. This is of course relevant because systems which are open to uptake in the private sector should also be usable by foreign public authorities, i.e. there is no imperative legal/policy objection towards cross border use (although technical considerations might still be a barrier). Page 90 of 228

4.3.2.1 Public sector controlled PKI systems Country Description Entity issuing the authentication token Belgium Croatia Estonia Finland France Authentication certificate in the eid card Authentication certificate on a smart card (FINA eid card) Authentication certificate on the CIHI (health care) card Authentication certificate in the eid card Authentication certificate in the eid card FINEID Authentication certificate in the Daily Life card Greece Syzefxis system for civil servants using signature certificates, either on smart cards or as soft certificates Hungary Education cards containing signature certificates (only for teachers and administrators; not for students) Issued through communes upon identification in person. Financijska agencija (FINA), the Croatian Financial Agency Croatian Institute for Health Insurance Citizenship and Migration Board (CMB) Issued through local police stations. Local authorities The appropriate Ministry, depending on the civil servant. Minister of Education Iceland Soft authentication certificates A number of administrations, including the Tax Revenue Directorate and the Directorate of Customs. In the future, bank issued smart cards will contain both signature and authentication certificates. Italy Authentication/ attestation certificate in the eid card Authentication/ attestation certificate in the CNS card Authentication or signature certificate in the CMD (public servant card) Issued through municipalities upon identification in person. Depends on the local authority who has decided to issue the card The issuing civil service (depends on the card; e.g. Ministry of Defense) Latvia Authentication and qualified State Revenue Service. Yes. Accessible to private sector? Yes, through freely disseminated software modules. Yes. No. Yes. Yes. No. No. No. Yes. Yes. No. No. Page 91 of 228

Liechtenstein Lithuania certificates in private sector smart cards Authentication certificate in the eid card Authentication certificate in the eid card Authentication certificate in the Civil servant eid card Malta Soft nonqualified signature certificates Portugal Authentication certificate in the national eid card Slovenia Qualified signature certificate containing a unique identifier linked to a database managed by the Ministry Spain Authentication certificate in the national eid card (or electronic residents card in the future) Signature certificates issued by certain publicly controlled accredited CSPs, either soft or on a smart card. Requires a passport to request. Issued through communes upon identification in person. Issued through communes upon identification in person. The issuing civil service (depends on the card). Maltese government; see http://repository.ca.gov.mt INCM (Portuguese Mint) Certification authority at the Ministry of Public Administration eid card Technical Office (Oficina Técnica del DNI electrónico) FNMT (Spain s Royal Mint); CATCERT (Certification Authority of the Regional Government of Catalonia); IZENPE (Certification Authority of the Regional Government of the Basque Country); ACCV (Certification Authority of the Regional Government of the Valencia Region) Turkey Soft authentication certificates Ministry of Justice No. Yes. Yes. Yes. Yes. Yes. Yes. Yes (several banks have announced their take-up of the eid card). Typically yes. Page 92 of 228

4.3.2.2 Public / private partnerships Country Description Issuing entity Accessible to private sector? Austria Qualified signature certificate in Citizen Card Belgium Bulgaria Czech Republic Denmark Qualified and nonqualified software signature certificates Signature using qualified soft certificates Signature using qualified certificates (either soft (the typical case) or exceptionally on a smart card) Signature using qualified certificates (either soft (the typical case) or exceptionally on a smart card) OCES advanced electronic signature (soft certificate; may include hardware token in the future) Depends on the implementation of the Citizen Card Recognised CSPs (all Belgian in practice) CSPs registered at the Bulgarian Communications Regulation Commission Recognised CSPs. The certificate contains the social security number, which is used for authentication purposes Recognised CSPs. The signature is used to sign an electronic document containing other unique identifiers, such as the personal identity number, which is then used for authentication. TDC, a recognised private CSP. The certificate contains a unique identifier, which is linked to the national register number (CPR number) for natural persons; but the CPR number cannot be directly derived without a mandate by law. Estonia Mobile-PKI/Mobile-ID PKI system based on mobile phones, as described in section 4.1.5. Iceland Authentication certificates under a common Icelandic Root (Íslandsrót 28 ) hierarchy France Authentication certificate in the Vitale card Currently only one CSP has been authorised to issue certificates: Auðkenni hf, a company in the financial sector. Health insurance funds. The identification number is the ADELI and/or SIRET number. Yes. Private sector partners can also issue Citizen Cards. Yes. Yes. Yes. Yes. Yes. Yes. Yes. Yes. 28 www.islandsrot.is Page 93 of 228

Liechtenstein Certificates issued by A- Trust (Austria) for use within the National Public Administration Lithuania Qualified signature certificates, either soft or on a smart card. The Netherlands Mobile-PKI/Mobile-ID Certificates issued under the PKIoverheid (http://www.pkioverheid.nl/), trust infrastructure for CSPs which meet certain quality requirements. Norway Authentication and signature certificates (qualified and nonqualified) issued by private CSPs. These can be stored on smart cards or server side. Poland Qualified signature certificates, either soft or on a smart card. Portugal Qualified soft signature certificates for lawyers, solicitors or notaries public. Romania Qualified and nonqualified soft signature certificates Slovakia Qualified soft signature certificates, issued after personal identification (since certificates may not use the birth number) Slovenia Qualified signature certificate; usually containing an official identifier (like the tax number or the Personal Registration Number) Spain Qualified signature certificate, soft or on a smart card, following prior Austrian CSP A-SIT Three qualified CSPs are presently available in Lithuania PKI system based on mobile phones, as described in section 4.1.5. A number of private CSPs. A number of private sector partners, including certain banks (notably Buypass and members of the BankID group) Three qualified Certification Authorities in Poland: Certum (www.certum.pl), Sigillum (www.sigillum.pl.com.pl) and Szafir (www.kir.com.pl) The Ordem dos Advogados (Lawyers Bar Association,) the Câmara dos Solicitadores (Solicitors Association) and the Ordem dos Notários (Notaries Order). Private CSPs Trans sped, Certsign, Digisign and Internet DomReg Accredited private sector CSPs Three accredited private sector CSPs Accredited and recognised CSPs Yes Yes Yes. Yes Yes Yes Yes Yes Yes Yes Yes Page 94 of 228

personal identification. Uses the national identifier. Sweden Advanced certificates, either soft or hard. Two separate certificates on each token, one for authentication and one for signature. Issuance based on a compulsory prior identification in person and information in national population register. Turkey Qualified signature certificates on a smart card. Mobile-PKI/Mobile-ID United Kingdom Soft qualified signature certificates Certificates issued by private sector partners (eight banks in a consortium forming BankID, the Nordea bank, the telecom company TeliaSonera and the computer company Steria). The National Swedish identity card issued by the police (deployed but still not fully initiated for electronic use). Four accredited CSPs. PKI system based on mobile phones, as described in section 4.1.5. British Chamber of Commerce and Equifax Yes. Yes Yes. Yes. 4.3.2.3 Conclusions with regard to PKI based authentication systems Based on the tables above, the following conclusions can be drawn: A total of 17 countries out of 32 (53%, 3 more countries than in 2007) reported using public sector controlled PKI systems as defined above, with a total of 22 systems being reported (+6 compared to 2007). Of these 22 systems, 15 were open to private sector use (68%). 20 countries out of 32 (62,5%, 4 more countries than in 2007) reported using public/private sector controlled PKI systems as defined above. Given the involvement of the private sector, it is unsurprising that all of these could also be used in the private sector. Combining both tables, a sizable majority of 27 out of 32 countries (84%, three more than in 2007) have reported using PKI systems (either public or public/private controlled) for the purposes of entity authentication. It is important to note that the public sector controlled PKI systems which were not open to private sector use are only certificates or smart cards which have been issued for a very specific user group (such as civil servants) or for use within a very specific sector (such as a specific ministry/department). All of the general eid cards deployed so far (see section 4.1.1.6.) are open to private sector use without further restriction. This is relevant from an interoperability perspective on account of the large number of countries presently deploying/planning to deploy such eid cards: there is no objection in principle to the cross border use of such authentication means. Thus, the number of PKI systems which is open to private sector use (and thus also to cross border use) can be expected to increase as the number of eid cards increases. A secondary conclusion is that, at least for PKI systems, private sector involvement has the interesting side-effect of improving interoperability, as the systems by definition have been developed with a broad use in mind, and are not inherently restricted to use within one or several services. Page 95 of 228

4.3.3 Non-PKI systems It goes without saying that electronic authentication is not the exclusive domain of PKI systems. Especially for applications or services where openness and simplicity are seen as more important needs or where a sufficient infrastructure is in place to ensure the security of such systems, username/password systems (including through two factor authentication and time specific password calculators) remain very popular. The overview below will indicate which systems of this kind are in use in the surveyed countries. In each case the overview will indicate what type of login password is used (classified as Single factor (username/password) / Multifactor password list / Multifactor - password based PIN calculator / Multifactor mobile phone); who issues the credentials and/or the token, and whether or not the system is accessible to private sector parties. The latter is of course less common than with PKI systems, and will mostly be the case if the system is controlled by private sector entities. The following countries have been found to have deployed some form of login/password system to authenticate a group of entities as a key part of their eidm policy. Only functioning systems are described; not planned ones. Country Description Entity issuing the username/password or password generation token Belgium Multifactor password list (federal token: using username, password and random string from a paper token) Croatia Single factor (username/password) systems in a number of smaller applications Cyprus Single factor (username/password) TAXISnet, based on prior personal identification before a local office Czech Republic Estonia Single factor (username/password) system where credentials are issued after signing an application form with a qualified certificate Multifactor password list, using username, password and random string from a paper token Multifactor - password based PIN calculator Belgian federal government, after application through the federal portal site. Depends on the application Inland Revenue Department Depends on the application (e.g. Czech Social Security Administration, Ministry of Agriculture) Estonian banks Estonian banks Accessible to private sector? No. No No No. Yes (managed by banks). Currently used more often than national eid card. Yes (managed by banks). Currently used more often than national eid card. Page 96 of 228

Finland Multifactor password list, using username, password and random string from a paper token Greece Single factor (username/password) TAXISnet, based on on-line identification using the tax number and ID card number Single factor (username/password) E-KEP platform, based on on-line identification Hungary Single factor (username/password) - Client Gate; based on prior personal identification or identification through an electronically signed 29 document Iceland Single factor (username/password) used in several applications Ireland Single factor (username/password) - Reach Services portal, based on electronic registration using the PPS number, which is then authenticated against the PSI Latvia Multifactor password list in the eprocurement system, using username, password and random string from a paper token Single factor (username/password) - Electronic Declaration System (EDS), based on an electronic signature for requesting credentials Finnish banks that belong to the Finnish Bankers Association authentication service Tax authorities Citizen Service Centre. Accessible to non-nationals, since an ID card number is not mandatory Regional document offices. The requesting party must present a personal identity document, passport or driving licence. It is therefore accessible to non-nationals (with a passport) Depends on the application owner The Public Services Broker. Unknown State Revenue Service. Requires a passport to request. Yes (managed by banks). Currently used more often than national eid card. Uses the social security number as an identifier. Lithuania Multifactor password list, All nine commercial Yes (managed by No. No. No. No. No. No. No. 29 Using an advanced administrative certificate signature. According to the report, registrations using an advanced signature (rather than personal appearance) accounted for 68 out of 520.000 cases, or around 0.01%. Page 97 of 228

using username, password and random string from a paper token Multifactor - password based PIN calculator Luxembourg Single factor (username/password) systems; processes depend on the application Malta The Netherlands Multifactor password list using username, password and a PIN-code Single factor (username/password) systems; processes depend on the application Single factor (username/password) DigiD first level; requires a Social Security Number (or CSN since its introduction) Multifactor mobile phone - DigiD using mobile phone for two factor authentication Norway Single factor (username/password) and Multifactor - a variety of systems, sometimes simple, sometimes two-factor, including relying on SMS authentication. MyID (MinID) is the most prominent example, being based on a PIN code card. Portugal Single factor (username/password) - Citizen s Portal (Portal do Cidadão). Single factor (username/password) in a variety of tax/social security systems; requires a suitable identifier (e.g. tax number) Romania Single factor (username/password) in a variety of applications Lithuanian banks All nine commercial Lithuanian banks Used in a multitude of applications; issuer depends on the application Local council offices. Issued after verification in person of ID card. Used in a multitude of applications; issuer depends on the application GBO.Overheid (Gemeenschappelijke Beheerorganisatie) and the Dutch Tax Authorities. GBO.Overheid (Gemeenschappelijke Beheerorganisatie) and the Dutch Tax Authorities. Depending on the application provider. Note that some of these systems also include PKI based esignature functionality at higher security levels UMIC. Note that the system could be used by foreigners (it requires no information unique to Portuguese citizens), but the applications are geared towards local needs. Depends on administrating authority (e.g. Tax Department) Depends on administrating authority Slovakia Single factor Central Portal of Public No. banks). Yes (managed by banks). No (application specific) No. No (application specific). No. No. No No No No Page 98 of 228

(username/password) - Central Portal of Public Administration Slovenia Single factor (username/password) used in several applications Turkey Single factor (username/password) in various applications United Kingdom Single factor (username/password) via the Government gateway Administration Depends on the application owner Depends on application The Government gateway No. No No. In total, 22 countries out of 32 (69%) have reported using login systems as a key component of their eidm strategy (one more than during the 2007 study), with 28 systems in total being reported (+1 compared to 2007). Again, it should be repeated that the actual number of login systems is likely higher, and that a number of correspondents simply did not consider these systems to be a key component of their country s eidm strategy. In addition, some of the reported systems (like DigiD in the Netherlands or MinID in Norway) comprise multiple authentication possibilities. None the less, it should be recalled that 25 out of 32 countries (78%) reported the use of PKI systems, which are thus more likely to be emphasised as staples of a country s eidm strategy. Of the reported login systems: 20 were simple username/password systems, independent from any sort of material token or challenge/response system; 7 relied on multifactor authentication using a password list. 2 permitted the use of password calculators. Both of these (in Estonia and Lithuania) were bank authentication systems which the banks have opened up to public sector applications. It should be noted that such systems are quite popular; e.g. in Estonia the bank authentication system is significantly more popular than the eid card system using PKI certificates, despite the advanced status and highly secure nature of the eid card system. 2 countries reported the use of mobile phone based authentication systems, where SMS messages were used as a challenge-response system (the Netherlands and Norway). As was already noted above, mobile phone usage is also prevalent in other countries (notably Austria, Estonia, Lithuania, Poland and Turkey), but in these countries it is used and presented as an electronic signature solution, rather than an electronic authentication solution. The security of the used systems can thus vary widely: while some username/password systems have no specific innate security mechanism during registration, most of the systems above require the user to either provide a specific identifier during registration (e.g. TAXISnet in Greece), to appear personally to receive the credentials (e.g. TAXISnet in Cyprus), or allow the credentials to be requested using a PKI based signature system (e.g. the Client Gate in Hungary). Thus, while the use of a simple username/password system is inherently less secure than a system which also requires a material token (rather than solely knowledge of specific identification strings), registration procedures are in most cases secured against abuse. With regard to private sector uptake, login systems can logically be expected to be inaccessible to private sector parties (unless the system itself is controlled by a private sector party), as such systems inevitable require access to an underlying database for the provision of specific identity information. The table above confirms this expectation: only 5 of the 28 systems (18%) can be used in the private sector; and all of these are bank systems, i.e. the private sector in this case is simply the controlling bank itself. Page 99 of 228

From a European interoperability perspective, this is relevant for the reason that cross border use of login systems is thus inherently limited by the requirement of needing access to an underlying identity database, which is not necessarily the case for PKI systems, where the certificate can conceivably contain the required identity information itself. Thus, while login systems are more flexible (in the sense that issuing and use procedures can be easily tailored to local policy preferences and to the needs of specific applications), realising cross border interoperability is also inherently a more complicated matter. This is specifically the case when such login systems are controlled by public sector bodies, since cross border use would then require foreign applications to be able to obtain the necessary identity information from local official identity databases, which can be politically and legally very complicated. Page 100 of 228

4.4 Mandate management and authorisations The issue of mandate/authorisation management (determining the rights and responsibilities of a specific entity) is closely linked to the issue of identification (determining who an entity is). This is most apparent in the representation of legal entities: any form of identity management targeted towards legal entities implicitly requires a form of mandate management, since legal entities by definition must be represented by a duly authorised natural person. However, even outside the scope of the representation of legal entities, mandate management is a crucial issue. For the purposes of this section, we will examine which countries have integrated some form of mandate management into their eidm policies, defined as the ability to grant and revoke the permission to an entity to perform a clearly defined legal action on behalf of another entity. This can includes the representation of legal entities, the representation of tax payers by their accountants, or generally speaking any representation by a service provider of his/her client. In the table below, we will also examine the broader topic of role management or authorisation management. This distinction has been made because a number of countries have installed specific eidm systems for closed user groups, including doctors, lawyers, notaries public, civil servants of one or more departments, etc. These closed systems by definition entail a role management /authorisation component. Thus, this section examines both mandate management (the ability to grant and withdraw specific mandates to specific entities), and authorisations in general. All surveyed countries have been classified into one of three categories: None, i.e. no systematic form of mandate/authorisation management was reported to exist in that country; Ad hoc, i.e. a solution has been implemented for one or more application types, but no generic mandate management / authorisation solution exists; Systematic, i.e. a generic approach to the creation and revocation of mandates / authorisations has been implemented. This leads us to the following overview: Country Status (Systematic / Ad hoc / None) Description / Details Austria Systematic The Citizen Card concept allows signed XML structures to be stored on the card, which identify mandate giver, mandate holder and the terms of the mandate (which can be in free text form). How such mandates work in practice is a matter of implementation. Belgian Systematic (was: ad hoc) For specific sectors (e.g. ehealth), Belgium uses a system of sector specific service integrators which link specific mandates/authorizations to generic identification/authentication systems like the eid card. The service integrator will determine their mandate/authorization on the basis of authentic databases that it manages through a network of intermediaries (like e.g. hospitals). Bulgaria None The legal framework distinguishes between the author and the titular of a signature. For legal Page 101 of 228

Croatia None N.A. Cyprus None N.A. persons, a natural person can be chosen to be the author on behalf of a legal person who is then the titular. Both fields are included in the certificates being used. Czech Republic None Limited systems are in place that allow a natural person to represent a legal entity, using a sufficient authentication mechanism for the natural person and conditional upon providing evidence that the natural person is authorised to represent the legal entity. Denmark Ad hoc Authorization must be done through the receiving application/service, not via the certificate itself. It is thus up to the service provider to develop authorization systems if needed. These authorization systems are typically based on the identity gained through certificate information and other external or internal registers. Estonia Ad hoc (was: none) There is no generic system in place for handling mandates and authorisations. However, corresponding information is available over the X-Road secure network from corresponding registries. It is possible to find out whether the person is a CEO of the company or whether he is a medical professional by querying corresponding registry provided that access to that registry is granted. Finland None Limited systems are in place that allow a natural person to represent a legal entity, e.g. through the KATSO system. France None N.A. Germany None The S.A.F.E. Secure Access to Federated E- Justice/E-Government concept aims at the secure registration, authentication and authorization as well as the secure storage of communication participants 30. Implementation starts in 2009, production rollout in the area of E- Justice is scheduled for 2010. Greece None N.A. Hungary None N.A. Iceland Ad hoc Authorization must be done through the receiving application/service on an ad hoc basis. Employee certificates are available to natural persons in legal entities. In these certificates the 30 For details see: http://www.justiz.de/erv/grob- _und_feinkonzept/abstract_of_the_core_concepts.pdf Page 102 of 228

Ireland None N.A. Italy None N.A. legal entity is the subscriber but the employee is the holder of the certificate. The subject field in the certificates includes ID-number (SSN#) of the legal entity and the employee. Latvia None The Electronic Declaration System (EDS) can be used both by natural and legal persons, which is an implied mandate system. See below. Liechtenstein None N.A. Lithuania None N.A. Luxembourg None A few username/password systems allow a representative of a legal entity to be indicated, which is an implicit form of rudimentary mandate management. Malta Ad hoc Limited systems are in place, e.g. mandates can be given to accountants and tax consultants to file on-line tax declarations. A more extensive system is planned in the future. The Netherlands None N.A. Norway None Limited systems are in place that allow a natural person to represent a legal entity, including through the Altinn platform. Poland None N.A. Portugal Ad hoc In relation of the representation of businesses and namely for the issuance of the commercial CA certificate, the practice adopted in Portugal (by Multicert, the Portuguese certification service provider major player) is to require the presentation of legally and up-date companies certificates. Romania None N.A. In relation to some professions, such as lawyers and notaries, electronic authentication is made possible by the use of a digital certificate proving the professional quality of the user, as will be further explained below. These certificates are issued within the scope of the Ordem dos Advogados (Lawyers Bar Association) and the Ordem dos Notários (Notaries Order). Slovakia None Limited systems are in place that allow a natural person to represent a legal entity, by identifying the capacity of the natural person in a specific PKI certificate. Slovenia Ad hoc Limited systems are in place that allow a natural person to represent a legal entity, by identifying the capacity of the natural person in a specific PKI certificate. In addition, systems of mandating Page 103 of 228

are integrated within applications that allow other natural persons to represent legal persons. Spain Ad hoc Limited systems are in place, e.g. the recognition of collaborators by the Tax Agency. Sweden Ad hoc The framework agreements with the recognised issuers eids differentiate between several types of eids, including eids issued to groups, authority stamps and functions within a company, which is an implied form of mandate management. Another examples is Swedish healthcare, which is building up a general mandate management system based on general public personal eid cards. The name of the system is SITHS (Secure IT for health services). A healthcare CA is established for the country. Each hospital and clinics can act as RA issuing secondary certificates to be stored on the cards. These secondary certificates can carry information of place in organisation, mandates etc. Turkey None N.A. United Kingdom None N.A. The results can be summarised as follows: 22 countries out of 32 (39%) have no form of mandate/authorisation management, other than the allocation of certificates or credentials to the representatives of a specific legal entity. 8 countries out of 32 (25%) have implemented an ad hoc form of mandate/authorisation management covering specific applications or service types, most typically by supporting PKI certificates issued to specific user groups (e.g. lawyers certificates, doctors certificates), or by establishing or leveraging ad hoc administrative databases that link generic identifiers to a legal capacity. Only two countries have implemented systems of mandate/authorisation management which can be characterised as systematic: the Austrian open approach to mandates, and the Belgian systematic approach to authorisations. Austria has created a generic system of mandate management, relying on the central sourcepin Register Authority. In this system, Electronic mandates are XML records that hold the identifiers of both the constituent and the representative. The electronic mandate is signed by the sourcepin Register Authority and stored in the citizen card of the representative. The scope of such mandates is specific and explicitly given in the mandate. It can thus also be a general power of attorney, if this is stated as such. The XML structure contains a field Textual Description which describes the scope of the mandate, which can take any arbitrary content (human readable), essentially in the same way that a conventional paper mandate does. Depending on the complexity of this description and the context in which the mandate is being used, automatic recognition of such mandates may or may not be possible. An example of mandates that can be automatically recognised is power of procuration. With electronic mandates technical means to check its validity and to revoke mandates have been introduced. This is provided by a service of the sourcepin Register Authority that operates similar to and has been derived from the online certificate status protocol (OCSP). Thus, this system creates a true electronic equivalent of the traditional mandate. Page 104 of 228

The Belgian approach in contrast does not focus on such open mandates, but rather on a consistent approach to authorisations, based on the use of a Policy Enforcement Model 31. The Policy Enforcement Model basically operates by distinguishing the functions of identification, authentication, the verification of attributes and mandates, and authorisation. In this model, generic identification tools (such as eid cards) are used to identify or authenticate users. A Policy Enforcement Point will then determine the contact point (Policy Decision Point) should be consulted to determine whether the appropriate authorisation is available. The Policy Decision Point makes this decision by contacting an underlying database of authorisations, a so called Policy Information Point. A Policy Information Point could be managed by any organisation authorised to do so, including public sector bodies (like social security organisations), but also e.g. professional bodies of doctors, lawyers, accountants, etc. - Graphical representation of the Policy Enforcement Model, taken from http://www.kszbcss.fgov.be/documentation/fr/documentation/presse/annexe_catalogue_services_base_metiers.pdf - Portaal means Portal ; Authentieke Bron means Authentic source ; and Mandaten means Mandates - It should be noted however that both the Austrian and Belgian systems are operational, but are only taken up to a limited extent in egovernment applications at this stage. In conclusion, despite the fact that mandate management is considered to be an important component of identity management as a whole, most surveyed countries have not yet made significant progress in this field. 31 See http://www.kszbcss.fgov.be/documentation/fr/documentation/presse/annexe_catalogue_services_base_metiers.pdf for a description of this model. Page 105 of 228

4.5 Legal / policy analysis As has been described in the sections above, the surveyed countries take widely different approaches to electronic identity management, varying from a complete reliance on electronic signatures, to the use of authentication specific PKI infrastructures, reliance on mobile PKI systems, two factor authentication systems, and simple username/password systems. In this section, we will take a closer look at the legal and policy issues surrounding electronic identity management systems, based on the descriptions above and on the specific information provided in the country profiles. First of all, we will examine the applicable European legal framework, including the esignatures Directive 32, the Data Protection Directive 33, and the Services Directive 34. In each case, we will take a look at the basic principles of these frameworks, and at the way they have been applied in the Member States. Secondly, we will examine the national regulatory frameworks themselves, focusing on higher level policy choices, regarding the degree of (de)centralisation of electronic identity management in the surveyed countries, and with regard to national competences / constitutional issues. Thirdly, the issue of privacy protection will be examined in greater detail, as one of the major factors that can potentially impede the development of interoperable identity management systems. After all, a key fear is the notion that easily accessible cross border authentication could imply an increased access to personal data, which could potentially threaten the privacy of their citizens if insufficient measures are built in to determine who has the right to access and process such data. We will also examine the choice of unique identifiers (if any) in each of the surveyed countries, and their legal status as protected/restricted/unprotected information. Finally, we take a look at any authentication policies in the surveyed countries, i.e. at the question of how countries distinguish between the reliability of multiple authentication systems, and if any formal criteria have been officially adopted to distinguish between such systems. The data presented in the aforementioned sections will serve as a key input for each of these issues. 32 Directive 1999/93/EC of the European Parliament and of the Council of 13 December 1999 on a Community framework for electronic signatures; see http://eurlex.europa.eu/lexuriserv/lexuriserv.do?uri=celex:31999l0093:en:html 33 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 and on the free movement of such data; see http://eur-lex.europa.eu/lexuriserv/lexuriserv.do?uri=celex:31995l0046:en:not 34 Directive 2006/123/EC of the European Parliament and of the Council of 12 December 2006 on services in the internal market; see http://eurlex.europa.eu/lexuriserv/lexuriserv.do?uri=celex:32006l0123:en:not Page 106 of 228

4.5.1 The European legal framework For the purposes of this Study, the key European legal texts with regard to electronic identity management are considered to be: the esignatures Directive, as the main source of regulations with regard to certification services. This is important, since PKI systems are increasingly becoming a standard identity management solution. the Privacy Directive, as the main source of regulations with regard to the processing of personal data, including unique identifiers. This is important, since privacy issues are often quoted as one of the main barriers to the implementation of an interoperability framework. The Services Directive, as it requires Member States to provide a single contact point where non-national entities aspiring to provide services abroad can electronically meet any requirements relating to the access and exercise of any service activity covered by the Directive. This implies a de facto obligation to foresee an electronic authentication mechanism which is accessible from abroad. The role of electronic signatures in this process is particularly important, and will be examined in greater detail below. For each of these texts, the sections below will examine the basic principles, applicability to the electronic identity management issues, and trends and key examples of their interpretation in the Member States. 4.5.1.1 esignatures Directive Principles and applicability Scope of the Directive PKI, signatures and entity authentication The exact scope of the esignatures Directive, including its potential applicability to entity authentication, is a matter of continued debate. Essentially, the key problem revolves around the interpretation of the notion of a signature. While the Directive defines an electronic signature as data in electronic form which are attached to or logically associated with other electronic data and which serve as a method of authentication (article 2.1), this does not resolve the essential conflict between two contrasting schools of thought. A first school of thought holds that, at least with respect to the legal effects of electronic signatures (article 5 of the Directive), the main goal of the Directive was to create a harmonised set of rules to asses the value of electronic signatures as the digitised equivalent of a handwritten signature, and to determine when the employed technological solution indeed resulted in a legal equivalent (i.e. an interpretation favouring a strong link between the traditional legal concept of a signature and the technical signature process). According to this interpretation, the impact of the Directive on the process of using PKI technology as a system for entity authentication is limited, due to the fact that the legal effect of a signature as a mechanism for entity authentication is entirely undefined in the Directive, as article 5 does not apply. A second school of thought holds that the Directive as a whole regulates the use of digital signatures as a technology in general, and that its application covers virtually any possible use of a PKI system. This interpretation is supported by the fact that the Directive defines the notion of a certification-service-provider in general as an entity or a legal or natural person who issues certificates or provides other services related to electronic signatures ; i.e. a relation to electronic signatures is sufficient, regardless of the actual application. For this Page 107 of 228

reason, the Directive is also applicable to e.g. digital archiving and timestamping services; and it can be argued that PKI services used for the purposes of entity authentication (a very common solution, as shown in section 4.2.1. above). It is clear that the designation esignatures Directive is somewhat misleading, or at least ambiguous with regard to its exact scope. In the sections below, we will examine if and how the Directive applies to identity management. Applicability to the issue of identity management The key issue question with regard to the applicability of the Directive is whether or not entity authentication services (including specifically those relying on PKI methods) are covered by the Directive, and if so, what the result would be. In order to determine the value of the Directive for the purposes of identity management, the key provision is the clause with regard to the legal effect of an electronic signature (article 5). With regard to the legal value of an electronic signature, the Directive creates a tiered system: Article 5 - Legal effects of electronic signatures 1. Member States shall ensure that advanced electronic signatures which are based on a qualified certificate and which are created by a secure-signature-creation device: (a) satisfy the legal requirements of a signature in relation to data in electronic form in the same manner as a handwritten signature satisfies those requirements in relation to paper-based data; and (b) are admissible as evidence in legal proceedings. 2. Member States shall ensure that an electronic signature is not denied legal effectiveness and admissibility as evidence in legal proceedings solely on the grounds that it is: - in electronic form, or - not based upon a qualified certificate, or - not based upon a qualified certificate issued by an accredited certification-service-provider, or - not created by a secure signature-creation device. In accordance with this system, a so-called qualified signature (article 5.1) is considered the equivalent of a hand-written signature; whereas other types of electronic signatures (article 5.2) may not be denied legal value on the grounds of their electronic character. As noted above, the first paragraph has no real meaning for the purposes of entity authentication: a handwritten signature as such (i.e. distinct and separated from its context) has never been considered a sufficient method of demonstrating the identity of an entity. As a result, legal equivalence to a handwritten signature does not address the legal effect of an entity authentication process. Similarly, the second paragraph merely introduces a non-discrimination principle, so that the only legal effect on PKI based authentication systems would be that the system should not be considered legally ineffective as such. In short, article 5 does not contain any provisions that allow an electronic signature as such to be granted any specific entity authentication value. It is thus important to be aware that the legal framework for electronic signatures does not solve the key question of authentication: who is the person with whom I am communicating, and how do I know Page 108 of 228

this for certain? This is an issue which is not resolved by the Directive, which assumes a prior resolution of the identity question without offering specific guidance. This is also clear in the definition of an advanced electronic signature (article 2.2), which simply states that the signature must be capable of identifying the signatory, without specifying how this could be achieved; and the definition of a certificate merely states that it must confirm the identity of that person. Indeed, even when referring to qualified signatures, Annex II of the Directive explicitly avoids this issue and leaves its resolution to the Member States: ANNEX II - Requirements for certification-service-providers issuing qualified certificates Certification-service-providers must: [ ] (d) verify, by appropriate means in accordance with national law, the identity and, if applicable, any specific attributes of the person to which a qualified certificate is issued; [ ]. This does not preclude PKI systems from being a perfectly suitable technical solution for eidm, as can also be seen in the overview above, including where qualified signatures are concerned. This is stressed in a number of country profiles, including e.g. for Norway, where the correspondent noted that: For a better understanding of this report it is important to understand the following. Pursuant to Norwegian law there are very few legal regulations that require a signature in order to make the transaction legally binding. In addition the definitions in the Directive on Electronic Signatures, and subsequently of the Norwegian Act on Electronic Signature, are interpreted to also cover entity authentication. Thus, a qualified certificate under Norwegian law can be used for signature (non-repudiation) and/or entity authentication. However, it is important to note that the Directive itself does not address the legal effect of entity authentication. It does not define when an entity has been uniquely identified, nor what the legal effect is of an authentication certificate. In short, the issue of entity authentication is not currently regulated on a European level. Approaches in the surveyed countries As noted in section 4.3.2. above, the majority of countries have implemented some form of a PKI authentication system (25 countries out of 32-78%). This is almost invariably the case in countries which have introduced eid cards (7 countries out of 32 (22%) when looking only at cards issued by public bodies; or 12 countries out of 32 (38%) when including smart cards issued by private CSPs with a government mandate), which often carry a certificate for authentication next to an e-signatures certificate. In some cases however (like in Austria) only a signature certificate is included, which is used for authentication purposes as well. As noted above, there is no European regulation with regard to electronic entity authentication; the status of national regulations in this regard will be further examined below (see section 4.5.2. for information on the national status). Page 109 of 228

Apart from the use of authentication certificates, the use of electronic signatures for entity authentication purposes is also commonly cited. These fall broadly into two categories: Electronic signature certificates which are directly used for authentication purposes, through the inclusion of unique identifiers in the certificate itself. This is e.g. the case in Austria and Bulgaria. Electronic signatures are used to sign electronic documents which contain the required personal data. This approach, which is e.g. being used for some applications in the Czech Republic, is an interesting application of the esignature Directive, since it indeed leaves it up to the application provider to determine which information he wants/needs to receive before considering an individual to be adequately identified. In effect, this is a fairly direct recreation of a traditional offline authentication method, by requesting the authenticating entity to provide his information and to sign it, with the provided information then being assessed by comparing it to a reliable identity document (such as an ID card). However, it is also somewhat circular in its logic, since entire system is only useful if a link can be determined between the signatory (through the signature itself) and the identification information in the signed form. Thus, the system thus still needs to fall back on information contained in the signature itself. In other words, while the system might be on firmer legal grounds than the approach above, the situation with regard to actual reliability is identical. Page 110 of 228

4.5.1.2 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 Page 111 of 228

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. Page 112 of 228

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 35 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. Page 113 of 228

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. Page 114 of 228

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. Page 115 of 228

4.5.1.3 Services Directive Principles and applicability Basic principles of the Directive Finally, the Services Directive of 12 December 2006 (to be transposed by the Member States by 28 December 2009 in accordance with its article 44) introduces a legal framework aiming to harmonise the internal market with regard to the provision of services, both in relation to the exercise of the freedom of establishment for service providers and the free movement of services (article 1 of the Directive). This should facilitate the provision and use of cross-border services in the European Union, thus increasing cross-border competition in service markets, bringing down prices and improving quality and choice for customers. Applicability to the issue of identity management While not explicitly relevant to egovernment or identity management as a whole, the Directive none the less contains one particular provision that will have a direct impact on the state of electronic identity management systems in many Member States. Specifically, article 8 of the Directive states the following: Article 8 Procedures by electronic means 1. Member States shall ensure that all procedures and formalities relating to access to a service activity and to the exercise thereof may be easily completed, at a distance and by electronic means, through the relevant point of single contact and with the relevant competent authorities. 2. Paragraph 1 shall not apply to the inspection of premises on which the service is provided or of equipment used by the provider or to physical examination of the capability or of the personal integrity of the provider or of his responsible staff. 3. The Commission shall, in accordance with the procedure referred to in Article 40(2), adopt detailed rules for the implementation of paragraph 1 of this Article with a view to facilitating the interoperability of information systems and use of procedures by electronic means between Member States, taking into account common standards developed at Community level. The first paragraph of this article requires Member States to create in effect an on-line one-stop-shop (a point of single contact PSC), where service providers can go to meet any requirements covered by the Directive linked to the access or exercise of impacted services in that country. Apart from a number of other issues, a key problem to be resolved is the identification of the service providers. It should be noted that this paragraph does not require Member States to implement a specific eidm system that is interoperable with any non-national systems. It would be equally possible to implement a strictly national lower level authentication system that allows non-national entities to meet their obligations electronically and at a distance. Alternatively, Member States could opt to abolish certain requirements that would be difficult to reconcile with this provision. Theoretically, the most ideal solution would be to implement an interoperable eidm system that would allow non-national entities to authenticate themselves with an acceptable degree of certainty using their own national eidm systems. However, in this case there remains the inherent weakness of requiring a reliable non-national eidm system to interoperate with, which may be non-existent in some countries. It is clear that the Directive foresees the creation of interoperability mechanisms (both with regard to authentication and document exchange) as a key route to adhering with the provisions of article 8. This is witnessed by the third paragraph of the article, which grants the Commission the authority to adopt Page 116 of 228

detailed rules for the implementation of paragraph 1 of this Article with a view to facilitating the interoperability of information systems and use of procedures. Currently, the issue of identity management is addressed in an oblique manner through the ongoing CROBIES work 36 surrounding the Common Minimum Requirements for a Qualified Certificate Profile supporting Qualified Electronic Signatures [RD9]. As indicated by the name, this work focuses mainly on improving the interoperability of electronic signatures based on qualified certificates, and not on entity authentication as such; however, there may be a significant impact on identity management issues as well. The relevant efforts within CROBIES with an eidm component do not relate primarily to questions of identity management as applied to the signatory but rather to the content and structure of qualified signature certificates as a whole. As such, the CROBIES work is aimed at establishing a better and more harmonised implementation of the TS 102 280 standard (X.509 V.3 Certificate Profile for Certificates Issued to Natural Persons 37 ). One of the main expected impacts will be the mandatory use of a harmonised serialnumber within the Subject field of the certificate, which should ensure that at least a basic resource is available to unambiguously identify signatories. It should be kept in mind however that this work is only envisaged to directly impact qualified certificates, and that the serialnumber as such may not be a directly usable resource to any given e-signatures application. Thus, in this respect, the CROBIES work provides a crucial input to address semantic issues related to the identity and capacity of signatories. 36 Cross Border Interoperability of esignatures [CROBIES] study; see http://ec.europa.eu/information_society/policy/esignature 37 See http://www.etsi.org/website/technologies/electronicsignature.aspx Page 117 of 228

4.5.2 National regulatory approach models As an initial comment with regard to national regulatory approach models, one of the main questions of the questionnaire was whether or not the surveyed country had any specific legal framework with regard to entity authentication. The underlying goal of this question was the identification of any legal definition of the concept of an identity, and more importantly, how an identity can be established in an electronic environment. This was considered to be a significant question, especially in view of the lack of a clear European framework for electronic entity authentication. It was generally expected that most countries would not have explicitly addressed this issue through regulatory initiatives, and this appears to be correct: only in Austria is the concept of identification legally defined. As noted in the Austrian profile: The Signature Act has transposed the e-signature Directive. Qualified electronic signatures are defined for natural persons only (based on the fact that qualified certificates can be issued to natural persons only), other signature types such as advanced electronic signatures can be issued to legal persons also. The egovernment Act defines identification, as follows: - Unique identity: designation of a specific person by means of one or more features enabling that data subject to be unmistakably distinguished from all other data subjects Initially, a second identification level recurring identity allowing to link an authentication to a previous one, but not necessarily longterm unique identification has been defined but abandoned in the 2008 amendment due to low practical relevance. All Austrian citizen cards in use provide unique identification, as the identity is linked to the base registers unique identifiers. Integration of foreign eids is provided and has been streamlined with the last amendment of the egovernment Act. [ ] The sourcepin Register Authority provides services in connection with the sector-specific eidm model. In particular, this includes the calculation of sector-specific PINs of other sectors, if the name and the date of birth together with the sector-specific PIN of the requesting sector are provided. The sector-specific PIN is encrypted for the target sector. This allows data exchange between sectors without involvement of the citizen where such data exchanges are admissible. The unique identifiers sourcepin and also the sector-specific PINs are legally protected by the egovernment Act. Storing the sourcepin is prohibited for any application; only the citizen card holds the sourcepin in the identity link. The sector-specific PINs may only be stored by the sector that has created the identifier. The same holds for private-sector specific PINs. In addition, the Finnish report noted that a new Act on Electronic Authentication and Signatures was expected to be passed by the Parliament in September 2009; this Act has since been adopted 38. Other than these two cases however, the regulatory frameworks generally only referenced electronic identification indirectly, including notably via: esignatures regulations; 38 The Act on electronic identification to promote the provision and the use of identification services entered into force on 1 September 2009, replacing the Act on Electronic Signatures of 2003; see http://www.epractice.eu/en/news/293726. Page 118 of 228

Regulations in relation to available infrastructure (electronic identity cards and official registers, most notably, specifically indicating which information they contain, what form they should take, and for which purposes they can be used; or To indicate security requirements by referencing any authentication policies. As indicated in section 4.3.1., this is however relatively rare, and was only observed in France and Norway, where authentication policies are supported through specific legislation. The question of which elements legally constitute an entity s identity has not been explicitly regulated in all but two countries however; nor have they generally implemented a generic 39 legal framework detailing on what authentication is, and at which point authentication requirements have been met. In the absence of any legal framework with regard to authentication (either on-line or off-line), a further comparison is of course not possible. Explicit reference in this regard is often made to the national laws with regard to electronic signatures, with a large number of correspondents noting that, although this legislation does not strictly apply to authentication processes for the reasons noted above, PKI signature technology is still often retained as an entity authentication mechanism. The main reason for this is that, even if the legal framework does not strictly speaking address all relevant issues, the technology/technique behind PKI based electronic signatures can still offer a large degree of certainty with regard to the entity using an electronic signature (especially when qualified certificates or qualified signatures are used), so that the use of electronic signatures is a de facto adequate tool for authentication, even if the legal basis for it is non-existent. In an offline context, an entity is authenticated in a variety of ways. In formalised government transactions, where an entity is authenticating itself to an entirely unknown administration, this is typically done by providing a certain amount of information, typically issued by a third party, which the receiving administration then verifies to a degree that it finds satisfactory. In an electronic context, the process is largely identical: trusted information, typically authenticated by a third party, is provided to an administration, which then assesses if this information is sufficient to consider the entity authenticated. However, in neither case an explicit legal framework typically exists. The primary questions are then which information is usually provided, and how is trust in the accuracy of this information created? The legal aspects of these issues are discussed in greater detail below. 4.5.2.1 General eidm policy at the national level The first of these issues, the creation of trust between identity providers and relying third parties, is organised in vastly different ways, with the surveyed countries making substantially different policy choices, as noted in the tables above. However, there are a number of common elements, which will be discussed further below. 4.5.2.1.1 Centralisation and internal harmonisation One common element is that no country relies exclusively on a single centralised system, e.g. an electronic identity card or a single username/password system. While most countries have chosen to use a single or limited number of authentication system as their primary solution, smaller scale solutions for specific applications continue to exist. However, the analysis also shows that most of these isolated smaller scale solutions are the result of a spontaneous and pragmatic development of specific solutions within a specific sector (e.g. tax administrations) or for a specific application (e.g. requesting on-line certificates from civil 39 I.e. which transcends the functionality of a single application or application category. Page 119 of 228

administrations). In relation to current interoperability initiatives, most country profiles indicate that national harmonisation of identity management solutions is usually a policy priority, where governments have elected certain solutions as their standard authentication model, and are actively promoting their uptake. This can be clearly witnessed in the existence of multilevel authentication policies in a number of surveyed countries (see also section 4.5.4 below). After all, such levels can only be defined once an administration has created an overview of the principal authentication solutions in vogue, and has mapped these solutions to abstract requirements. In summary, it is important to note that the sector of egovernment identity management is still consolidating internally, with policies mostly focusing on eliminating smaller scale solutions in favour of a limited number of favoured solutions so as to maximise return on investment in these solutions, and has not yet reached a point of complete stability in most countries. This can be seen even in countries with strong decentralised traditions, such as e.g. Germany, where a large scale eid project has been underway: The boundaries of legislative authority between state and federal level have been changed by a Federalism Reform Agreement between the Federal Government and the 16 State Prime Ministers in 2006 and furthermore in 2009. Among other things the legislative authority for civil registration has been shifted from the state to the federal level. Thus identity management is now an issue of the federal government, which has to seek agreement with the state governments and municipalities, which still have the authority for technical and organisational implementation of the law. It should be noted however that there are two exceptions/nuances to this general trends of harmonisation and centralisation. The first of these is the existence of decentralised solutions as a policy choice, where a local IDM solution has been created to ensure that local/user group specific needs are being met in an appropriate manner. Key categories of this trend, as identified in section 4.2, include the decentralised issuing of cards specific to a certain region with the required administrative autonomy (such as the French Carte Vitale or the Italian CNS), or the issuing of suitable tokens to a specific user group on account of their specific qualifications (such as the Italian civil servant card CMD, or the Portuguese authentication certificates issued to lawyers, solicitors and notaries. In these cases, the use of user group specific solutions is considered justified on the grounds of a perceived benefit of catering to the specific needs of the group. In this regard, it is interesting to note that several surveyed countries, including Austria, Hungary, Iceland and Italy have opted to create card standards/concepts/models, where the presented solution represents an specific set of requirements that can be implemented in any number of ways. The Austrian Citizen Card Concept is the most far reaching of these, since the concept can be implemented in any number of technologies, including in the form of mobile phone cards. The use of traditional smart cards is thus not necessary. The Hungarian HUNEID and the Italian CMD/ATA-E cards take a similar but less radical approach, by specifying a set of standards which can be implemented through any number of smart card solutions. Thus, the purpose of the standards in these cases is principally to ensure that compliant solutions offer a certain functionality, including with regard to their interoperability from a national perspective, but without committing to a specific card type, or in the Austrian case, to a specific technology. Apart from the introduction of such decentralised and user group specific solutions, a second exception is the use of identity management solutions which are principally used in the processing of sensitive or protected data, the most common example being the existence of health cards/social security cards, and the existence of healthcare professional cards. In these cases, the European legal framework (mainly the Privacy Directive) foresees specific protection, as the data is considered to be particularly privacy sensitive. For these reasons, it is unsurprising to see that many of the surveyed countries have opted to split off these systems from more generic eidm frameworks. As noted in section 4.1.3. above, 6 correspondents have indicated the use of health card/social security smart cards in their country, with Page 120 of 228

another 6 noting the use of healthcare professional cards. Given the likelihood of underreporting (as the surveys requested that correspondents report the main eidm solutions in their country, which may not always include these cards), privacy considerations also seem to play a key role in eidm choices, with sensitive data being screened off through the use of specific eidm solutions. 4.5.2.1.2 Private sector involvement A second common element is that the surveyed countries fairly uniformly recognise the importance of private sector uptake of the electronic authentication solution. Many of the correspondents express the sentiment that the business case for an exclusively public sector authentication solution is very limited to the general public. This situation is of course very different for specific user groups such as lawyers, accountants or healthcare practitioners, who are required by the nature of their services to interact frequently with public sector bodies, and where the business case of a public sector only solution is thus sufficiently strong. But apart from such specific user groups, the usability of authentication solutions in private sector applications is considered to be of key importance. This can be seen in the tables under section 4.2., which indicate which of the offered eidm solutions are available to use in the private sector. In this section, three key categories are distinguishable. The first of these consists of PKI solutions which are managed in their entirety by public administrations, which includes most types of electronic identity cards and soft certificates issued by governmental CAs. Here we see that 14 out of 21 described solutions (i.e.66%) are open to use by private sector parties; with the remainder typically being restricted to certain user groups (civil servant cards, lawyer cards etc.). Thus, unless the solution has been designed with only a specific functionality in mind, private sector use is typically possible. It should be noted that this category can be expected to grow substantially, since 13 of the surveyed countries are currently designing or considering the introduction of eid cards, and private sector use in all of these cases is either certain or considered. The second group consists of PKI solutions which are managed in public/private sector partnerships. This is the case where part of the PKI responsibilities have been outsourced to private sector partners, such as the issuing of smart cards by financial institutions, or the use of certificates issued by accredited/recognised private CSPs in egovernment applications. Given the expected hopes for an adequate return on investment in this constellation, it is unsurprising that all of these have been designed with private sector use in mind. Finally, the third group consists of username/password systems, either simple or as a two factor system. Of the 28 identified solutions, 23 have been implemented by the administrations themselves, and in only 5 cases, the system is controlled by banks, who have concluded cooperation agreements with public administrations allowing them to take advantage of these authentication systems. Considering these numbers, it is clear that private sector uptake is a major design consideration in PKI based IDM systems, and an important improvement of the use case. This is demonstrated clearly in the Estonian country profile, which comments on the importance of this link with the private sector: Although the ID-card is an important eidm system, it is not the most used system today. Estonia has a relatively long tradition of Internet banking and nearly everyone has access to it. The main method to access Internet banks is using password cards with 24 codes on it (usage of ID-card and PIN-calculators is estimated below 15% today). Banks are providing authentication services to 3 rd parties (~30 systems), including egovernment systems. It is estimated that over 90% of egovernment transactions requiring authentication is performed only thanks to the authentication service from Internet banks. The PIC has also here the function of unique identifier in the authorisation process. This situation is expected to change in a few years banks are going to drop authentication service to 3 rd parties and reduce usage of password cards by gradually lowering daily Page 121 of 228

transaction limit. The latest drop of a transaction limit to 3000 EEK per day (around 200 EUR) was performed on May 18 th, 2009. [ ] It is obvious to everyone that ID-card-based authentication is more secure than using bank authentication, but the number of electronic users of the ID-card is still low at the time being. It is up to every egovernment service provider to decide about the security level of authentication and most of them support both (ID-card and bank eid) methods. Regional/local government authorities use the same eidm resources as national ones. As noted before, bank authentication is the most used authentication method today with password cards being overly popular. After completion of roll-out of the ID-card and with the rise of cyber-theft, banks have been starting to change their thinking and policies towards provisioning of the authentication services and use of password cards in general. As a result, a co-operation agreement was signed between major banks, major telecom companies and the Government in May 2006 with code-name Computer Protection 2009 (http://www.sk.ee/pages.php/02030201,1107). This initiative addresses general IT-security topics for end-users but with large emphasis on transition to PKI-based authentication methods. Objectives of the initiative include: promotion of ID-card increasing availability (and affordability)of smartcard readers introduction of alternative PKI-based authentication systems like Mobile-ID and alternative eid cards 10-fold increase of user base of PKI-based authentication systems in 3 years (from 40 000 to 400 000 by the end of 2009) As a result of the initiative there has been notably accelerated growth of ID-card users. Although the 400 000 mark seems to be unachievable, 300 000 users by the end of 2009 seems still realistic. 4.5.2.2 National competences and constitutional issues It is important to note that the possibility to design and deploy eidm systems across a country can be hindered because of restrictions of competences. A key example is this regard is the German situation, where we already noted above that important changes in competences have been implemented in recent years. However, constitutional objections against generalised unique identifiers remain. As noted in the report: Based on the census decision (Volkszählungsurteil) of the Federal Constitutional Court (Bundesverfassungsgericht) of 1984 and its interpretation by the Federal Parliament (Deutscher Bundestag), the German constitution does not allow a unique personal identity number. Consequently the present and foreseeable future policy does not aim at a comprehensive and integrated eidm system based on a unique personal identity number used on a digital token in all or most sectors of government. While Germany may be the most far reaching example, other countries show similar concerns, most notably Hungary: The basic registers use a mathematically generated unique identifier which is a sectoral identifier and besides that they store the natural identifiers (name, place and date of birth, mother s name) of the person involved also. The so called personal identification number was introduced before the Change (1989) in order to help to keep the records of public administration databases up-to-date. But in a decision made in 1991, the Constitutional Court has ruled that the general, uniform and uncontrolled use of the unique personal identification number in use since 1986 should be considered unconstitutional. The law No XX. of 1996. has therefore limited the Page 122 of 228

use of the personal identification number and has decreed the use of separate identifiers for tax and social security purposes. As a result of this, recently there are multiple sectoral identifiers in use in Hungary (the most important ones are the taxation number, social security number, student number, personal identification number), and the usage of the already existing personal identification number as a general identifier for egovernment purposes is not possible. In fact the personal identification number by the earlier mentioned Constitutional Court decision in practice became rather a sectoral identifier.. Thus, the concern over unique identification numbers is not a uniquely German phenomenon. Other national reports have expressed similar concerns, mostly originating from data protection groups, about the risk of relying on unique numerical identifiers. Portugal also dealt with this issue in the introduction of the eid card: Due to constitutional limitations, this e-card does not provide a unique IDnumber for each citizen. Instead it contains all the numbers included in the mentioned existing cards, i.e. the personal identification number, social security number, tax number and health user number. Such concerns and sensitivities will need to be taken into account when attempting to create an interoperability framework. 4.5.3 Privacy issues Apart from the issue of trust, there are also privacy concerns resulting from the need to identify individual entities in a way that is as minimally intrusive as possible. As noted above, the surveyed countries take significantly different approaches to this. At this point it is important to reiterate a terminological concern in the study. The definitions in section 2.1 above define a unique identifier as follows: Unique identifiers: an attribute or a set of attributes of an entity which uniquely identifies the entity within a certain context. Examples may include national numbers, certificate numbers, etc. It follows naturally from this definition that any electronic authentication process aimed at uniquely identifying an entity (as opposed to merely authenticating a capacity, which is a matter of authorisation) requires a unique identifier. However, this does not imply that a specific number needs to be allocated to such an entity. The use of issued unique numbers as unique identifiers is a typical and easy approach. As long as the numbers are issued and managed by a central authority or by a system that ensures that such numbers are and remain unique, this is a system that can scale well and offer reasonable amounts of security. None the less, there are several possible issues with this approach. First of all, as indicated above, several countries (namely Germany and Hungary) consider the use of generic identification numbers for all egovernment applications to be unconstitutional when applied to natural persons. This does not necessarily imply that no unique identification numbers can be used in these countries, but rather that their use must remain limited to a specific context. Even in countries where there is no such controversy, it is clear that any unique identification number issued to a natural person constitutes personal data as defined by the Privacy Directive, and can therefore only be processed under specific circumstances. This usually implies that such identifiers are unsuitable for uptake outside of the context in which they were issued, which (at least for identification numbers issued by public administrations) typically implies that they cannot be used in the private sector. It should be noted that this issue is related to privacy risks (i.e. the possibility of abusing a unique identifier of linking information together in a way that is contrary to the data subject s will), and that it is therefore much less relevant for legal persons. Indeed, as the table in section 4.1.2.1. shows, Page 123 of 228

identifiers which are uniquely issued to legal persons are not usually subject to usage restrictions in the way that identifiers for natural persons are 40. A second potential issue is the potential key space, i.e. the total number of available identification numbers which may not be exhausted. While no identifier has been identified in the study for which the key space has been exhausted, there is an additional legal risk involved in cases where the chosen identifier is semantic, i.e. reveals personal identification regarding the user. A typical example of this is e.g. Luxembourg, where the identity number is semantic for both natural and legal persons: The identity number is semantic. In the case of natural persons, it contains the date of birth, a sequence number indicating the order of birth of that day and the gender (odd number for men, even number for women), and a check digit. For legal persons the number indicates the year of establishment or first registration for non-national legal persons, legal form, sequence number and check digit. This practice is quite common, as shown in table 4.1.2.1. above: apart from Luxembourg it is in vogue i.a. in Belgium, France, Hungary, Malta, and Slovakia. The use of such identifiers exposes the holder to additional privacy risks, since specific information can be obtained regarding his/her identity merely by having access to this number (date of birth and gender being common examples). While this risk in itself is small since the information is not typically especially privacy sensitive, it also increases the risk of key space collision, where the same number is allocated twice to different persons with similar identity attributes. Incidents of this nature have been reported e.g. in Slovakia. For this reason, a number of countries (most notably Finland and Austria, but also the Czech Republic in the future) have taken the step of allocating unique identification numbers based on encryption algorithms which can guarantee that key space collisions cannot occur and which do not contain any semantic information. In both cases, even further privacy protection measures were implemented: the Finnish FINUID number has no actual functionality apart from authentication using the eid card, so that its use is strictly limited; and the Austrian sourcepin is never presented in an unencrypted form to any service provider, making abuse practically impossible. Apart from the use of identity numbers, other identification strings are of course equivalent and show the same risks and advantages. This issue was also addressed through encryption in Italy: One interesting feature of the Italian eid tokens is the format of the authentication digital certificate, whose common name does not directly contain (at least in the EIC and NSC cases) the name of the holder. Instead it contains the SHA-1 hash of the file Dati Personali (personal data), thus preventing anybody from accessing the personal information of the holders (for example, from the directory of certificates) without their explicit permission. In case of necessity, the file Dati Personali can be read too, its hash computed, and the result compared with that contained in the common name of the certificate. This concern is also relevant for non-pki systems. By way of example, in username/authentication systems the username plays the role of de facto unique identifier, with the additional risk that the username might in some cases be semantic (e.g. smithj for John Smith), predictably constructed (e.g. user563 for the 563 rd user), easy to guess (e.g. john.smith@company.com) or simply chosen by the user himself (e.g. JohnSmith). For all of these reasons, simple username/authentication systems without multifactor measures) offer virtually no security and present privacy risks that make them fundamentally unsuitable for egovernment applications requiring more than basic access control. However, there are of course less obvious choices for unique identifiers than merely selecting a number or single attribute, such as a unique combination of identifiers. Any sufficiently extensive dataset (e.g. first name(s), last name(s), official address, date of birth, place of birth, nationality, civil status,...) will automatically result in the unique identification of the entity concerned. However, such 40 Certain limited exceptions to this principle exist, such as Luxembourg, which has a joint unique identification number system for natural and legal persons which are subject to the same legal regime (although of course the Luxembourg Data Protection Act additionally applies to this number for natural persons but not for legal persons) Page 124 of 228

combinations again offer little in the way of security (the information is accessible to anyone familiar with the entity) nor in the way of privacy guarantees (a full set of identity information becomes available to the recipient of the identifier). Quite likely this is the reason why the existence of systems relying on such identifiers has not been reported. None the less, it can be considered as a basic alternative to unique identification numbers. As the Norwegian correspondent stated: Pursuant to the Act on Personal Data a personal identification number can only be used when there is a just reason and it is impossible to ascertain a person s identity by other means such as name, address, date of birth, customer/member number. 4.5.3.1 Identifier policies A summary overview has been provided of the main choices of identifiers in the surveyed countries in section 4.1.2. above, along with their legal status as being unprotected (apart from the applicability of the Privacy Directive s transposition law in the case of natural persons) or protected by specific regulations. Restrictions to protect such identifiers through specific regulations are of course permitted under the Data Protection Directive, which explicitly notes that 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 of the Data Protection Directive. The table in section 4.1.2 shows that unique identifiers are frequently included as an identifier in authentication certificates, even if they are legally protected against unrestricted used; which is e.g. the case for both the Belgian and Estonian eid cards, or in the recently introduced Icelandic cards: The Serial_Number field in the Certificate subject denotes the Personal Identification Number of the Certificate holder (the citizen) which is a unique number, created for all citizens by the National Central Registry. The Certificate also contains the name of the citizen. This information should be enough for most service providers. If needed, service providers will also be granted certificate-lookup-access for public certificates of their customers. This practice hollows out the legal regime which protects these identifiers against trivialisation in both countries. For this reason some countries, such as Finland, have chosen to create an identifier (the FINUID number) whose only purpose is electronic authentication, and which can thus be freely incorporated in the authentication certificate and used outside of it. None the less, even when such identifiers are not protected against private sector uptake from a practical perspective, the legal framework may still provide a significant barrier, as is e.g. witnessed in the French example: The opinion of the CNIL [the French data protection authority] as regards the use of the NIR [the French National Registry Number] as identifier will be discussed as it is expressly adopted by the French government in its e-administration policy. 41 Since 1984, the CNIL has insisted that the RNIPP [the French National Registry of Physical Persons] was a civil status directory, created for preventing mistakes in the identity of individuals based on homonymy. 42 A universalistic concept of the NIR which would convert it to a national identifier should be avoided. This means that the NIR cannot be used as unique identifier and should be complemented by other information such as the address, etc, when it is used. Moreover, the use of this number by Public Agencies for the linking of databases is limited to a strict application of 41 Ministry of Civil Service, State Reform and Land settlement, Electronic Administration Strategic Plan (PSAE) 2004-2007, p.15 42 CNIL, Délibération n 83-058 du 29 novembre 1983, available at : http://www.cnil.fr/index.php?id=1380&delib[uid]=35&chash=52a059c87b Page 125 of 228

the finality principle 43 : if two public agencies are legally authorised to use the NIR and to transfer personal data to each other, then they can use it as a key for their transfers of personal data. In any other case, the CNIL considers that the sole need of linking two databases is not sufficient for justifying the use of this number. 44 This interpretation has played a key role in preventing the use of the NIR by Public Agencies as common identifier for the linkage of distinct public databases, compelling them to create their own identifiers and maintaining its use, each time broader, within the health sector. The factual private character of an identifier thus does not depend only on the legal framework surrounding the identifiers, but also on the enforcement of this framework, and most importantly on the operational practices surrounding the identifier (such as its routine inclusion in PKI certificates used in private sector transactions). Apart from these more typical approaches to the selection of unique identifiers, other countries choose more minimalist approaches to reduce privacy risks, such as Hungary: (Re)identification (verification of personal data) The digital certificates mustn t contain either the personal identification number or the natural identifiers except the name and the e-mail address of the certificate holder in Hungary. The Act No. CXL. of 2004 on the general rules of public administrative procedures and services (hereafter Ket) has introduced the institution of (re)identification to solve the problem of data protection arising in connection with the on-line identification of persons. The method of (re)identification provides the result of identification without transfer of personal data stored at the Client Gate or at Certification Service Provider (CSP). Basically in a single-sign-on system if the user signs on his attributes are transferred for the service providers from the identity provider, which in our case is the Client Gate; but for data protection reasons this is not allowed in Hungary. Only the name and the e-mail address of the user gets automatically transferred to the service provider after sign on. The other attributes (the natural identifiers) of the user can be discovered only by the process of reidentification. When the user signs on, only his name and e-mail address is transferred to the service provider. In case the service provider wants to know the natural identifiers of the user for identification purposes it has to find it out for itself first. It can do so either by asking the user to tell it directly (entering it into an electronic form), or if the service provider already has a database (usually in this database the natural identifiers and a sectoral identifier of the person is stored together) then by retrieving it from there by asking the user to enter his/her sectoral identifier while using the service. After the service provider manages to acquire the natural identifiers of the user in any of the ways mentioned earlier, based on that it can ask the Client Gate to verify that data. For the verification the service provider sends the earlier mentioned transaction code (which functions like a temporary connection identifier) to the Client Gate (this is the data from which the Client Gate knows which logged on users reidentification is going to happen; the transaction code was earlier issued by the Client Gate and sent to the service provider and is valid for one connection only) and the natural identifiers. If the natural identifiers sent to the Client Gate are the same as those which are registered in the Client Gate s database about the person who logged on and got the given transaction code, then the reidentification is successful and the person s natural identifiers are verified. This approach is very pragmatic, since an e-mail address is indeed verifiably unique and usually not very privacy sensitive. The downside of course is that e-mail addresses may change ownership over 43 Under the finality principle, data controllers must obtain data only for specified and legitimate purposes, and must not carry out any further processing which is incompatible with those purposes. For more information about data protection principles, see FIDIS, D.11.1. Collection of Topics and Clusters of Mobility and Identity Towards a Taxonomy of Mobility and Identity, available on-line at: http://www.fidis.net/fidis-del/period-2-20052006/d111/doc/31/ (last access on 17 April 2007). 44 CNIL, 20th Annual Report, 1999, p. 65 Page 126 of 228

the course of time as domain names change hands, and that any entity may possess an arbitrarily high number of e-mail addresses/identities. None the less, it is an interesting example of minimising identity data in the authentication token, and shifting the burden of acquiring the needed identity data to the administration requiring it. A similar take is followed in the aforementioned Italian approach of including the the SHA-1 hash of the file Dati Personali (personal data) in the authentication certificate. In this case identity data is present on the token, but it is not routinely presented in the course of the authentication process. Instead, control is left in the hands of the card holder. The use of sector based identifiers is also finding increasing adoption, including e.g. in France and in Austria: As regards the identifiers used for authentication functions, the French government expressly opted for adopting sector based identifiers in accordance with the position of the CNIL on the use of the NIR. It is foreseen to use federated identities which would allow the user to get a unique identifier for accessing public services and prevent any link to be made between public databases. Therefore, public authorities issuing an eidm system will be able to adopt the same identifier they use in their relation with their users. Indeed, the choice for sector specific identifiers can even be a consequence of constitutional issues, as identified in the German report and discussed above. In the Portuguese case, an inverse decision was made to that in Finland: Finland introduced a distinct identification number (the FINUID) to limit privacy risks. In contrast, the Portuguese made the opposite choice: the eid card was not allowed to contain any new identifier, and so it just contains the four unique identity numbers (ID card, social security, tax and health) that already existed on other cards: Please note that due to constitutional limitations, this e-card does not provide a unique IDnumber for each citizen. Instead it contains all the numbers included in the mentioned existing cards. Finally, it should also be taken into account that sometimes no specific (legal) identifier is available, including in Slovakia: The most significant eidm system in Slovakia based on the Slovakian eid Card with a chip card and qualified electronic signature will be introduced according to the task No. 10 of the Action Plan Minerva 45 by the end of the next year. Before this is done, it will be necessary to introduce an identifier for the communication between information systems of public administration that will be unique, and to generate a unique personal identifier from the birth number. According to the data protection law the current birth number 46 is not usable for the information systems of public administration because it is possible to derive from it the personal data of the person, such as date of birth, sex, place of birth etc. But the birth number is currently used in all public sector systems and unfortunately, many Slovakian laws are explicitly bound up with the birth number. From that reason the replacement of the old birth number by a new unique identification number will be a long process and probably both numbers will be used for a few years simultaneously. Sometimes, qualified certificates issued by accredited certification authorities are used in connection to eidm. But it is not allowed to state the birth number of a natural person in a qualified certificate, and because of the present lack of another unique personal identifier it contains no clear unique personal identification data that would enable to uniquely identify the natural person. This seems to be the biggest issue; if the citizen wants to use the qualified 45 Short name of document Strategy of Development an Information Society under conditions of SR and the Action Plan adopted by Government of the Slovak Republic and describing the process of developing an electronic public administration. 46 The birth number can be used in paper form only. Page 127 of 228

certificate to sign electronically in communication with public administrations, that issue is actually solved by prior physical authentication. Thus, while all solutions by definition need to contain a unique identifier, the choices made in the surveyed countries vary widely, including the use of pre-existing and new protected identifiers, preexisting and new unprotected identifiers, sector based identifiers, obfuscated/hashed identifiers, and private sector controlled identifiers. 4.5.3.2 Private sector involvement As noted above in section 4.5.2.1., private sector involvement is considered a key enabler for electronic authentication in most of the surveyed countries. However, a problem inevitably arises when personal data is re-used outside of the context in which it was initially granted, which may be at odds with the provisions of the Privacy Directive and its national transpositions with regard to processing only being permitted in cases which are reconcilable with the goals communicated to the data subject, or with its permission. Thus, when an eidm system is being used in a private sector context, two situations can be distinguished: The eidm system is controlled by the private sector from the onset, but is also permitted in certain egovernment applications. This is e.g. the case with bank authentication systems that have been taken up by the public sector (as e.g. in Estonia) or with private sector CSPs issuing certificates which can also be used in the public sector (as is the case e.g. in Luxembourg, Austria, Liechtenstein, etc.). The eidm system is controlled by the public sector, but can also be used in private sector applications. This is invariably the case with public sector issued eid cards (see the list in section 4.1.1.2.). Either way, usage in the private sector implies that the private sector party will typically receive a set of identity data. The risk is that this set of data is greater than needed for the purposes of the application, thus resulting in an unnecessary divulgation of personal data. In most countries, no measures have been taken to counter this issue other than the applicability of national privacy regulation, which in general terms forbids the disproportionate processing of personal data as stipulated by the Privacy Directive, which thus includes a ban on acquiring, processing and storing unneeded personal data by default. In practice, observance of this rule is very difficult to police. More tangible systems have already been implemented in Italy (where, as noted above, personal data is actually encrypted and cannot be accessed directly without the user s consent), or the Estonian and Lithuanian examples of bank controlled authentication systems: In order to authenticate himself/herself via the ebanking system, the user must first enter the webpage of a certain state institution or the portal Government Electronic Gates and then choose the appropriate bank out of the list. The user is then directed to the webpage of respective bank and prompted to enter username, code (from the codes card or electronic codes generator) and a password. After authentication of the user he/she is asked to consent for the bank to transfer certain personal data (name, last name and personal code) to the Committee, State Tax Inspectorate, municipality or public agency Registru centras, depending on the services requested. Having thus given consent, the user is redirected to the website of the respective institution provider of egovernment service or to Government Electronic Gates portal, listing the available egovernment services. The user may then request the desired egovernment service. Thus, it is clear that the principle of user control over his personal data in electronic authentication processes (and particularly over the proportionality of any data processing activities) is receiving Page 128 of 228

increasing attention. In a cross-border context, user centricity and data stewardship should equally be key considerations. Page 129 of 228

4.5.4 Authentication levels: regulations and policies 4.5.4.1 Prevalence and principles of authentication levels in the surveyed countries As noted above in section 4.4, it is relatively common for countries to informally acknowledge the existence of multiple authentication levels and to informally determine some form of hierarchy between them: 18 out of 32 countries (56%) some form of multilevel authentication policy can be recognised, which is an increase of 3 countries compared to the 2007 edition of the study. However, such distinctions are rarely elevated above the level of nonbinding policy recommendations. More importantly, no country uses a tiered authentication system to formally require the use of specific authentication levels (rather than specific solutions) for each application, although steps in this direction are being taken in France and Norway. It is interesting to note that, while several countries have informally acknowledged authentication policies, virtually all of them focus exclusively on the security of the validation mechanism being used after the issuing of authentication credentials. This is of course only one side of the coin, as such policies are of little value if the registration process itself is not also covered. The Norwegian policy is a noteworthy exception to this rule, which will be discussed in greater detail below. On a high abstraction level, the following structure is often found: Level 0: a baseline level of publicly and anonymously accessible information (i.e. no form of authentication is required). Level 1: minimum security authentication is required, relying only on a username/password system. Such systems are commonly acknowledged to be insecure, but sufficient for low security applications. It is interesting to note that the use of username/password systems is almost omnipresent, despite a clear awareness of the limited security being offered by such systems. Level 2: two factor (or multifactor) authentication systems, which rely on username/password systems in combination with a token to generate a third/additional authentication string. Examples include paper tokens with multiple passwords, of which one is randomly requested by the authentication system; and electronic time based password generators. Level 2: PKI based systems relying on an authentication certificate containing whatever information is considered sufficient by the application. Level 3: PKI based systems combining an authentication certificate with a qualified signature. The main appeal of this approach appears to be the perceived certainty linked to the legal status of the qualified signature, as opposed to the authentication certificate which has no such status. This was observed e.g. in Austria, Italy, Malta, Poland, Romania, Slovakia, and Slovenia. Thus, the status of a qualified certificate is also used de facto as a quality label in an authentication context. It is clear that this opens certain perspectives in relation to interoperability, as the concept of a qualified certificate is a European one, meaning that at least this top level of an authentication policy could be applied in a cross border context without much additional effort. As noted above, such policies are rarely elevated to more than nonbinding policy statements. However, their main appeal lies in the possibility of generalisation to abstract norms, allowing each common European eidm solution to be given an authentication level classification. As a final stage, applications could then request the use of specific authentication levels, rather than specific authentication solutions. It is worth noting that the Estonian report indicated the intention to launch a project to develop assessment methods and criteria for assessing different eids, including foreign ones, likely through a formalised system of authentication levels. Page 130 of 228

The Norwegian approach, as formulated in the general specification for PKI seems to show the greatest potential for generalisation: while its current status is that of a policy document rather than a binding legal framework, it is a three tier system which explicitly identifies registration and management requirements, and maps risk levels to the corresponding security levels, as follows: The requirements specification contains three levels of security, two for individuals (Person-High and Person-Standard) and one for enterprises (Enterprise): The assurance levels and a selection of properties are specified in the table below: Page 131 of 228

The table below shows the intended use of the various types of certificates: Page 132 of 228

Common requirements for all three security-levels (unless expressly stated otherwise): - The certificates shall follow "Recommended certificate profiles for person certificates and enterprise certificates, unless these are not relevant to the certificate type. If other formats are used any deviations shall be documented (4.1.6) - The certificates should support user-specified non-critical extensions of the fields. (4.1.10) - For Personal-Standard and Enterprise storage of keys as encrypted PKCS # 12 objects should be permitted (4.3.4 and 4.4.5). - The Supplier shall document whether the solutions for presenting and verifying signed data comply with the requirements in CWA 14171 (7.1) - If the Supplier supplies a signature service, documentation shall be provided of whether the solution complies with the requirements and recommendations in CWA 14170 (7.2). - All user dialogues, help text and instructions shall be available in the Norwegian language (8.1.1 8.1.3). - What the user sees shall match what she signs. The way in which this principle is satisfied shall be documented (8.1.7). - Sufficient documentation shall be provided to allow a programmer with general expertise but no knowledge of the interface to utilise it (8.2.2) - The solution shall not tie the user to a single platform as regards for example operating system or web browser (8.3.1). - The CSP shall specify the operating systems that the end user may use. This shall include versions and support for thin Clients. (Windows XP, Red Hat Linux, Citrixterminal server etc.) The solution shall as a minimum function on the three most commonly used operating systems for end-user environments (Windows, Linux and MAC). (8.3.3) - Client interoperability (9.4) Certificates should be available for running Microsoft Certificate Store. Operations with private keys should be available for applications using Microsoft CRYPTOAPI or PKCS#11. The S/MIME format shall be used for encrypting e-mail. The solution should support SSL Client certificates. Due to its fairly detailed but still high level nature, this system constitutes an interesting baseline for a wider cross border approach. However, it also has the obvious restriction of being a PKI-specific mechanism, which cannot be easily extended to include other (non-pki) authentication methods. Page 133 of 228

4.5.4.2 Authentication levels and mutual recognition Currently, authentication levels are defined strictly on a national level, and they are mainly used as a tool to assist national policy decisions; i.e., the identified policies describe specific reliability criteria to be met, and map these to specific authentication means. As such, application owners can use such policies to assist them in determining their security needs and in selecting appropriate authentication means for their applications. However, the use of authentication policies is not usually mandatory, in the sense that application owners are not typically required to refer to specific authentication levels as a minimum for valid authentication in their applications, nor are they typically required to accept any authentication method which meets the requirements for these levels. Noteworthy exceptions to this are countries that have adopted PKI based authentication policies which are more strictly enforced, and which permit the use of any CSP authentication solution that has been accredited as meeting the requirements for a specific level (which is e.g. the case in the French PRIS framework). On an international level, the currently defined authentication policies have little relevance. They have been drafted with national authentication policy in mind, and do not consider the role of foreign authentication means from a cross border perspective (again, with the exception of PKI based authentication policies which often permit foreign CSPs to obtain accreditation for a specific level on equal terms as national providers). None the less, the availability of a generic authentication policy that could be applied across border is a crucial building block for the cross border mutual recognition of authentication solutions. One of the key problems for cross border authentication which currently remain unresolved is the issue of determining the reliability of foreign identity providers. Even if the required identity attributes could be delivered from a foreign source to a local application owner, this transfer would be meaningless if the application owner would not be able to determine with a satisfactory degree of certainty that the provided information is indeed correct. While this problem has a lot of components (including liability for provided information, trust assurance from specific partners, and semantic agreements on the specific meaning of certain information), a key issue is the mutual recognition of authentication means in a cross border context. In a nutshell, this entails (1) the acknowledgement that foreign authentication means are suitable for (certain) egovernment applications, and (2) the actual acceptance of the recognised authentication means within these applications (respectively the (1) formal component and the (2) factual follow-up). In order to be able to recognise a foreign authentication means, one must first be able to ascertain its reliability. This is where authentication policies can play a crucial role. In the absence of a cross border authentication policy that allows an application owner to determine the security level of a specific authentication means, the application owner has no other possibility than to verify the specific qualities of the authentication means on a case by case basis. On a European scale, encompassing many hundreds of authentication solutions, this would quickly become infeasible. For this reason, a cross border authentication policy should be defined, which determines specific security levels and specific requirements for the registration and authentication process. Such a policy would need to be taken up by any country interested in participating in a cross border authentication mechanism; and any cross border authentication solution should as a minimum show how the application owner can determine the reliability level of a foreign authentication mechanism being presented to his application. It was already noted above that qualified certificates (despite being principally targeted towards signature functionality) are considered to have a strong potential for being a top level solution for entity authentication. The Estonian intentions to explore this possibility to create a policy for accepting foreign qualified certificates both for authentication and for digital signing was already mentioned above; and in fact this option is already built in under Austrian legislation. As noted in the Austrian report: Interoperability with other national eids has been built into the egovernment Act. Registration to the SupR [Supplementary Register for Natural Persons] can be made online with the foreign eid if Page 134 of 228

... the application is provided with a qualified electronic signature which is linked to an equivalent electronic verification of that person s unique identity in his or her country of origin. The Federal Chancellor can lay down by order which foreign eids are deemed having an equivalent unique identity. For both non-residents having an Austrian eid and foreigners using their domestic eid, neither the citizen nor the service would sense a difference. The authentication process is based on an identity link signed by the sourcepin Register Authority and on qualified signatures. A technical difference is that the identity link usually cannot be stored in the foreign eidm token, but is created on the fly during the authentication process based on the foreign unique identifier. Thus, at least in some countries, there is a strong support for exploring the interoperability potential of qualified signatures for authentication functionality as well. Page 135 of 228

4.6 e-government applications using eidm 4.6.1 Introduction possible authentication methods in applications It will be examined which kind of authentication method was used, based on the following categorisation: Authentication method Password or PIN token Description A secret character string that a claimant memorizes and uses to authenticate his or her identity. Password list One-time password device token Soft crypto token Hard crypto token A personal soft token (paper list) that the claimant possesses. A list contains PIN codes for use in authentication, often in combination with a static password or PIN token within the authentication system. A personal hardware device that generates one time passwords for use in authentication. The device may or may not have some kind of integral entry pad, an integral biometric (e.g., fingerprint) reader or a direct computer interface (e.g., USB port). The passwords shall be generated by using a block cipher or hash algorithm to combine a symmetric key stored on a personal hardware device with a nonce to generate a onetime password. The nonce may be a date and time, or a counter generated on the device, or a challenge sent from the verifier (if the device has an entry capability). The one-time password typically is displayed on the device and manually input (direct electronic input from the device to a computer is also allowed) to the verifier as a password. This may include mobile SMS onetime password systems. A cryptographic key that is typically stored on disk, USB stick or some other media. Authentication is accomplished by proving possession and control of the key. The soft token shall be encrypted under a key derived from a password known only to the user, so knowledge of a password is required to activate the token. Each authentication shall require entry of the password and the unencrypted copy of the authentication key shall be erased after each authentication. A smartcard or similar media that contains a protected cryptographic key. Authentication is accomplished by proving possession of the device and control of the key. Hard tokens shall: require the entry of a password or a biometric characteristic to activate the authentication key; not be able to export authentication keys Page 136 of 228

4.6.2 ehealth applications 4.6.2.1 Overview In the table below, we will provide an overview of information that was provided on the availability of ehealth applications in the surveyed country, and specifically how eid functionality has been integrated into these applications. Country Application name and URL Use/functionality Status Austria Belgium Various applications built around the health insurance card, e.g. the health professional directory http://www.ehvd.at/ ehealth platform https://www.ehealth.fgov.be/fr/homep age/home.html Depends on the application The Platform provides the infrastructure (referred to as basic services 47 ) that allows applications to be developed, including the authorisation of health care professionals. Bulgaria No details provided No details provided N.A. Operational Operational Croatia Primary Health Care Information System PZZ http://www.hzzo-net.hr/ General platform for ehealth communication, building on the CIHI card and local clients in the doctors praxes Operational e-zdravstveno (e-health) Application that allows businesses that are registered in the register of the Croatian Institute for Health Insurance (CIHI) to register employees and their family members. Operational On-line supplementary insurance (on-line dopunsko osiguranje) Submission of proposals for supplementary health insurance Operational Cyprus Health care Information System (HCIS) The system includes many applications and modules to increase the quality and efficiency of procedures, working paperless and providing remote medical services. Partly operational 48 Czech Republic Pension and health insurance http://www.cssz.cz/epodani/epoda ni.asp A system of submissions of employers for pension and health insurance to the Czech Social Operational 47 See https://www.ehealth.fgov.be/fr/page_menu/website/home/platform/basicservices/overview.html 48 The system is already implemented in some hospitals and will be completed in 2010. Page 137 of 228

Security Administration IZIP - internet access to patient healthcare information http://www.izip.cz/index.php?lang =eng&p=0 Database of healthcare information on the internet; i.e. a patient's (client's) medical file. Operational Denmark Sundhed.dk www.sundhed.dk General platform for ehealth support, including signature functionality through OCES Operational Estonia Health Information System http://www.digilugu.ee A centralised database of medical data of patients accessible to health care professionals (with the permission of the patient) and patients themselves Operational Finland The national digital archive for patient documents KANTA A national digital archive for patient documents KANTA operated and maintained by the Social Insurance Institution (KELA). The legislation obliges all health organizations to join the national IT architecture for health, which should be built by the end of 2011. Pilot Establishment of a national eprescription database in KANTA and archive service operated by KELA. The Terhikki register Is available online and it is used as a so-called validated authentic source by the all healthcare service units to verify authorizations with regard to medical records and other data or applications. Operational The Terhikki register healthcare professional SSIN number is used as the user certificate serial number. The user role is included only in the signature certificate title field and no role attributes are included in other certificate types. France The Vitale Card requires the use of specific software officially recognised by the National Center of deposit and accreditation [Centre National de dépôt et d agréément] (CNDA). Persons or institutions which are professionally involved in health care services and which have been mandated to use the specific readers needed to read/edit the data on the card. From the user s perspective, the only application is therefore the automatic reading/verification of this data, so that the appropriate benefits can be provided (e.g. refunds for Operational Page 138 of 228

Germany National Health Telematic Infrastructure Greece Hungary www.gematik.de medication) and the correct administrative follow-up is ensured. The Vitale Card requires the use of specific software officially recognised by the National Center of deposit and accreditation [Centre National de dépôt et d agréément] (CNDA). General platform for ehealth support, including electronic authentication through specific smart cards. E-Health Unit of the Sotiria Hospital. A home-based integrated service (rehabilitation, follow up, home hospitalisation) is provided to elderly patients typically having more than one chronic disease, frequent exacerbations, poor quality of life or repeated hospital admissions. CARDIOEXPRESS S.A. Data supply to the National Health care Fund Telemedicine services specializing in cardiology. Allowing for the storage of an electronic patient record and the analysis of the ECG. The service subscribers are equipped with a portable ECG cart, supporting the transmission of either 3 or 12 lead ECG (by using standard telephone or mobilephone or radio-telephone communication links) Most of the operations are done through client gate. Additionally Hospitals provide a regular data supply to the National Health Care Fund by digitally signed documents. Iceland No details provided No details provided N.A. Ireland HealthLinkOnline Secure transfer of patient information over the internet between GPs and acute hospitals Italy ehealth services of the Region of Lombardy 49 http://www.crs.lombardia.it/cm/pa gina.jhtml? param1_1=n11c66635d1be439a 6ae General platform for ehealth support, including electronic authentication through specific smart cards Latvia No details provided No details provided N.A. Pilot Operational Operational Operational Operational Operational 49 Health care is a regional competence in Italy; therefore most of the relevant applications are developed, maintained and offered at the regional level. They are free to create their own eidm tools, with some regions being more active than others. Page 139 of 228

Liechtenstein No details provided No details provided N.A. Lithuania No details provided No details provided N.A. Luxembourg No details provided No details provided N.A. The Netherlands Norway Malta UZI card applications (UZI-Register) http://www.uziregister.nl/ MyGP/MyDoctor (MinFastlege), an application within the MyPage (MinSide) portal www.minside.no Several different services: Application for a European Health Insurance Card (EHIC) Blood donor registration Breast Care Related Services Speech Language Services Community Services by Commcare Register as a Pharmacy of Your Choice (POYC) Service Provider Generic trust infrastructure for health care professionals Allows natural persons to change their offial GP There is a growing number of ehealth services which makes use of the eid authentication framework. eid level1 is used. Poland No details provided No details provided N.A. Portugal No details provided No details provided N.A. Romania No details provided No details provided N.A. Slovakia No details provided No details provided N.A. Slovenia e-health Portal On-line access to health and health insurance data The portal is a cornerstone of a centralized information system for e- Health services. However, currently there are no applications available yet but implementation of some of them will start in 2009: E-documents exchange - solution will start as a pilot, afterwards it will be employed in part or in full on the national level Electronic ordering - project in preparation E-released letter - conceptual project in preparation The on-line access of health care providers. Development of other e- applications using e-signature on the HPC and/or HIC Operational Operational Operational Deployment phase; expected to be finalized in 2010 Pilot / under development. Spain General framework According to the study The ICT in Operational Page 140 of 228

Sweden A national electronic health record system, known as National Patient Summary (Sw: Nationell Patientöversikt NPÖ http://www.npö.nu/index.php?s=e nglish the National Health System. On line health 50, all Spanish Regions have worked hard for the automation of the health centers and services, gradually incorporating in the past 15 years telemedicine solutions or computing systems for the health management. Today, homehospitalization or electronic prescriptions are already functioning in the Spanish NHS. The system will, at a later stage, allow Swedish residents to access their own medical records through the Internet. At the moment, however, the National Patient Summary mainly gives authorised care staff access to critical patient information. Turkey No details provided No details provided N.A. United Kingdom No details provided No details provided N.A. Under development 4.6.2.2 Type of authentication method and authorisation management In the table below, we will provide an overview of the method of authentication used in the identified ehealth application for each country (using the classification above), and explains if/how authorisation management is addressed. Country Authentication method(s) Austria Hard crypto token Belgium Hard crypto token and password list Generic mandate and authorisation models The health insurance card is a closed PKI system which can be activated to operate as a citizen card. Public health officers and health authorities authenticate via a national portal group to the system using their citizen card. The portal group provides the nation-wide authorisation information transfer. The citizens are identified using the sector-specific identifiers based on the Residents Register CRR and the Supplementary Register to ensure high data quality. This system provides the national basis for The European Surveillance System (TESSY: European Centre for Diseases Prevention and Control). For specific sectors (like ehealth), Belgium uses a system of sector specific service integrators which link specific mandates/authorizations to generic identification/authentication systems like the eid card. In the ehealth sector, the service 50 Published on 2008 by the National Observatory on Telecommunications and Information Society (ONTSI) at http://observatorio.red.es/sanidad/articles/id/3032/las-tic-el-sistema-nacional-salud.html Page 141 of 228

Bulgaria N.A. N.A. integrator is the recently established ehealth platform. Users can use their eid card or federal token to authenticate/sign, and the service integrator will determine their mandate/authorization on the basis of authentic databases that it manages through a network of intermediaries (like e.g. hospitals). Croatia Hard crypto token Cyprus No details provided Czech Republic Password or PIN token or alternatively Soft crypto token Denmark Soft crypto token Estonia Hard crypto token Finland Hard crypto token The CIHI and FINA smart cards play an important (but not exclusive) role in ehealth applications. Authorisations/mandate management are largely handled on an ad hoc basis. No details provided The identification number is usually the personal identity number, access code is generated by the information system and provided to the owner personally, like a credit card PIN code; password is chosen by a user after the first log in into the system. The alternative is to use an authentication (non-qualified) certificate. Currently there are supported certificates issued by any of the three Czech accredited certification service providers or by Thawte, Int. The users have to log in to the system using id number/code/password combination and register their certificate. After the certificate is activated 51 by a system, a user can use it to access the system. Legal qualification/capacity in ehealth works by linking the personal registration number in the OCES certificate to the national health professional authorization register. If a person is listed in this register the registers authorization-code states the type of health professional that he/she is. The signature/certificate itself does not include such information. Authorisation details can be derived from specific registers, with support implemented on a case by case basis. Identification is done on the basis of the generic solutions (eid card, and in most cases the bank card as well). Applications rely on the use of the FINEID card for citizens and organisations, and the VALVIRA card for healthcare professionals. Healthcare professional certificates are issued to healthcare professionals defined in the law 559/1994, and also to students completing studies to become physician, dentist and pharmacist. According to the law 159/2007 VALVIRA certificates are also issued to all personnel working in and for healthcare service units, to other healthcare service providers and to healthcare applications and equipment. VALVIRA certificates are to be used for accessing patient data systems, signing of electronic prescriptions and other applications. More information on the VALVIRA CA activity is available in Finnish at: http://www.valtteri.fi 51 The new certificates are activated four times a day. The times are set with regard to the time of publishing CRLs to make sure that only valid certificates are registered. Page 142 of 228

France Hard crypto token Germany Hard crypto token Greece N.A. N.A. Hungary No details provided (Planned: Hard crypto token) Ireland Password or PIN token Iceland N.A. N.A. Italy Hard crypto token Latvia N.A. N.A. The VITALE card is delivered to any Social Security beneficiary older than 16 years and defines its rights to be reimbursed. It is based on the RNIAM number (National repertory inter-regimes of Health Insurance beneficiaries) issued on the basis of the national registration number (NIR, numéro d inscription au repertoire) which functions as an authentic source of civil status information. The application (and future ehealth applications as well) build on the egk (elektronische Gesundheitskarte) and the new HBA (Heilberufsausweis, Health Professional Card). The eidm systems behind this are mainly based on the membership data held by the health insurance companies that are issuing the egk and the organizations issuing HBA. The HBA will basically be a signature card for QES comprising authentication and encryption capabilities. It will also hold attribute certificates indicating the role of the card holder (e.g Arzt (doctor) or Apotheker (pharmacist)). Such attribute certificates are issued on the basis of existing professional admissions and are controlled along with these. Management of attributes under the responsibility of third parties is regulated in the Signature Act. The National Health care Fund is planning to issue an ehealth card replacing the recent paper card. The chip card will contain a signature and an authentication certificate. The planned start of issuance is the end of 2009. No generic model is in place yet; solutions are largely ad hoc. Services are built around the Regional Service Card (basically a local implementation of the NSC concept). The necessary databases containing the main attributes and mandates of health care professionals are put in place through the SISS project (Sistema Informativo Socio-Sanitario ). The SISS system is an ICT platform that links online general practitioners, childrens doctors and all other health structures. The aim is to have a unique system that collects, stores and makes available all health information about the citizens to the authorised health operators (i.e. it is an instrument of integration of existing and dispersed data). Access to the system happens through two cards: the operators card (SISS card) and the NSC. The SISS card allows the authorised operators to enter in the system and have access to the health data of the citizens. Liechtenstein N.A. N.A. Page 143 of 228

Lithuania N.A. N.A. Luxembourg N.A. N.A. The Netherlands Hard token crypto Dutch healthcare providers are issued with an electronic identity, in the form of a UZI-card (UZI stands for Unique Healthcare Provider Identification, Unieke Zorgverlener Identificatie). This is done by the Dutch Unique Healthcare Provider Identification Register (UZIregister), an organisation under responsibility of the Health Secretary. The UZI-card has three main functionalities: it allows healthcare providers to identify and authenticate themselves, it guarantees the confidentiality of their communication and, most importantly in the current context, the UZI card enables healthcare providers to enter an electronic signature. The UZI-card and its services are based upon the so called trust model', a model based upon the hierarchy of PKI-Overheid, the national government PKI. Norway Password list The described application is built on the generic MinSide infrastructure, and in this case allows the use of MyID (minid) authentication, i.e. using a password list. The approach aims to leverage the general infrastructure created by the MinSide-portal, through collaboration with relevant service providers within the government. For the ehealth application described above, authorization is handled by the Norwegian Directorate of Health (Helsedirektoratet). The Directorate has in this case a register of parents and their children, that they may represent in the solution. This is based on the reference within the MyID entity authentication solution to the national identity number, which is used to identify the person. Malta Password or PIN token Poland N.A. N.A. Portugal N.A. N.A. Used authentication mechanisms is currently eid Level 1 (username/passwords + PIN) Romania N.A. The Unique Integrated Information System of Social Health Insurances (Sistemul Informatic Unic Integrat al Sistemului de Asigurari sociale de sanatate) ( UIIS ), which was launched in 2008, plays an important role in the creation and management of the National Health Database from a technical and organisational perspective. UIIS has a hardware and basic software endowment component. The health data is collected by the physicians for each patient and includes the medical check-up card, prescriptions, medical leave, and will be transmitted at the end of each month to the Local House of Health Insurance. The exchange of healthrelated data at the national level is to be made by using the UIIS. Once the National Health Insurance Cards will be issued, all the information provided by such electronic card will form the first national database which will include health information on every citizen. Slovakia Soft/hard crypto token Authentication in e-health portal relies on qualified (software or hardware) certificates issued in accordance with Slovene legislation. For on-line access to health and health insurance data the new health insurance card with non-qualified certificate (hard token) will be used Page 144 of 228

Slovenia N.A. N.A. Spain Hard crypto token All citizens are part of the national Health System and have their e- Health Card; it was foreseen that by the end of 2008, the health cards of all Spanish regions would be fully interoperable. Sweden Soft and Hard crypto tokens Turkey N.A. N.A. The eid has to include two keys and two certificates (one for identification and one for the electronic signature). The purpose of the certificate and its private key has to be defined in the certificate field keyusage. The certificates with the personal eid should follow RFC 32802 and give the relying party access to the user s personal identity number. Soft certificates should not be valid longer than 2 years. United Kingdom N.A. N.A. 4.6.2.3 Conclusions Thus, 20 countries provided information in relation to their ehealth eid policies, whereas the others did not report significant use cases of eid in ehealth applications. Of these 20 countries, 4 only reported use cased that were in pilot/development stage, and these will not be examined further. In the remaining 16 countries, 18 use cases were reported: 10 countries reported on the general ehealth eid infrastructure, reusable across a number of ehealth application fields; 2 reported on predominantly social security/administrative applications; 6 reported specific applications (typically applications allowing the management of and access to electronic health records). Looking at the authentication means reported in these 16 countries: Hard crypto tokens are the predominant form of electronic authentication, being reported in 11 out of 16 countries (Austria, Belgium, Croatia, Estonia, Finland, France, Germany, Italy, the Netherlands, Spain and Sweden). Obviously, the availability of ehealth cards or health care professional cards is a strong enabler in this respect, as is e.g. the case for Croatia (CIHI card), Germany (EGK and HBA card), Italy (EIC and NSC card), and the Netherlands (UZIcard). These cards serve to determine the capacity of the signatory (e.g. the UZI-card is only available to health care professionals registered in the Dutch UZI-Register), meaning that interoperability is much harder to achieve in this field. Soft crypto tokens are significantly less common, being used in the Czech Republic, Denmark and Sweden, thus including mainly countries where such certificates generally play a stronger role in egovernment eid policy. Password lists were reported to be used in Belgium and Norway for some applications. Finally, Password or PIN tokens were reported in the Czech Republic, Ireland and Malta. Typically, this related to lower security applications. Page 145 of 228

4.6.3 ejustice 4.6.3.1 Overview In the table below, we will provide an overview of information that was provided on the availability of ejustice applications in the surveyed country, and specifically how eid functionality has been integrated into these applications. Country Application name and URL Use/functionality Status Austria CyberDOC and Archivium http://www.archivium.at/ Both are document archiving solutions for respectively notaries and lawyers. Belgium No details provided. No details provided. N.A. Operational Bulgaria No details provided. No details provided. N.A. Croatia e-tvrtka (e-company) www.pravosudje.hr Site allowing notaries to create certain companies on-line Pilot Cyprus No details provided. No details provided. ejustice infrastructure is present, but no clear eidm system yet. N.A. Czech Republic E-order for Payment Procedure It requires to fill in an electronic form and sign it with an electronic signature. Operational Denmark 52 Electronic deeds registration. Registration of electronic deeds and mortgages Operational Estonia Company Registration Portal 53 Finland https://ettevotjaportaal.rik.ee/?chl ang=eng The Ministry of Justice (MoJ) is developing several e-justice initiatives that will start towards the end of 2009. Portal site allowing the creation of simple companies on-line Legal assistance electronic services Uncontested debt recovery service Electronic service for bailiff and debt recovery Electronic document management for courts Operational Under development 52 Information kindly provided by Mrs. Charlotte Jacoby of the Danish Ministry of Science, Technology and Innovation after the finalization of the Danish country profile. 53 Described in the national report via a generic esignature application description, noting that the same signature infrastructure is universally usable (irrespective of application field). Page 146 of 228

France DepoMail System registers the sending or reception of a mail before the Court or in case of dispute. The system enables to identify the sender, guarantee the identity of the recipient and that the document has been received. When a return receipt is used it can be sent by electronically or by any other means allowing the storage. All these acts are certified by a bailiff. Operational Authentidoc The service ensures the validity and evidential value of a document. This service ensures the storage of documents and their integrity through time (10 years), certified by a bailiff. The document can be accessed online by the party through the secure portal jedepose.com Operational Electronic notarial acts Notarial acts certify the authenticity of an act signed by parties. It is given evidence value as it can not be refuted, it certifies the date of the act and it is enforceable. Operational Electronic criminal records Will enable citizens to file a judicial complaint and obtain online up to 15 justice related documents such as criminal records, copy of civil, commercial, social or criminal judgments. This involves these acts to be electronically signed by the competent public agency Implementati on stage Germany Federal company register platform (Elektronische Handelsregisteranmeldung) using the German EGVP system General portal for the submission of official documents to the company register. Operational http://www.handelsregister.de www.egvp.de Greece Courts of Piraeus, Thessaloniki and Athens The electronic filing of lawsuits, provision of information on lawsuits and filing of applications for the issuance of certificates from Courts. Operational Extracts from the penal register http://www.ypiresiespoinikoumitroou. gr A specific web page for the Penal Register, where the citizens can also find the application for the request of an extract from the penal register online Implementati on stage 54 54 The First Instance public prosecutor's offices of six (6) cities Athens, Piraeus, Thessaloniki, Patras, Heraklion, Volos. Currently the online service is only available for the Athens Penal Registry Service. Page 147 of 228

Hungary Ireland Electronic company registration Security of Legal Transactions Service Small claims on-line www.smallclaims.ie Lawyers fill out a form with a form filling program than sign it and through e-mail send it to the Firm Court. That replies with a digitally signed proof. (can also be used through Client Gate) Notaries and lawyers can access the data of the Personal Data and Address Registry in order to check the validity of the person that they are dealing with. (through Client Gate) Consumer disputes before a small claims court Iceland No details provided No details provided N.A. Italy E-civil trial ( processo civile telematico ) http://www.processotelematico.giusti zia.it/pdapublic/index.jsp The application allows external users, mainly lawyers, to upload documents, signed with digital signature and encrypted, and to create an electronic file of the proceedings. Latvia No details provided No details provided N.A. Operational Operational Operational Implementati on stage Liechtenstein No details provided No details provided N.A. Lithuania No details provided No details provided N.A. Luxembourg No details provided. No details provided. N.A. The Netherlands No details provided No details provided N.A. Norway No details provided No details provided N.A. Malta 55 ecourt service The service will give lawyers and legal procurators the possibility to submit judicial acts to the Courts of Justice online Implementati on stage Poland No details provided No details provided N.A. Portugal Electronic Postmark System Platform for the communication of acts and other judicial proceedings by lawyers, judges and DAs (procuradores do Ministério Público), essentially creating an electronic equivalent to registered mail. Operational Romania No details provided No details provided N.A. Slovakia No details provided No details provided N.A. Slovenia Register of Wills Contains information about wills prepared in the form of notarial act, wills deposited at notaries, wills prepared or deposited by attorneys Operational 55 Information kindly provided by M. Adrian Camilleri of the Malta Information Technology Agency after the finalization of the Maltese country profile. Page 148 of 228

Spain The Justice Administration the application LexNET. and wills prepared or deposited at courts. The secure delivery of information and notifications by e-mail. Sweden The electronic file Documents are submitted electronically to the courts Turkey United Kingdom National Judicial Network Project (UYAP) Lawyer Portal In this system, every kind of data and document flow is carried out electronically and the system assures that the laws, court s interpretation of the law, circular, similar case writings and similar information can be reached even during the hearing. The Lawyer Portal is open only for certificated Lawyers. With this system, lawyers can obtain information including the progress of the cases, date of hearing and they can carry out judicial procedures online via the Lawyer Portal. No details provided No details provided N.A. Operational Under development Operational Operational Page 149 of 228

4.6.3.2 Type of authentication method and authorisation management In the table below, we will provide an overview of the method of authentication used in the identified ehealth application for each country (using the classification above), and explains if/how authorisation management is addressed. Country Authentication method(s) Generic mandate and authorisation models Austria Hard crypto token The applications build on the citizen card concept. The certificates of these professional signatures include an object identifier indicating the particular role. The competent authorities (Chamber of Lawyers, Notarial Chambers, Chamber of Architects and Consultant Engineers) are in charge of attesting the profession or of revoking it in case of cessation. When using qualified certificates, these are citizen card implementations. Belgium N.A. N.A. Bulgaria N.A. N.A. Croatia Hard crypto token The FINA smart cards play an important (but not exclusive) role in ejustice applications, with username/password systems playing a smaller role. Authorisations/mandate management are largely handled on an ad hoc basis. Cyprus N.A. N.A. Czech Republic Soft crypto token The Czech justice follows the same rules as the communication with any other public authority so there is also used an advanced electronic signature based on qualified certificate issued by an accredited certification service provider containing a social security number. Denmark 56 Soft crypto token The OCES soft signature certificate is used. Estonia Hard crypto token Not applicable in the example given (company creation). In other cases authorisation details can be derived from specific registers, with support implemented on a case by case basis. Identification is done on the basis of the generic solutions (eid card, and in most cases the bank card as well). Finland Hard crypto token or password list The eidm functions are to be integrated using the national VETUMA authentication and payment gateway service. The VETUMA service provides an authentication gateway service that can be used with the FINEID card and TUPAS tokens to access electronic services. France Hard crypto token The qualified electronic signatures infrastructure for clerks is in place since 2007, despite the first e-notarial acts has not been 56 Information kindly provided by Mrs. Charlotte Jacoby of the Danish Ministry of Science, Technology and Innovation after the finalization of the Danish country profile. Page 150 of 228

issued until October 2008. Clerks can use an electronic signature certificate stored on an USB key with a chip, the so-called REAL» key, provided by the company Oberthur. The French professional Order of Clerks (Conseil Supérieur du Notariat) acts as Certification and Registration authority and fabricates the card and deliver the PIN code. The Local Council to which the clerk belongs to acts as Delivery Authority. Germany Hard crypto token The S.A.F.E. Secure Access to Federated E-Justice/E- Government concept aims at the secure registration, authentication and authorization as well as the secure storage of communication participants 57. Since these aims are of common interest for most E-Government services also beyond communication and beyond E-Justice, the S.A.F.E. concept covers E-Justice requirements in a specialized part build on a more generalized one. Implementation starts in 2009, production rollout in the area of E-Justice is scheduled for 2010. S.A.F.E. defines a technical framework for interoperable and safe usage of Digital Identities across administrative borders ( Trust- Domains ) and is set up from the Web Service Protocol Stack ( WS-* ) of OASIS and W3C. The S.A.F.E. infrastructure is organized in Trust-Domains (TD). All S.A.F.E.-TDs have a similar structure and have to provide identical services. A S.A.F.E.-TD is divided in three subsystems - Attribute Service (AS), Provisioning Service (PS) and Identity Provider (IdP) - plus an Identity-Store. One major requirement for eidm is the ability to handle application- /sector specific sets of attributes (e.g. roles assigned to identities, may be even depending on the scenario to be served. Greece Password or PIN token Access is granted mainly to lawyers of the corresponding Bar Association, who are given a user name and a password (no electronic signatures are used). Hungary Ireland Hard crypto token Password or PIN token Password or PIN token Iceland N.A. N.A. On the other hand in a PKI certificate it is possible and also allowed by data protection to store attributes of the user. In practice lawyers (possibility) and notaries (obligation) are often having qualified digital signatures that contain the attribute that they are lawyers or notaries. One of the services that is available through the client gate with the usage of these certificates is The Security of Legal Transactions Service. In this case the notaries or lawyers are signing on at the Client Gate with their username-password and than when they use the service they also sign an online form with their digital signature from which the service provider can retrieve the notary/lawyer attribute and based on that can allow access to the service. No generic model is in place yet; solutions are largely ad hoc. 57 For details see: http://www.justiz.de/erv/grob- _und_feinkonzept/abstract_of_the_core_concepts.pdf Page 151 of 228

Italy Hard crypto token The personnel of the Ministry of Justice (basically judges and clerks) have access to the service through a smart card (Public Employee Card), while lawyers will use a smartcard as well. The card is very similar to the EIC and has both a laser band and a microchip, which may contain a certificate of digital signature. The determination as to whether the user is authorised to use the application is made through the interconnection with the professional associations if the user is a member of the association (e.g. lawyers). Latvia N.A. N.A. Liechtenstein N.A. N.A. Lithuania Luxembourg N.A. N.A. The Netherlands N.A. N.A. Norway N.A. No specific model has been implemented yet. The National Courts Administration has drafted a document on electronic communication with the courts in April 2009, indicating that a portal should be established, to cover the most basic needs, and making use of the national eid interoperability hub. It is deemed that the eid and PKI solutions that are and will be use in the hub will cover the needs also in this area Malta 58 Soft crypto token No details available yet (still in implementation stage); the service will use the Maltese eid (together with the digital certificate) and will be restricted to lawyers and legal procurators only. The eid of the lawyer and legal procurator will serve to identify the person who is requesting the service. Poland N.A. N.A. Portugal Hard crypto token Lawyers use signatures issued by the CA Multicert, with certificate confirming the professional capacity of the signatory, based on the Portuguese Bar Association as an RA Romania N.A. N.A. Slovakia N.A. N.A. Slovenia Soft crypto token To use the online application the prior registration of a qualified digital certificate is needed. The application is fully functional. The authentication process is based on existing PKI in Slovenia with registered Certification Authorities governed by the ECESA. Spain Hard crypto token Providing maximum security and reliability thanks to the use of a qualified signature. Sweden N.A. N.A. 58 Information kindly provided by M. Adrian Camilleri of the Malta Information Technology Agency after the finalization of the Maltese country profile. Page 152 of 228

Turkey Hard crypto token In 2007, the Ministry of Justice reached an agreement with the public e-signature provider, for the delivery of 40,000 e-signatures for all judges, prosecutors and staff. United Kingdom N.A. N.A. 4.6.3.3 Conclusions Thus, 17 countries provided information in relation to their ejustice eid policies (noticeably less than the 20 for ehealth), whereas the others did not report significant use cases of eid in ejustice applications. Of these 17 countries, 4 only reported use cased that were in pilot/development stage, and these will not be examined further. In the remaining 13 countries, 14 use cases were reported: 6 out of the 13 descriptions relate to court proceedings and court administration ( the Czech Republic, France, Greece, Ireland, Portugal, Spain and Turkey; Three relate to the establishment and management of companies (Estonia, Germany and Hungary); Five related to authentic document archiving services (Austria, Denmark, France, Hungary and Slovenia). Looking at the authentication means reported in these 12 countries: Hard crypto tokens are again the predominant form of electronic authentication, being reported in 7 out of 12 countries (Austria, Estonia, France, Hungary, Portugal, Spain, and Turkey). Soft crypto tokens were reported in the Czech Republic, Denmark and Slovenia. Finally, Password or PIN tokens were reported in Greece, Ireland and Hungary (albeit in the latter case relying on a registration system supported by a signature certificate). Similarly, the Greek approach allows courts to perform registration to improve the reliability of the issued credentials. Page 153 of 228

4.7 Technical / infrastructural analysis This section will describe for each of the surveyed countries what kind of technical infrastructures are currently used. A focus of this section is to present all technologies used inside Member States. 4.7.1 Commonly used tokens This section will describe which tokens (if any) are commonly distributed to entities in the surveyed countries. These tokens include any hardware or software or combination thereof that contains credentials, i.e. information attesting to the integrity of identity attributes. Apart from identity cards, examples can thus include USB sticks or cell phones containing PKI certificates, or even the certificates themselves. To achieve full picture of used egovernment authentication methods also plain username/password table has been added. The main purpose of this section is to provide valuable information regarding standards and methods used inside countries to provide basis for more advanced interoperability planning. Apart from previous sections also explaining distribution of different type of tokens, this section is more technically oriented. 4.7.1.1 Card systems This section will describe which hardware based tokens are used in the surveyed countries. These tokens include real manufactures and types of devices or either list of commonly accepted standards. Type of description depends on the surveyed country, some of the countries have specified the tokens in to the smallest details and others are more just specifying that what type of standards should be followed with eid tokens. The main purpose of this table is to provide valuable information for interoperability study around citizens. When addressing the eid infrastructure from end user (citizen) point of view most challenging part of the interoperability for the citizen is the authentication device (or method) he/she uses. In most cases the authentication device and the authentication process is only thing citizen sees from the eid system. When citizen is using his/her authentication device inside home premises this challenge usually does not exist, but when used becomes mobilized and acts as an visitor in different Member State questions around token and middleware interoperability will become more important. Specifically, the overview reports: Name of the country. The Manufacturer section lists all nationally accepted vendors. In some of the surveyed countries there is no selection of manufacturer done, in these cases this section will only include information about used standards. The Type / Microcontroller section describes more detailed information about selected device types. In some of the surveyed countries there is no selection of manufacturer done, in these cases this section will only include information about used standards. The Multipurpose section describes scenarios where the surveyed country has chosen hardware token, which can be used with several applications (these include certificates, purse functionalities, health information, etc.). If multipurpose token is used then the underlying technology is described. Page 154 of 228

Country Manufacturer Type / Microcontroller Multipurpose Austria Not specified, all certified smart cards can be used. Common Criteria certifications at EAL4+ for the ChipOS and EAL5+ for the chip platform together with a formal confirmation of the notified body A-SIT are needed. Belgium Axalto Cryptoflex JavaCard 32K / Infineon SLE66CX322P and an additional crypto processor (for RSA and DES computations). Bulgaria N.A. N.A. N.A. Croatia N.A. N.A. N.A. Cyprus N.A. N.A. N.A. Czech There is a plan on eid implementation, but it is at an early stage. There will be two types of ID cards (a smart card and a plastic card without chip). Denmark OCES digital signatures are software-based digital signatures. Certificate can be stored as a soft or hard token N.A. N.A. Estonia Orga 59 Micardo COS with a crypto-processor. Finland FINEID (Citizen card): Gemalto (Setec). The FINEID profile complies with ISO/IEC 7816-15. 60 Organization card: FINEID: SetCos 5.1.1B / 72 Kb (64 Kb stated) EEPROM memory, where only a minor part is allocated to additional certificates or data objects. Much of the No common usage. Depending on the issuer, other applications such as health card certificates for the health insurance card or ATM and electronic burse functions for the bank cards are provided. Yes, Java Applet handles all communications with the outside world. The eid card also has the capability to contain programmes which can be run within the card processor chip. N.A. N.A. Not Specified YES, Java Open Platform card. The FINEID specifications do not allow the use any additional applications. 59 The current supplies of ORGA cards will end at 2008. For that, preparations for the new card platform have been started. There has been developed a prototype on the current ESTEID card application on MultOS-compatible cards, so in all likelihood MultOS will be the next platform for Estonian ID-cards. 60 Based on low usage of citizen cards Finland is currently changing their FINEID strategy. Current smartcard based citizen certificate system will be changed. New certificate carrier has not been chosen, but discussions are indicating the usage of different type of USB memory devices. Page 155 of 228

Issued to natural persons with professional usage. Oberthur Card Systems Finland The JavaCard Applet is produced by Charismathics Gmbh and it follows the same Applet command interface specification as the citizen FINEID applet. memory space is left unused. Organization card: Oberthur Cosmopolic 5.4 RSA 64 JavaCard platform, which is SSCD certified. France Not Specified. A three layered authentication specification in use, these levels deploy different set of requirements (Middle, Strong and Strengthened). 6162 Not Specified, same levels apply as in manufacturer. 63 Three smartcards: Vitale Card 2: different 32ko Eeprom memory, crypto-processor, certified common criteria EAL4+ (PPSSCD;PP9911) and standard ISO7816 and EMV. Not Specified The Healthcare professional Card: The security level is EAL4+. This card contains a microprocessor and a cryptographic coprocessor. (ISO 14443A or ISO 14443B at 13,56 MHz.) The future national eid Card: The future National eid card will adopt the format of credit card. It will be based on the ECC standards. (Type and 61 Middle: Generation in a cryptographic module compliant with the requirements in the CP Template. Strong: Generation in a cryptographic module certified at a level CC EAL2+ Strengthened: Generation in a cryptographic module certified at a level CC EAL4+ 62 Used smart cars standard are ISO 7816, ISO 7816-15 and PKCS#15 for certificates X509 V3. 63 New so-called Vitale 2 is 32ko Eeprom memory, crypto-processor, certified common criteria EAL4+ (PPSSCD;PP9911) and standard ISO7816 and EMV. Page 156 of 228

Microprocessor not specified yet, uses level strenghtened). Germany Qualified electronic signature implemented on a variety of smartcard types. 64 Greece In general known industrial standards are used. 65 The smart cards are SysGillo CryptoSmartCard from the InCard ST Microelectronics Variety of smart card types. Common Criteria EAL4+ certified. No available specifications N.A. Hungary N.A. N.A. N.A. Iceland Different manufactures. Typically different Bank cards 66 are used. Other cards 67 are cards available to all that either cannot get bank cards or for some other reason want special cards e.g. employee cards for companies. Both use (ISO-7816 PKCS#15). N.A N.A. Ireland N.A. N.A. N.A. 64 It can be stated that everything contained in the framework has been subject of international standardization. So when ISO 24727 and the respective CEN profiles like e.g. the European Citizen Card (ECC) will be finalized, the ecard API will be a compliant specification. 65 Commonly used standards like ISO/IEC 15408-3; ISO 17799; ETSI TS 101 456; ITSEC-E3 FIPS 140-1. 66 eids on bank cards will be the main eid token in Iceland in the near future. The National registry has also been planning for the issuance of citizen cards with certificates, but nothing definitive has been decided on this. 67 These certificates are issued under the same intermediate certificate as the certificates on bank cards and fulfil the same requirements. Page 157 of 228

Italy Latvia There are several card manufacturers able to supply cards. Currently used suppliers are Siemens, Incard and Oberthur A smart card vendor yet to be decided, Contact ICs (ISO 7816) with PKCS#15 structure. 68 While Siemens and Incard offer native operating systems, Oberthur offer a Java card. In all cases, the OS comply with the CNS specification and are thus interoperable. 64KB EEPROM. Lichtenstein N.A. 69 N.A. N.A. Oberthur offer a Java card. Not Specified. Lithuania Not Specified, must comply to Common Criteria EAL4+ and CA private keys held in PKCS #11 devices FIPS 140-1 level 1 to level 3 key protection (with the help of ncipher and/or Chrysalis) 70 Not Specified, must comply to Common Criteria EAL4+ and CA private keys held in PKCS #11 devices FIPS 140-1 level 1 to level 3 key protection (with the help of ncipher and/or Chrysalis) Luxembourg N.A. N.A. N.A. Malta N.A. N.A. N.A. The Netherlands N.A. N.A. N.A. Norway N.A. N.A. N.A. Poland No specific details, planned pl.id initiative only available. Portugal e-card is Gemalto Cryptoflex JavaCard 64K N.A. It is equipped with a 16 bit microcontroller (Infineon SLE66CX322P) and an additional crypto processor (for RSA and DES computations). Not Specified It is only known that it will be a multiapplication eid card compliant with the European standards requirements (mainly with EN 15480 Identification card systems - European Citizen Card). A Java Applet implements the Chip Authentication Program (CAP). 68 eid cards are not still available because of ongoing discussions regarding concept and appropriate solution, details listed are based on preliminary planning. 69 The hardware specifications will be mainly based on the indications given by A-Trust, 70 Technical specifications of the certificates issued by UAB Skaitmeninio sertifikavimo centras Page 158 of 228

Romania N.A. N.A. N.A. Slovakia N.A. 71 N.A. N.A. Slovenia 72 Gemplus PKCS#15 (HIC Card), ActivIdentity smartcard (SIGOV- CA) Spain Type is not specified, but it uses following standards: ETSI TS 102 042,ETSI TS 101 456, ETSI TS 101 862, CWA 14167, CWA 14172, CWA 14.890. The cards used for the national eid card and the Royal Mint follow the standards PKCS#11, CSP and API PC/SC HIC Card: Samsung S3CC91C chip (pure contact chip with 7816 interface and 72K EEPROM available for storing data) with Java Card operation system provided by Gemalto (EAL 4+ evaluated.). The eid card uses contact ICs, with ISO 7816-3 compatible access and with an EEPROM size of 34 Kb for data. Common Criteria Certification at EAL4+ certification as a smart card and a Secure Signature Creation Device. N.A. Multipurpose card supporting Java Applet and Active esignature creation programs over the middleware layer. Sweden Nordea: Setec TAG AB (PKCS#15 profile), with the operating system SetC0S version 4.4.1. 73 Steria: The cards used are operating system Setec SetCOS (various versions) and Cryptoflex from Axalto. Nordea: Not Specified uses ISO 7816 standard. Steria: Not Specified uses ISO7816 standard. BankID: Not specified, uses ISO 7816 standard for readers. TeliaSonera: specified. Not Not Specified BankID: Oberthur (Siemens Cardos 4.3b), Gemalto (Setcos 4.4.1) and 71 With regard to future plans, when there will be a central eidm system, the authentication mechanism will be based on PKI and the private key will be included on the smart card with contact ICs (specified in ISO 7816) or with dual interface ICs (one chip and two interfaces contact ISO 7816 and contactless ISO 14443). 72 A smartcard specification has only been defined for health care cards, egoverment CA s can issue several type of smartcards. 73 Nordea s bank cards (XponCard with operating system Proton Prisma EMV) can also be used as the carrier of the eid. Page 159 of 228

Gemalto (Javacard with eid2048 applet). All cards have a PKCS#15 profile. TeliaSonera: cooperates with the Swedish bank SEB offering eids to SEB s Internet customers. Turkey N.A. 74 N.A. N.A. The United Kingdom N.A. N.A. N.A. 4.7.1.2 Middleware applications This section will describe which middleware applications are used in the surveyed countries. The Middleware in this context is seen as a layer between hardware based tokens and egovernment applications citizen is accessing. Type of description depends on the surveyed country, some of the countries have specified the middleware in to the smallest details and others are more just specifying that what type of standards should be followed with middleware applications. The main purpose of this table is to provide valuable information for interoperability study around citizens. When addressing the eid infrastructure from end user (citizen) point of view most challenging part of the interoperability for the citizen is the authentication device (or method) he/she uses. When a citizen uses his/her authentication device to access the service the local system needs to be able to read the identity information from the device. In this sense the description and functionality of selected middleware standards is as important as used authentication token (both needs to exist for the successful citizen logon). As also described in previous token section most challenging user is the travelling one. These questions were provided to the countries so that complete picture of currently used middleware standards could be established and input from this query could be used to provide more accurate methods for pan-european eid system. Specifically, the overview reports: Name of the country. The Description section provides information about potential provider of the middleware application. In some of the surveyed countries no provider has been selected, but rather just a list of necessary standards are published. The Availability section provides information about the openness of the used middleware application. The main goal is to provide information if the middleware application is publicly available or if it is property of a private company. The Details section provides more accurate information about usage of the middleware application. The main goal is to provide information about used access standards and toolkits, which could be used to integrate national token to selected egovernment services. 74 Secure signature creation devices shall be conformant to CWA 14169 or assured to EAL4+ in accordance to ISO/IEC 15408 (-1,-2,-3). Based on The Electronic Signature Law no:5070 and its bylaws. Page 160 of 228

Country Description Availability Details Austria The middleware citizen card environment integrates the various tokens. Belgium Developed for the Belgian government by Zetes. Different supported tokens can be added to middleware (e.g. other Member State tokens). The source code has been made publicly accessible Bulgaria N.A. N.A. N.A. Croatia N.A. N.A. N.A. Cyprus N.A. N.A. N.A. Czech N.A. N.A. N.A. Denmark An Open Source component (OpenSign/OpenLogon) has been developed. The component offers client side login and web-signing functionalities. Estonia Supporting interfaces to applications like MS Crypto API (CAPI) and PKCS#11 have been developed. Multiplatform PKCS#11 driver is integrated to OpenSC. An ID-Card utility has been developed and released. The source code has been made publicly accessible Open and available products. Access is provided via native ChipOS interfaces. Accessed through CryptoAPI without knowing anything about the underlying implementation, the CSP part of the middleware establishes the link between the abstract CryptoAPI and the underlying PKCS#11 interface.( in non- Microsoft applications, the PKCS#11 (v2.11) interface is used) Application developers can use functions of open source component to add logon and signing functions to their applications. Application developers can use functions of open source component to add logon and signing functions to their applications. Page 161 of 228

Finland France Developed by several companies, including Setec/Gemalto, Nexus/ID2 and Fujitsu Services Finland. A specific middleware has been developed by the DGME/SDAE and a private consortium of cards industries, GIXEL (Cards Industrial Group - Groupement des Industriels de la carte). In 2007 the PRC selected the Fujitsu s mpollux DigiSign Client as the specific middleware applications intended to be used together with the card. The PRC acquired a global license for the solution, which can be downloaded free of charge 75. Other middleware applications have been developed by several companies, including SecMaker Net id, Charismathics and Setec/Gemalto, There is also an Open Source middleware (OpenSC) that supports the FINEID. These modules are delivered together with tools facilitating the use of cards and certificates. This middleware can be used either with smart cards or USB keys. In particular, it is foreseen to be used with civil servant s cards (carte Agent), Vitale cards 2, future national eid cards and with any other card compliant with the IAS standard. Germany ecard-api-framework Relevant projects for this strategy are: electronic Health Card (egk) electronic ID card (epa) electronic passport (epass) electronic tax return (ELSTER) electronic notification of wages and salaries (ELENA) A CryptoAPI is an application programming interface for cryptographic operations in Windows environment. The DigiSign CSP enables applications to use smart cards to perform digital signatures, and to encrypt/decrypt files or messages using algorithms such as 3DES, SHA, MD5 and RSA. API standards: CWA 14169 (PP Secure Signature Creation Device) CWA 14890 E- Sign Area K (Application Interface for Smart Card used as Secure Signature Creation Device, Part 1 and 2) Both authentication application and module to verify the authentication process are required to be certified at a level EAL2. 76 The ecard API consists of 4 different layers: The application layer defines the interface to be used by an application to integrate the framework Identity layer providing identity, signature and encryption services Service access layer 75 http://www.fineid.fi/vrk/fineid/home.nsf/pages/04b87acd4ff07dbdc2257054002e14f6 76 Exception is the middle level authentication where no requirements exist. Page 162 of 228

including an ISO 24727-3 interface plus supporting functionality Terminal layer for integration of the full variety of possible card terminals over an IFD interface Greece Common specifications Not specified Software characteristics compatibility and PC/SC Compatibility, automatic update in Windows environment, optional CSP interface, optional PKCS#11 interface. Hungary N.A. N.A. N.A. Iceland Citizens are also provided with CSPmiddleware 77 (MS-CSP, PKCS#11, AppleCSP). Support for CEN TS 15480 and ISO 24727 is planned. The company Auðkenni hf. (company owned by the banks) provides the middleware Ireland N.A. N.A. N.A. Italy For all these cards, the standard PKCS#11 and CSP. For the EIC 78, a specific EIC-API middleware was also made available, to simplify the use of the card by software developers. Latvia Used middleware standard will be PKCS#11. Middleware is available and often published on the issuer web site. Not specified Lichtenstein N.A. 79 N.A. N.A. (MS-CSP, PKCS#11, AppleCSP). Support for CEN TS 15480 and ISO 24727 is planned. Applications can access used smart card through PKCS#11 and vendor CSP. EIC-API can also be used. Not Specified 77 http://skilriki.is/notendur/debetkort/hugbunadur/ 78 National eid card 79 The technical aspect of the specific middleware is based on guidelines, EIF-specifications and standards. Page 163 of 228

Lithuania For e-id card the specific middleware to be used together with the card has been developed for Gemalto Middleware for Gemalto Sealys Multi App ID Classic Client 5.15 (Gem Safe 5.15). The source code can be downloaded from http://www.dokumentai.lt/ Luxembourg N.A. N.A. N.A. Malta N.A. N.A. N.A. The Netherlands N.A. N.A. N.A. Norway Not specified Several different private sector certificate providers. Not specified. Poland N.A. N.A. N.A. Portugal For e-card a A specific middleware to be used together with the card will be developed for the Portuguese government by Zetes. 80 High-level APIs will be developed by Multicert and will constitute the application level interface for e- Government applications that use cryptographic operations from the smartcard (qualified digital signature and authentication) and PKI related services (timestamping, LDAP validation, OCSP validation). An e-id application development kit will be available online. Development cards that are functionally equivalent to actual e- ID cards will also be available. Romania N.A. N.A. N.A. Not specified Certificates should be available for running Microsoft Certificate Store. Operations with private keys should be available for applications using Microsoft CRYPTOAPI or PKCS#11. Not Specified 80 This middleware is a low-level API that bridges between the application itself (or high-level API) and the device actually performing the cryptographic operations (the e-id card, in conjunction with the compatible card readers). Page 164 of 228

Slovakia N.A. N.A. N.A. Slovenia Several different middleware s in use. Spain The middleware that interacts with the eid token. Sweden 81 Nordea: Nexus Personal supports both CSP and PKCS#11. BankID: On the client side BankID provides an authentication and signing plug-in that all users must use. On server side certified software for validation needs to be used. TeliaSonera: Provides CSP support through the program NetiD from NetMaker. Related middleware is distributed by CSPs themselves and it is always card vendor dependant CSP and PKCS#11 interface can be obtained from www.dnielectronico.es/descargas. Nordea: Commercial product. BankID: Clients can receive necessary plug-ins and development tools TeliaSonera: products. Commercial Turkey N.A. N.A. N.A. Related middleware solutions usually follow standards PKCS#11 and CSP. It is compatible with Microsoft Systems (CrypoAPI or CSP) and PKCS#11 standard utilized in Mozilla, Linux and Unix Systems among other systems Nordea: Usage through Nexus Personal, CSP e.g. for internet explorer and PKCS#11 for developers. BankID: Usage of plugin, there are also some applications that are allowed to code directly towards the CSP/CAPI-interfaces to provide third party solutions. TeliaSonera: Usage of commercial solutions. The United Kingdom N.A. N.A. N.A. 4.7.1.3 Username / Password systems This section will describe the different password based systems used in egovernment applications in the surveyed countries. These systems include static passwords and different type of one-time password system. The main identifier of these systems is the fact that it is used and accepted as an authentication method inside the surveyed country. The main purpose of this table is to provide valuable information about accepted passwords systems in Europe. This will clarify the need for creating different levels of authorization in pan-european eid system. These types of systems can be used as an authentication method inside citizen home country, but regulations in other Member States can restrict the usage of such systems in pan-european context. Specifically, the overview reports: 81 The latest public procurement process in 2008 led to the following suppliers of eid services: The framework agreements are valid until June 2011. Page 165 of 228

Name of the country. The Description section provides the name of the described system. The User group section provided the information about described system potential users. The Details section provides more accurate information about usage and functionalities of the described system. Country Description User group Details Estonia Bank ID Users of Estonian Banks (Estimated at 1.1 million). Finland The Finnish Banker s Association paper token framework (TUPAS). Lithuania The Netherlands ebanking authentication DigiD Estimated at 4 million (requires bank account in at least one of the Finnish Banker s Association member banks) Customers of nine commercial banks of Lithuania Registered users of DigiD system. Several egovernment services are built to support DigiD authentication. Password cards (with 24 codes) and PIN-calculators. (solution depends on bank) 82 The TUPAS service does not require any separate hardware or software as it is based on One-Time-Passwords (OTPs) printed on paper. The user is given one to two pass-code lists (depending on the bank), a static user name and a static private password. Only name, surname and personal code (from the codes card or electronic codes generator) of the person held by the bank are used for authentication of users of egovernment services. In most cases username and password is enough. Option is to add one-time SMS code to authentication stack (code is sent to users mobile phone). 4.7.1.4 Mobile tokens This section will describe which mobile tokens can be used in egovernment applications in the surveyed countries. These systems include certificate based access methods and one-time SMS message systems. The main identifier of these systems is the fact that it is used and accepted as an authentication method inside the surveyed country. The main purpose of this table is to provide valuable information about accepted mobile token systems in Europe. The concept of the mobile authentication device, which does not require additional software or hardware installations in case of the visiting citizen, is important. The nature of the mobile 82 In some cases ID-Card it self can be used for bank authentication. It is expected that banks will cease providing authentication services to 3 rd parties. This means that all e-service providers relying on Bank eid authentication shall turn their users to use of PKI-based solutions ID-card and Mobile-ID. Page 166 of 228

authentication device makes it possible that one specific mobile device can cover all previously presented challenges around visiting citizen (one device can at the same time be identity carrier, identity reader and a middleware application). Specifically, the overview reports: Name of the country. The Description section provides the name or/and some information about the system. The user group section explains and lists all users of actual solution. The Details/Authentication usage section provides more accurate information about usage of the mobile token. Country Description Users group Details/Authentication usage Austria Mobile signatures offered by any operator. Any mobile phone subscriber Estonia Mobile-ID Was introduced to Estonian market in May 2007 mobile operator EMT (Two other main mobile operators (Elisa, Tele2) are expected to start providing Mobile-ID during the second half of 2009.) Since Q4 2009, mobile phone based identification is possible in certain egovernment application (e.g. income tax declaration), using qualified certificates in which a hardware security module (HSM) managed by the operator functions as an SSCD storing the cryptographic keys, making the solution an application of the generic Austrian citizen card concept resulting in qualified signatures 83. In order to get Mobile-ID, the user needs to replace a SIM-card with the PKI-capable one. Although the registration process is performed by the mobile operator, it is not considered trustworthy enough. Therefore the user needs to activate his/her Mobile-ID with ID-card in the web environment. In this manner issuance of the Mobile-ID is bound to the security and quality of 83 Information kindly provided by M. Peter Kustor of the Austrian Federal Chancellery after the finalization of the Austrian country profile. Page 167 of 228

the ID-card. Hungary SMS OTP solution OTP identification is quite wide spread among Hungarian banks and the administration is also considering to use an SMS OTP solution. Lithuania Mobile-ID Two Lithuanian public mobile telephone communication operators UAB Bite Lietuva and UAB Omnitel provide mobile electronic identification solutions. Bank customers can use the solution. The Netherlands DigiD / SMS Registered users of DigiD system. Norway BankID This is a service which is only available to customers that have Telenor as mobile operator. One-Time-Password logon to Bank services. Password is sent to user as a SMS message, which is then used to logon to service. The customers of these operators can order esignatures by signing the agreement on esignature service. Thereafter, to the customer is issued a special SIM card with installed secure cryptographic modules and two digital certificates: a connection certificate and a signature certificate. The esignature certificate conforms to the requirements of a qualified certificate. Medium level authentication to egovernment systems. One-time SMS code is sent to user s mobile phone. The key is stored in the SIM-card. To log-on one enters the telephone number and the date of birth (day, month and year), and a code appears on the webpage and on the mobile phone, which must correspond to each other. Page 168 of 228

Buypass Mobile-ID Slovenia Mobitel WPKI (Wireless PKI) qualified certificates. Sweden BankID in cooperation with Telia and Telenor (two mobile phone operators) Not yet implemented. The solution is not linked to a special mobile operator. Foreign SIM-cards can also be used. Norsk Tipping and its internet users are the first users of this application. Mobitel is offering all interested CSPs to integrate their systems with its solution and at the moment one CSP is already issuing mobile certificates but several others are upgrading their systems so that they will be able to issue these certificates, too. Telia and Telenor customers. Not specified, works on all mobile telephones that support Java Keys of mobile certificates are stored on a SIM of the mobile phone. eids that are integrated in SIM-cards on the user s mobile phone. The use of these mobile solutions within egovernment applications is not yet determined. 4.7.1.5 Other tokens This section will describe all the token models not fitting to any of the above categories. These are the systems developed as ad hoc for one of the surveyed countries. Specifically, the overview reports: Name of the country. The Description section provides the name of the system. The user group section explains and lists all users of actual solution. The Details section provides more accurate information about usage of the ad hoc token. Country Description User group Details Belgium The federal paper token Belgium national and non-nationals A small paper card with 24 personal codes. Authentication Page 169 of 228

holding identity card number, the national registry number and the social security card number. It should be noted that the federal paper token is expected to be phased out it the next few years in favour of the national eid card. is two-factor authentication: the user enters his chosen username and password, and the system prompts him for one of the 24 personal codes on the token. Based on the national infrastructure tables, the following global conclusions can be drawn: Out of 32 countries, 17 have set detailed specifications to hard tokens (13 in previous study). Out of 32 countries, 2 have created initial plans for hard token implementation. Out of 32 countries, 13 have no specification or advanced planning for hard tokens (17 in previous study). o Some of these surveyed countries might have more detailed specifications, but those are not available for the public. Out of 32 countries, 17 have set detailed specification for middleware applications (12 in previous study) Out of 32 countries, 15 have no specifications to middleware applications (20 in previous study). o Some of these surveyed countries might have more detailed specifications, but those are not available for the public. Out of 32 countries, 9 have some other form of accepted tokens (8 in previous study). o o o 4 out of those countries are using centrally approved username / password systems. 7 out of those countries are using mobile tokens (only 3 in previous study, only country stopping the mobile-id usage has been Finland) Only Belgium is using Government based paper tokens (this solution could also be categorized to username / password systems). Page 170 of 228

4.7.2 Authentication systems (eidm applications) In this section, we will take a closer look at authentication systems and eid applications which are used in the surveyed countries. Correspondents were asked to report all egovernment applications using electronic authentication. I should be noted that these systems are not bind to any specific electronic authentication method (rather it can be any of the following: PKI based, mixed, password based or some other ad hoc based solution.). 4.7.2.1 PKI systems This first section focuses on the PKI based authentication systems. These are the private or public services, which can be accessed using certificate based authentication. Specifically, the overview reports: Name of the country. The Sector section provides the information about who is providing these services. The Services section provides more accurate information about which type of services are included. It should be noted that many of these authentication systems are built to support several back-office services. The Details section provides more information about solution and authentication it self. Country Sector Services Details Austria Public / Private There are several different applications both on private and public sector, so complete list is not applicable. Thus a representative selection is given: Electronic delivery that replaces registered letters, electronic certificate of enrolment (Central Register of Residents), electronic Register of Convictions certificate and e-reporting certain crimes (child porn, repeat offence,...) An open source program has been made available by the federal government. Both the public sector and the private sector can use modules for online applications (MOAs) 84. to integrate citizen card based authentication to their systems. The MOAs include modules for the identification process (MOA-ID), for electronic representation and mandates (MOA-ID+ and MOA-VV), for electronic delivery (MOA-ZS), and for server-side signature creation and signature validation (MOA-SS/SP). 84 http://egovlabs.gv.at/ Page 171 of 228

Belgium Public Consultation of the National Register, on-line registration of applications for public functions, on-line tax declarations, safe chatting for minors, and ordering attestations for provided medical aid Belgium Private The KeyTrade access management system, offering secured access to e- banking applications; see https://secure.keytradebank.com/login.h tml?lang=en The EasyPay HR software (including access management and time registration) which has integrated the eid card; see http://www.easypaygroup.com/fr_be/ ebay account verification: existing Belgian account owners can validate their accounts to increase their reliability in the community; see http://pages.befr.ebay.be/help/idverify_p rocess.html The Planet winner system, which automates entering customer information for hotels and restaurants; see http://www.planet-winner.com/ For a more complete list, see http://map.eid.belgium.be/fr.html or http://www.ibz.rrn.fgov.be/index.php?id= 599&L=0. Bulgaria Private Some in area of electronic signature. Almost all of the operational egovernment applications obtain the UCN directly from the certificate for the electronic signature of the user. Croatia Private (ebusiness) Presents the services like The eregos (The Central Registry of Insured Persons) Project, The epdv (VAT) Project, The ecrew Project and The ecustoms Project. Users of the system can access services using certificates stored on The FINA E-CARD. Czech Private Some usage of certificates. The personal identity number can be bind to qualified certificate issued by private CA. Certificates are usually soft tokens. Denmark Electronic services for OCES digital signatures Log-on with digital signatures: 5 pensions fond, 90 public authorities - more than 150 services and 25 private companies Implemented Employee signatures: 22 public administrations Log-on to the services can usually be conducted using soft or hard token. Page 172 of 228

Secure e-mail: 400 public authorities and 20 private companies Estonia Public The most notable service is the Citizen Portal. Through Citizen Portal users can access the vast majority of public services (SSO). Others include: the Estonian Tax and Customs Board and e-schools. ID-card is considered as an enabler of Internet voting 85 which was introduced in 2005 for elections of local governments and repeated in 2007 for elections of the Parliament. One of the most popular e-services accessible with ID-card is e-school 86. Private sector also utilizes usage of ID- Card to their services, these include: Internet banking (optional) and several other private companies. Estonia Public Using the unprotected part of the Estonian ID-Card more public and private services can be activated. These include: ID-Ticketing, car-driver document functionality, ID-Card as a loyalty card, as an entrance card and as a quick registration device. Finland Public The Palkka.fi (or Salary.fi), The Suomi.asiointi.fi, The Change of address notification service for citizens, The Tarkista tietosi!, or check your personal information service, the Tekes.fi service and The Patent registration service Log-on to the services is done using authentication certificate on the ID-card. The personal data file contains the same information that is visibly printed on the card most notably name and PIC of the cardholder. This information can be read without presenting PIN- Code with a reader or terminal. Services are usually offering possibility to use National Id card as an authentication medium, but still most of those authentications are done with TUPAS system. There are also other services available, but those are not mentioned here, because they use e.g. KATSO as an authentication interface. 85 http://www.valimised.ee/ 86 http://www.ekool.ee/ Page 173 of 228

France Public Public sector applications include a wide range of e-processes. A specific website has been established in order to centralise the access to all public services. Germany No available specifications No available specifications Greece Public The PKI services in the framework of the Syzefxis project will be used for authentication of public servants who use information systems of the public sectors, such as the KEP information system, etc. Hungary Public Digital signature case: Any hungarian CA can get the overcertification of the national root CA (KGYHSZ; that has only supervisory and no certificate using roles) to issue administrative digital signatures only in case it provides reidentification service to public authorities for those certificates that were issued for administrative usage. Latvia Public The esignature services: Office of Citizenship and Migration Affairs, State Social Security Agency, Road Traffic Security Office and State Revenue Service Latvia Private Authentication to the banks is possible in Latvijas Krajbanka and Nordea Bank 87. Both banks with regard to their services accept the qualified electronic signature as one option Lithuania Public Personal certificates issued by SSC, mobile operators UAB Omnitel and Bite Lietuva are used as authentication means in the public sector applications. Luxembourg Public Luxembourg has initiated an project of egovernment applications by launching the Counter on 17 November 2008. The purpose of this Counter is to offer a virtual point of single contact to complete online all proceedings and formalities in relation with the PKI based authentication. A series of e-processes such as e-vat or e-income require the use of electronic signature. No available specifications PKI based authentication of public servants. In future same type of infrastructure will be used for citizen authentication. If the certificate and the natural identifiers fit then the citizen is identified. This method is used because the certificate by data protection rules can not contain the natural identifiers (only the name and e-mail address) of the citizen. These services accept documents sent with email, which are signed by a qualified electronic signature. The qualified electronic signature can be used instead of the code card or code calculator issued by the bank for authentication purposes. Requires either a 2 nd or 3 rd class personal certificate, issued by a qualified esignature services provider. The user authenticates with Luxtrust certificate. 87 See the homepage of Nordea Bank: https://netbank.nordea.com/pnb/login.do?ts=lv&language=en&ti=1&cs=117ff04e3f5dfb121b6809b9c5 12b237c719111f Page 174 of 228

Luxembourg administrations within the next few years both. Malta Public, Private Some tax related and public procurement services use eid Level 2 as a method of authentication. Services like: Online VAT return, Corporate e-tax services, ROC Online System and Public Procurement eid Level 2 certificates conform with the the x509 v3 standard are used for authentication. Portugal Portugal Internet Channel / Site Telephone Channel / Contact Centre The site will provide card-based access to electronic services, in order to give people a privileged channel for dematerialised interaction with public and private services. New online services will be made available, particularly in relation to real estate purchases and changes of address, which will only be possible using strong authentication. This channel will enable people to obtain services by telephone The site will also use the single sign-on concept as part of citizens relationships with the Public Administration. Using a one-time password (which they will get via the Citizen s Card and its reader system) to identify themselves and authenticate the transaction. Slovenia e-taxes Filling out and secure filing of tax forms Authentication (and digital signature) is based on qualified digital certificates. Registered users. Slovenia Spain Business oriented services (EPOS, Annual reports and E-business in agriculture) Public sector applications Sweden Public and Private Business entities and users of Agricultural Markets can conduct business communication. Private citizens can use more than 250 eservices that require the use of esignature. There are more than 150 different services where the eid can be used today. Most used public services are in the Authentication and digital signature are based on qualified digital certificates. Authentication and digital signature are based on qualified digital certificates. Not specified Page 175 of 228

field of tax, social security and student allowances. Most private services is in the field of Internet-banking 4.7.2.2 PKI Details This section focuses on the functionality of the Public Key Infrastructure (PKI). These are the main identity providers used in above mentioned PKI based authentication systems. On the PKI side we need to focus on certificate policies, which need to be commonly agreed on the participating countries. We also need to focus on the revocation method used in the surveyed countries. When building an pan-european gateway the solutions will need trust and this can only be achieved when trust chains and full knowledge of the current trust is available. Specifically, the overview reports: Name of the country. The Description section provides the name or nature of the system. The Certificate/PKI Details section describes which types of certificates are provided. The Directory/validation section describes how certificate life circle is managed (revocation and revocation publishing). Austria Country Description Certificate/PKI Details Directory/validation details The Main Association of Social Insurance Organisations (Public sector CA for citizen cards) Austria The A-Trust PKI system (Qualified Private sector CA for citizen cards) Two key pairs: a qualified signature for authentication and the second key pair for electronic signatures or encryption. (192 bit elliptic curve cryptography (ECDSA) for both key pairs.) Current Insurance PKI platform is gradually being replaced. New health insurance card supporting 256 Bit ECDSA will be rolled out beginning 2010 (A-Trust). Two key pairs: a qualified signature for authentication and the second key pair for electronic signatures or encryption. (192 bit elliptic curve cryptography (ECDSA) for the qualified signature and 1536 bit RSA for the second key pair.) Additionally issuance of the next generation bank cards supporting 256 Bit ECDSA starts in 2009. Certificate Revocation Lists (CRL) and the Online Certificate Status Protocol (OCSP). Certificate Revocation Lists (CRL) and the Online Certificate Status Protocol (OCSP). Page 176 of 228

Belgium National ID card Two certificates: one for authentication, and one for electronic signatures, with only the latter being considered as qualified. Each private key is dependent on the use of a PINcode (one PIN-code) Bulgaria Private Private Certificate Authorities Bulgaria Public, Integrated Environment for Exchange of Electronic Documents (IEEED). Croatia Private, The FINA E- CARD. The list of the CSPs issuing certificates for electronic signatures applicable for egovernment applications is available at the Communications Regulation Commission website 88. IEEED will be PKI based and will use Single CA Model. The CA will be part of a hierarchy. The PKI will not be linked to other PKI infrastructures through a Bridge- CA network. The users of IEEED will use UES for signing the exchanged statements and documents. FINA offers the service of certifying and issuing digital certificates to both retail and corporate clients. FINA presently provides three types of digital certificates - signature certificates, authentication certificates and encryption certificates. Both Certificate Revocation Lists (CRLs and delta CRLs) or the Online Certificate Status Protocol (OCSP) can be used Certificate Revocation List (CRLs) are used Not specified FINA (the Croatian CA) is publishing qualified certificates in accordance with the Electronic Signature Act. Czech Private Private Certificate Authorities Not specified Denmark OCES certificates In the OCES framework there is only one level in the hierarchy, due to the fact that the root key of the OCES-CA signs all certificates. The OCES CA has been webtrusted and therefore the root certificate has been included in both Microsoft s and Mozilla s certificate store for trusted authorities. OCES certificates comply with the ETSI TS 101 862, X509v3, RFC 2459 and RFC 3039 specifications. At the moment CRLs are the main supported validation method. An OCSPservice is also available. 88 See at http://crc.bg/section.php?id=182&lang=bg Page 177 of 228

OCES digital signatures are software-based digital signatures. They can also be obtained on hardware (such as etoken or smart cards). No matter the media, the certificate refers to the same certificate policy. Estonia National ID card The Estonian ID-card uses a single CA model. However, CA certificates for ID-card certification tend to change, so there are currently two CA certificates (ESTEID-SK and ESTEID-SK 2007) in use, both certified by root certificate of SK (JUUR-SK). In certificates the PIC 89 is used as the subject serial number. Finland National ID card 4 certificates in total: two CA certificates (The VRK RootCA and VRK CA certificate) and two user certificates (authentication and non-repudiation). certificates are protected by different PIN codes. France The French government has set up a CA hierarchy with a general accreditation body (the COFRAC Comité français d accréditation). Statement has been made that certificate carrier will be changed from smart cards to another more flexible media (e.g. USB-tokens) This body accredits certifications authorities which qualifies trust service providers, according to the requirements stated in the PRIS. Usually sector specific settings. Three levels of trust in use Middle, Strong and Strengthened. Germany Public Electronic Health Card (egk), Electronic ID card (epa), Both OCSP validation service and CRL publishing. Use or the CRL is not encouraged as it is published only once every 12 hours. Certificate Revocation Lists (CRLs) are used Sector specific. No available specifications Greece Public / Private In the case of the Syzefxis PKI system, this is managed by the contractors, i.e. the ADACOM, OTENET/OTE consortium. Internet X.509 Public Key Infrastructure Certificate and CRL Profile, April 2002 (RFC 3280). 89 The Personal Identification Code (PIC) is a unique number assigned to every Estonian citizen and resident. Page 178 of 228

Greece Public The implementation of the PKI of the HERMES project is under development. The security infrastructure uses VeriSign VSP 3.9 PKI platform together with Intercede MyID CMS and ncipher Timestamping devices. The issued digital certificates will be either software certificates or certificates generated and stored in Secure Signature Creation Devices (smart cards and USB tokens) Iceland eids on bank cards Islandsrot PKI architecture is a single CA Model/Hierarchical. Islandsrot is currently not linked to other PKI infrastructures through an existing Bridge-CA network. Italy Latvia National ID card and National Service card There are two standard x509 client certificates on the bank cards, one for Authentication (standard SSL/TLS), and one for Non-Repudiation-Signatures (Qualified signature certificate). The certificates (and the corresponding private keys) are stored on smart-cards (ISO-7816 PKCS#15). The authentication digital certificate, whose common name does not directly contain (at least in the CIE and CNS cases) the name of the holder. Instead it contains the SHA-1 hash of the file Dati Personali (personal data). The trusted certification The smart card holding a service providers (VAS certificate for qualified signatures Latvijas Pasts) 90 used for creation of electronic signatures and an unqualified authentication certificate used for authentication and stamping of electronic documents with timestamps. Lichtenstein The e-id card The e-id card is based on PKI technology, and incorporates two certificates: one for encryption, and one for electronic signatures, with only the latter being considered as qualified. No available specifications Validation is done through standardcrl/ocsp lookup. No available specifications. All methods are used: CRL & Delta CRL, & OCSP. No information 90 Similar type of specification will be used with National eid card. Page 179 of 228

Currently not used, under development. Lithuania UAB Skaitmeninio sertifikavimo centras 91 ( SSC ) and Bite Lietuva Usually the digital certificate contains the following data: public key of the holder, name of the holder, the term of validity of the public key, the name of the certification services provider, serial number of the certificate, digital signature of the organisation issuing the certificate. Luxembourg The Luxtrust CA Smart card holding two certificates together with their respective private keys. One is exclusively used for authentication and the second exclusively for signature. Other functions of LuxTrust include: Signing Server Certificate, SSL and Object Signing Certificates, Trusted Time Stamp and Tailor Made LuxTrust Solutions. Malta The Government CA Certificates are intended solely for client authentication to electronic services offered through the portal of the Government of Malta. While these certificates are technically capable of use for other Advanced Electronic Signature (or digital signature) purposes, such use is entirely at the subscriber s risk. Norway Buypass AS Buypass is the Certification Authority (CA) for Buypass Class 3 Certificates. Buypass Class 3 Certificates may be used to verify the identity of a person, for encryption of data and for electronic signatures. Buypass Class 3 Certificates must not be used to sign software, certificates or revocation lists. All BankID certificates shall BankID contain a unique object identifier (OID) that points to a specific certificate policy. Real time verification of the status of certificates via OCSP responder X.509 Certificates Revocation Lists (CRL). Not Specified The Government CA publishes CRLs at regular intervals. Both Certificate Revocation Lists (CRLs) and the Online Certificate Status Protocol (OCSP) can be used. There is a procedure for the use of on-line control fo revocation (OCSP) where 91 www.ssc.lt Page 180 of 228

Certificates under this policy can be used between private persons and service providers for authentication and digital signature. The certificates can only be used towards BankID service providers Portugal The e-id Citizen CA 92 Uses two different CA when creating certificates. Slovak egovernment PKI system - Planned Slovenia Slovenia Halcom CA and Posta CA CSP at the Ministry of Public Administration (CSP: SIGOV-CA and SIGEN-CA) Signature CA (only issues qualified signature certificates) Authentication CA (only issues authentication certificates). The authentication mechanism will be based on PKI and the private key will be included on the smart card Halcom CA: A standard certificate has single key pair and is mostly used in web browsers; it can be used for creating digital signatures and encrypting data.an advanced certificate consists of two key pairs: one for digital signing and the other for encrypting data. Mobile certificate consists of two key pairs: one for digital signing and the other for authentication. Posta CA: A standard certificate has single key pair and is mostly used in web browsers; it can be used for creating digital signatures and encrypting data. An advanced certificate consists of two key pairs: one for digital signing and the other for encrypting data. SIGOV-CA issues digital certificates to public servants. On the other hand SIGEN-CA issues certificates to natural and legal persons. CA issues following types of responses are received from a trusted validation authority. Both Certificate Revocation Lists (CRLs) and the Online Certificate Status Protocol (OCSP) can be used. Not specified The CA uses CRLs as a certificate validation system and publishes them on-line. The CA uses CRLs as a certificate validation system and publishes them on-line. 92 The Portuguese State has set up a CA hierarchy with the Portuguese Root CA (ECEE) at the top. The ECEE certifies the private keys of the CAs in the government domain including the e-id Citizen CA. Page 181 of 228

certificates: -web certificate has single key pair and is mostly used in web browser. -advanced certificate consists of two key pairs: one for digital signing and the other for encrypting data. Slovenia AC NLB This CSP issues only one type of certificates web certificates. They have a single key pair and are mostly used in web browsers. The intended usage of these certificates is to enable e-banking for the users. Spain National eid card The PKI architecture used in Spain is a hierarchic model 93 wherein there are two types of certification authorities: The AC Raiz (AC Root) only issues certificates for itself and its AC Subordinates. The AC Subordinada or certification authority subordinated to the AC Root. Its function is the issuance of certificates for holders of electronic certificates. Two types of certificates (digital signature and authentication certificates issued by CAs subordinated from the CA root). Sweden Swedish eid Swedish eids exist both as smart cards and as files stored on the hard disk; some issuers offer both options. As mentioned earlier, the latest public procurement process in 2008 led to the following suppliers of eid services: The framework agreements are valid until June 2011. Nordea Bank, Bank ID (several banks) and Telia Sonera. The CA uses CRLs as a certificate validation system and publishes them on-line. The standard for the publication of certificates is Online Certificate Status Protocol (OCSP) and as a method for revocation, the lists of revocation of certificates (CRL) are used. The Online Certificate Status Protocol (OCSP) or the Certificate Revocation Lists (CRLs) are available. (OCSP is the main method.) 93 Details of the eid card s PKI run by the National Police Department. Other accredited CA are free to create their own non-hierarchical systems, without the existence of a country s CA root that signs all the existing PKIs in the country. Page 182 of 228

Turkey Electronic certificate service providers Qualified Certificate Service Providers need to comply with following standards: ETSI TS 101 456, CWA 14167-1, ETSI TS 101 862, ITU-T Rec. X.509 V.3, ETSI TS 102 176-1, IETF RFC 3647, CWA 14167-1, ETSI TS 101 456 and ISO/IEC 17799. Devices and device verification needs to comply with: CWA 14169 or assured to EAL4+ in accordance to ISO/IEC 15408 (- 1,-2,-3) and CWA 14171 (verification device). Each certificate service provider has their own policies. Based on the PKI information table, the following global conclusions can be drawn: Out of 32 countries, 26 have reported some details of their PKI systems (19 in previous study) o o o 12 of these countries are using both CRL and OCSP methods (same as in previous study). 5 of these countries are only relying to CRL (2 in previous study) 9 of these countries have not specified the method used. Usually this is because PKI is privately operated and these decisions are made by the commercial company (7 in previous study). 4.7.2.3 Username / Password systems This section focuses on the password based authentication systems. These are either private or public by nature. Specifically, the overview reports: Name of the country. The Description section provides the information about who is providing these services and what type of services. The User group provides detailed information about to whom these services are for. The Details/Authentication section provides more information about solution and authentication it self. Page 183 of 228

Country Description Users group Details/Authentication usage Croatia 94 egovernment, ehealth, ejustice and eeducation services Cyprus Inland Revenue & Value Added Tax Citizens of the Croatia and the registered users of the systems Taxpayers who are natural persons There is no commonly agreed authentication method in Croatia. Each system maintains own identity management scheme. Currently password based authentications are used. A registered user can access his/her personal data electronically by presenting password and PIN number Cyprus Czech Theseas Customs, Excise System name/password/advanced electronic signature system Registered users of the system (usually traders) Specified application users. Czech A social security number The Ministry of Justice (only they have an access to social security number database) It is designed for the traders to connect to the system via the Internet for the electronic submission of cargo and import declarations. Furthermore, the system is also designed for the electronic payment of customs duties through the banks. This system is used in communication with The Czech Social Security Administration, Ministry of Agriculture etc. The name is connected with a qualified certificate (serial number) used to sign data that the user sends to the system. Compares personal IDs and social security numbers 94 All egovernment applications/systems are also accessible to qualified certificates holders, who are identified to public administration bodies. But because there is no method to create eid certificates to the citizens these systems are listed in this table. Page 184 of 228

Czech Personal identity number (or other data sufficient to uniquely identify person) Specified application users. Estonia Bank ID 95 Several commercial applications where users can log-on using their Bank ID logon. Germany the Hamburg Gateway Hamburg Gateway is a one-stop access point to these services and offers a central authentication for registered citizens. Hungary The Client Gate Specified egoverment application users. Ireland The Public Service Broker All users of public services This is used in customs declaration applications and in usual communication with public administration. The identification is made only through the connection of data from a qualified certificate and the personal identity number in the signed form. The authentication is done through specified bank authentication. Mostly using passwordlist or password-device. The lower security level one can be achieved by online registration with user name and password. Security level two requires registration in person at any of the decentralized customer centers, based on the presentation of the personal identity card. The user provides his or her user name and password in the login process, and the Client Gate sends to the application the name, the e-mail address, a qualifier related to the credentials and roles of the user, and a transaction code (artifact) from the registration register of the System of Central Electronic Services. Uses two distinct parts. First one is a user interface. This website is built to provide a single point of contact between individuals and 95 Banks will cease providing authentication services to 3 rd parties, this will lead to expanded usage of ID-Card. Page 185 of 228

Lithuania Luxembourg Application specific usage of Usernames and passwords (in ebanking also code genarators). Many applications such as e.g. etva Malta There several different e- services offered by the Government Application-based offered by various departments and authorities The DigiD supported egovernment services Users of specific application. E.g. etva application allows a user to submit VAT tax declarations. Several services on national level: Inland Revenue Department, VAT Department, Malta Environment and Planning Authority, Malta Transport Authority and Malta Financial Services Authority. Several different services (e.g. Tax government agencies. Authentication is done using password and username created during registration. Second part is Inter- Agency Messaging Service (IAMS). It s used to share information using standardised XML envelopes Some applications assign user name upon filling in basic personal information (name, surname, personal code) online. In other cases username and password are sent by e-mail upon conclusion of agreement on data supply via electronic means with the egovernment service provider state institution. In some of application users can choose their own username and password. A simple username/password system 96 for electronic authentication, based on prior authorisation after a (handwritten) application form is submitted by the user. A simple username/password system for electronic authentication. Registered DigiD users get username and 96 etva is changing to be used only with Luxtrust certificate. Page 186 of 228

Netherlands services, student services) supporting DigiD based authentication. Portugal Tax - Declarações Electrónicas (E- Declarations) Portugal Customs the NCTSnetwork (New Computerised Transit System) Portugal Portugal The Direct Social Security (Segurança Social Directa) Citizen s Portal (Portal do Cidadão) E-Declarations platform is a web platform that enables the communication of citizens and companies with the Portuguese Tax Department (Direcção-Geral dos Impostos). The system whereby all declarations are sent electronically using EDI-based messages (by EDI- FACT or XML), by accessing the website and uploading the communication has been implemented. A web page through which citizens and companies can communicate with the Social Security. Is a web platform developed by UMIC that mainly centralises information to be provided to citizens about all matter of Public password, in some cases SMS messages are used to achieve medium security level. User uses password (granted by the DGITA) to access the service. Passwords are stored in a DGITA database using a one way password scheme. Communications use the SSL protocol. The website system does not use advanced electronic signatures, the user is merely provided with a log in identification and a password. Technically similar to Tax system. The citizen access to the system is done using password, User receives a letter containing a password (the user must change this password when accessing the program for the first time). The site uses Safe Transactions SSL 128 Bits, with a web-server certificate. The online social security site includes a high grade (RC4 128 bit, SA 1024 bit) Verisign SSL Web server certificate. After registering and after having inscribed the respective data, the system send the user by an email containing a link that the user must access in order to get the registration. Page 187 of 228

Administration. Logging on to the system thereafter uses a username/password system. Slovakia The Central Portal of Public Administration. Spain egoverment services that can be accessed by username and password Access to public services. (e.g. etendering application) The National Cadastre and Land Records Service or at the Virtual Office of the Tax Agency, among others. Authentication through the username and password The user can choose to use password/username or certificate to authenticate. 4.7.2.4 Mixed / Ad hoc systems This section focuses on the Mixed and Ad hoc based authentication systems. These are either private or public by nature. Specifically, the overview reports: Name of the country. The Description section provides the information about who is providing these services and what type of services. The Details section provides information about the nature of the services used with this type of authentication. The Authentication method section provides more information about used authentication method. Country Description Users group Details Authentication method Austria Several applications that support the citizen card (together with other methods): Tax declarations online (FinanzOnline), Several Internet banking solutions and Social security (statement of social security terms, application premature retirement, ) for Citizen card or others (e.g. userid/pw) Page 188 of 228

Cyprus The Government portal and The Government Secure Gateway Through the Portal the visitor can visit Governmental and non Governmental Web Sites that offer various informative and interactive services. The Government Secure Gateway will provide the core architecture for enabling egovernment service delivery and Government to Government (G2G), Government to Business (G2B) and Government to Citizen (G2C) transactions online in a secure interoperable manner. and The Government portal is an institutional website and an entry point to public information and services. Both portal and gateway are still under development (not in use). The portal is accessible by anyone; however, certain eservices use the security method of user ID and password. Finland KATSO authentication KATSO system is an identity management, authorization and authentication platform for organizations. It enables businesses to file and interact with the Board of Tax, it acts as the identity provider, and provides a standard interface to a range of e- services KATSO credentials and paper tokens for registered users Oasis SAML 2.0 and Liberty ID-WSF 2.0 standards Finland VeTuMa authentication www.suomi.fi at The VETUMA system is a citizen identification and payment service. Users can identify themselves to the online services of public administration and make payments to the authorities. Depending on the online service, users can be identified with TUPAS bank identifiers, a FINEID certificate card or a simple username and password. Page 189 of 228

France Federated identity portal The user connects to the public administrations where he has a specific identity. Same identity can then be federated to other services. Currently the option being experimented is to manage the federation of identities through a unique portal, https://mon.servicepublic.fr/portail/ The procedure implemented is thus specific to this project 97. The user first has to create an account on https://mon.servicepublic.fr/portail/ (MSP). When doing so, he defines the authentication means he wants to use to access his personal account. Different levels can be defined. Belgium Federal paper token applications The federal paper token is only used in public sector applications, in particular: the TaxOnWeb application and a variety of applications using the iloket framework. The federal paper token is expected to be phased out it the next few years in favour of the national eid card A small paper card with 24 personal codes. Authentication is twofactor authentication: the user enters his chosen username and password, and the system prompts him for one of the 24 personal codes on the token. Iceland egovernment services Some services like: Income Tax Declaration, University of Iceland and Local Governmental service portals (my pages). egovernment services In most of the services user can choose to use password/username or certificate to authenticate. Italy The tax authorities ( Agenzia delle Entrate ) 98 Tax portal to citizens The user can: Send or cancel an income declaration; Send VAT declarations and other forms in the field of VAT; The validation scheme of this application is based on a dual approach: (i) username/password and (ii) EIC or NSC Pay taxes and ask for the refund of taxes unduly paid; 97 Description of the federation procedure is extracted from ADAE, Architectural vision Liberty Alliance version 1.0, September 2004, p36-38. 98 Can be accessed through the following URL: http://www.agenziaentrate.it/ilwwcm/connect/nsi/. Page 190 of 228

Register contracts for the renting of immovable properties; Send other declarations in the area of taxation and/or social security. Norway Altinn Altinn is a common internet portal for public reporting. Altinn is a tax reporting system, where user must have a Norwegian personal identification number and a PIN-code to access. smartcard from Buypass (Assurance level 4) PIN codes for MyID (letter from the Tax Administration) (Assurance level 3) PIN-codes from tax return documents (letter from Tax Administration) (Assurance level 2) One-off codes from a letter ordered on All-in (Assurance level 2) Using a registered password, together with a one-off code by SMS (Assurance level 2) Only a password (Assurance level 1) The Educational Fund State Loan Has two different authentication solutions. One for logging-on to Your Pages (No.. Dine sider ) and one for signing. Students use The State Educational Loan Fund to manage their loan information A student can log-on to his/her Your Pages with MyID to the State Educational Loan Fund. The signing procedure is done through the All-in portal with the use of the highest assurance level (level 4), i.e. the Buypass solution. My Page MyPage is an online one-stop public service centre that allows users to use online public services. Different type of egovernment services. (registration, message and calendar services) This type of services requires the use of MyID. Additionally: Registration uses: SOAPmessages, XML-data, XSL, WSDL and WS-I Basic PROFILE. Page 191 of 228

Message uses: SMTP, plain-text or structured (XML), STARTTLS and LDAP-S Slovakia The etax services (electronic tax returns) for individuals and the etax and evat services for businesses. Private citizens and businesses. Taxation services To access these services, a user needs either a qualified certificate from an accredited CSP or a password. Slovenia egovernment services that can be accessed by username and password or by certificate (e.g. State portal e- Uprava, e-sju portal) egovernment services users. Citizens and noncitizens living in Slovenia. The portal e- Uprava supports Government to Citizen (G2C), Government to Business (G2B) and Government to Government (G2G) interactions and offers various services to citizens, legal persons and public employees. The portal e-sju offers a single access point for all forms that can be published on the web by any public administration institution. 99 Authentication of users is usually based on qualified digital certificates issued by CSPs registered in Slovenia but authentication based on username/password is also supported for conducting services of lower sensibility, e.g. for the submission of forms that do not need digital signature. Spain egoverment services that can be accessed by username and password or by certificate Citizens can use the National Cadastre and Land Records Service or at the Virtual Office of the Tax Agency, among others. Logging-on to the system thereafter, allow to registered users to get access to several virtual office services. The user can choose to use password/username or certificate to authenticate. 99 Currently, the system includes the description of over 400 different services and 350 forms. Page 192 of 228

Turkey VEDOP The citizens of Turkey The citizens will be able to file their tax returns electronically with e-tax Return application feature of VEDOP. E-Tax Return application is implemented by means of encrypted data transfer, digital signature and Public Key Infrastructure (PKI) providing secure access through Internet. Nevertheless, what is explained here, is the use of PKI for secure communication, for authentication a username and password is used. Based on the national infrastructure tables, the following global conclusions can be drawn: Out of 32 countries, 20 are using PKI based egovernment applications (16 in previous study) Out of 32 countries, 14 are using username/password based egovernment applications (13 in previous study). o 10 of these countries are also using PKI based egovernment applications (5 in previous study). Out of 32 countries, 12 are using mixed (ad hoc) based egovernment applications (7 in previous study). o 9 of these systems have certificate support (6 in previous study) Out of 32 countries, only 3 have no electronic egovernment applications or information was not available (7 in previous study) Based on the above numbers several conclusions can be formulated. Specifically: The national infrastructure table s show high number in PKI based egovernment applications. 25 (78%) of the 32 surveyed countries have implemented some level of certificate based authentications to their egovernment services. More importantly, the tables shows that the countries are advancing towards electronic egovernment services, while only 3 of the surveyed countries has currently no electronic services. It should be noted that the development of the surveyed countries national infrastructures is progressing quickly and because of this fact some of the information gathered from the correspondences could be already old. As noted above, the volumes of the certificate usage has been growing since previous study. When analyzing the usage of certificates in egovernment applications we can see that the usage of certificates has grown from 68% of countries up to current situation 78% of countries. Based on the 32 surveyed countries reports also conclusions about their future development can be drawn. Basically the form of service authentication can currently be divided to the two main categories; Client to Service, in which user accesses the service through home application (e.g. browser) and Client to gateway (e.g. proxies and portals), in which several egovernment services can be accesses through a gateway service. Page 193 of 228

4.7.3 International interoperability approaches This section of the report will describe the international interoperability approaches that are used by each of the surveyed countries. It provides information about to who these solutions are built and how it is done. The purpose of this section is to clarify all electronic identities created for non-nationals of the surveyed countries and to clarify witch type of foreign electronic identities are accepted (if any). 4.7.3.1 National credentials issued to non-nationals In this section all different electronic identification devices available for foreign citizens are listed. Most of these countries do deploy non-technical social numbers e.g. to foreigners staying in country, but only solutions using technologies are listed here. Specifically, the overview reports: Name of the country. The Description section provides the name and the nature of the system. The Issuance section explains in which conditions National credentials are issued to nonnationals. The Status/Details section provides status and more accurate information about usage of the system. Page 194 of 228

Country Description Issuance Status / Details Austria Austria National ID card (public / private) A health insurance card Issued when the entity is usually registered in the Central Register of Resident. An Austrian eid card can be activated. If the entity is not registered centrally, then private sector A- Trust can be used. Registered entities subject to Austrian social security Belgium National ID card Non-nationals who are not eligible for a national eid card Belgium SIS card (social insurance card) Bulgaria UES and unique identifier Natural persons subject to Belgian social security Non-national possessing UES or unique identifier Croatia N.A. N.A. N.A. Deployed, technical details are the same for non-nationals as they are to Austrian nationals Deployed. A health insurance card can then be activated as a citizen card. New health insurance card supporting 256 Bit ECDSA will be rolled out beginning 2010 (A-Trust). Belgian eid cards are unavailable to most non-nationals, and for this reason the Belgian government is presently working on introducing a series of so-called foreigner s eid cards to replace the existing paper foreigner s cards. Eight different types of electronic foreigner s cards are currently being deployed, depending on the status of the foreigner 100. These cards also contain two certificates (one for authentication, and one for qualified electronic signatures) and are technically and functionally largely identical to the Belgian eid card. Deployed, each non-national subject to social security will receive SIS card. Usage similar as with Belgian citizens Deployed Use of most of the egovernance services by foreign citizens may prove possible only if they posses UES issued by registered CSP. Most of the services may be also accessible only if the foreign citizen has obtained a unique identifier under Bulgarian law 100 See http://www.dofi.fgov.be/nl/elek%20vreemdelingenkaarten/faq%20en.pdf for an overview Page 195 of 228

Cyprus N.A. N.A. N.A. Czech A personal identity number Non-Technical, but can be stored in certificate. Denmark OCES Certificate A foreigner with permanent residence in Denmark will be issued with a CPR number (national registration number) and can therefore have an OCES signature. Denmark The social security card (Sygesikringsbevis) Issued to Danish nationals and permanent residents. Estonia National ID card Issued to all aliens residing permanently in Estonia on the basis of a valid residence permit or right of residence irrespective of their age. Finland National ID card Issued to Finnish nationals and permanent residents. Deployed. Deployed. Only for health purposes, non eidcard Deployed, technical details are the same for non-nationals as they are to Estonian nationals Deployed, technical details are the same for non-nationals as they are to Finnish nationals Finland Social Security Number (SSN) and KELA card Finland The Finnish Banker s Association paper token framework (TUPAS). France National ID card and Vitale card Germany No available specifications All Finnish citizens and non-nationals mandated to reside in Finland Can be issued to resident non-nationals as well All French citizens and non-nationals mandated to reside in France No available specifications Greece National ID card Issued to all Greek citizen over 12 years of age, living permanently or temporarily in Greece. Non-nationals are provided with a permit of stay from the administrative region of Deployed. The electronic KELAcard is in fact the same national eid card, but enhanced with a code bar signalling the user s insurance reference number. Deployed, technical details are the same for non-nationals as they are to Finnish nationals. Deployed. Currently ID card is paper based, but future plans include electronic eid card. No available specifications Deployed. Currently ID card is paper based, but future plans include electronic eid card. Page 196 of 228

their domicile. Hungary N.A. N.A. N.A. Iceland N.A. N.A. N.A. Ireland N.A. N.A. N.A. Italy Electronic Residence Permit (Permesso di Soggiorno Elettronico) Non EU Residents in Italy Latvia The ebanking The ebanking authentication means are available for nonresidents who have opened accounts with the appropriate banks, and personal certificates may also be issued to nonresidents. Lichtenstein N.A. N.A. N.A. Lithuania The ebanking authentication All foreigners can open an account to Lithuanian bank and use these credentials to access egovernment services. Luxembourg N.A. N.A. N.A. Malta N.A. N.A. N.A. The Netherlands N.A. N.A. N.A. Norway N.A. N.A. N.A. Poland N.A. N.A. N.A. Portugal N.A. 102 N.A. N.A. Romania N.A. N.A. N.A. Slovakia N.A. N.A. N.A. Slovenia Ministry of Public Administration SIGOV-CA Non-nationals and foreign entities can obtain digital certificates from all CSP's in Slovenia if they are registered in the country or they exercise certain rights Passive & Active authentication, Police (visual) Identification, Biometry (face & finger). Specifications similar with Electronic ID Card for citizens. Deployed, non-resident using ebanking authentication means can access egovernment applications and its services. Deployed. 101 A certificate stored to smartcard can be used to authenticate to egovernment services. 101 A Future planned eid card should also be issued to foreigners according to the feasibility study on eid cards. 102 As stated in the introduction above, the Portuguese eid card and e-passport are only available and issued to a limited number of permanent residents (in the case of e-card, only in Azores). Page 197 of 228

or duties in Slovenia (e.g. they can obtain digital certificates from SIGOVCA if they are employed in a public institution). Spain The NIE card (Número de Identificación de Extranjeros) 103 Attests to the legal residence of foreigners in Spain, their identity and that they have been granted the corresponding authorization or the recognized right to stay in Spanish territory for more than three months. Sweden eid soft and hard Persons either living in Sweden (including nonnationals) or Swedish nationals can obtain any type of eid. In addition, some solutions require the user to have a bank account from one of the providers of an eid. Turkey N.A. N.A. N.A. All foreign holders of a NIE can obtain a Spanish qualified certificate as authentication means in order to make on-line transactions with the Spanish. Electronic certificates have the same legal validity and technical characteristic as the ones issued to Spanish nationals by any of the Certification Service Providers authorized by the Ministry of Industry, Tourism and Commerce. Deployed The United Kingdom N.A. N.A. N.A. 4.7.3.2 Non-national credentials accepted This section will describe all foreign electronic identities accepted by the surveyed countries. The purpose of this section is to clarify all existing interoperability efforts done by surveyed countries by them self. Specifically, the overview reports: Name of the country. The Description section provides the information and name of the system. The Involved countries section provides information of participating countries. 103 During the next year and according to the Police Department Plans, the eid card will start to be issued to foreigners who reside in the country and therefore are in possession of a NIE card (Número the Identificación de Extranjeros). Page 198 of 228

The Details section provides more accurate information how this interoperability system has been established. Country Description Involved countries Austria A non-national may use his home-country s eid. Not specified (Previously only following countries Belgium, Estonia, Finland, and Italy). Bulgaria N.A. N.A. N.A. Croatia N.A. N.A. N.A. Cyprus N.A. N.A. N.A. Czech N.A. N.A. N.A. Denmark N.A. N.A. N.A. Estonia Smaller scale pilots to accept foreign eids. Portuguese, Finland, Sweden, Lithuanian and Belgium Details The integration into the Austrian eid middleware citizen card environment. The authentication process is based on an identity link signed by the sourcepin Register Authority and on qualified signatures. A technical difference is that the identity link usually cannot be stored in the foreign eidm token, but is created on the fly during the authentication process based on the foreign unique identifier. New development of eid interoperability is based on STORK 104 project. Foreign eid-s in Internet banking applications. This interest is limited to neighbouring countries (Finland, Sweden). The esignature compatibility with Belgium and Finnish ID-cards has been successfully demonstrated. In the case of Finland, an MoU was concluded to govern the equivalence between existing eid solutions. Company Registration Portal of the Commercial Register accepts users with Portuguese, Belgian and Finnish ID-card and Lithuanian Mobile-ID in order to set up a company and manage it on-line 105. 104 The cross-border interoperability, in particular where eids are not based on qualified signatures, are elaborated in the EU Large Scale Pilot STORK. 105 See http://www.rik.ee/38928 Page 199 of 228

Finland The mutual acceptance of the FINEID with Estonian eids and Austrian eids France Netcards project, STORK and SEMIC EU project. Estonia Austria and Netcards includes partners from: Austria, Czech Republic, Finland, France, Germany, Greece, Hungary, Italy, Lichtenstein, Norway, Netherlands, Romania, Slovakia, Slovenia, Poland and subcontractors and/or supporters in many of the participating countries. Support for qualified certificates issued by other countries is further considered. Partner in EU Large Scale Pilot STORK. There have been noteworthy advances in the mutual acceptance of the FINEID with Estonian eids and Austrian eids. Interoperability initiatives have been taken within the Porvoo Group. In the health sector, the GIE SESAME-VITALE is taking an active part in the European project Netcards which works on a future European card for health insurance. This project aims at allowing Europeans to use their health card in any European country. Partner in EU Large Scale Pilot STORK. The DGME is also taking an active part in the SEMIC EU project, a participatory platform and a service by the European Commission that supports the sharing of assets of interoperability to be used in public administration and egovernment. Germany No current existing projects, but intention is to comply pan- European standards. Also STORK All STORK project partners Greece N.A. N.A. N.A. Hungary N.A. N.A. N.A. Iceland Future interoperability through STORK project All STORK project partners Technical specifications will be in line with CEN and ISO standards and that they aim for pan-european interoperability on the application layer as well. Partner in EU Large Scale Pilot STORK. Iceland is participating in the STORK project that is working on eid interoperability within European countries so usage of foreign eids in egovernment applications in Iceland could be possible in the near future. Page 200 of 228

Ireland N.A. N.A. N.A. Italy 106 Small test with Austrian eid scheme. Future interoperability through STORK project Austria. All STORK project partners Latvia N.A. N.A. N.A. Some interoperability tests have been conducted also with the Austrian eidm system, but the results were mainly due to the flexibility of the Austrian system. Partner in EU Large Scale Pilot STORK. Lichtenstein Not specified Not specified Relying to the European EIF-model it enables an interoperable e- Government infrastructure, providing public services to the European citizens. Lithuania National eid card N.A. The eid card complies with the ECC standard [51-55]. Luxembourg Luxembourg is actively participating in the STORK All STORK project partners Malta N.A. N.A. N.A. The Netherlands Partner in Stork project All STORK project partners Norway N.A. N.A. N.A. Poland N.A. N.A. N.A. Portugal Partner in Stork project All STORK project partners Romania N.A. N.A. N.A. Slovakia N.A. N.A. N.A. Slovenia No direct trust relations between other countries 107 Partner in Stork project All STORK project partners Partner in EU Large Scale Pilot STORK. The Netherlands participates in the STORK-consortium investigating and testing solutions for interoperable eid s. The Services Directive also stimulates the interoperability of electronic qualified signatures. The Portuguese Government and a Portuguese Company (Multicert) are members of the STORK (Security Identity Across Borders Linked) project, towards pan- European recognition of electronic IDs. Within the STORK project several test pilots will be set up. Slovenia as a member of the STORK project is actively involved in two pilots: e- delivery and change of address. 106 Italy is also attendant in Netcards project. Page 201 of 228

Spain Sweden Partner in Stork project Foreign eids Partner in Stork project All STORK project partners Some cases. specific All STORK project partners Turkey N.A. N.A. N.A. The United Kingdom Partner in Stork project All STORK project partners Proyecto Stork (Stork Project): Spain participates in this project of acceptance of eid and similar identifiers in egovernment services of other European Administrations. Commercial services, however, such as the e-procurement platform offered by ChamberSign, support to some extent foreign certificates or eids, mainly due to the fact that the verification of ChamberSign relies on the existing eid issued to a certain person, i.e. identification is guaranteed by the national eid provider. Partner in EU Large Scale Pilot STORK. Partner in EU Large Scale Pilot STORK. Based on the national infrastructure tables, the following global conclusions can be drawn: Out of 32 countries, 15 are issuing national electronic credentials to non-nationals (12 in previous study) o o 12 of these countries are creating certificates to non-nationals (9 in previous study) 1 is planning to start issue certificates to non-nationals. Out of 32 countries, 17 are not issuing any form of electronic credentials to non-nationals (20 in previous study). Out of 32 countries, 7 countries are accepting non-national credentials (6 in previous study). o These interoperability systems have been small pilots with few participating countries. Out of 32 countries, 25 are not accepting any form of non-national credential in egovernment systems (26 in previous study). Out 32 countries, 14 have reported the participation in STORK-consortium investigating and testing solutions for interoperable eid s. Based on the above numbers following conclusions can be formulated: There is no commonly agreed method for handling the citizens from another country. Only 15 out of 32 (47%) countries are creating some type of electronic credentials to non-nationals. The main change since the previous study is the STORK project, which aims to build common method for cross border communication between European countries. 107 Current situation in Slovenia, but there is no legislative barriers to use other qualified certificates if trust relations are built. Page 202 of 228

4.7.4 Adopted industrial standards In the previous sections above we have described what kind of egovernment applications are used in the surveyed countries. Those sections mostly focused to explain and differentiate egovernment applications and methods used to authenticate to those applications. In this section we will focus only to the applications that are using any of the identity management industrial standards. This section of the report will describe which types of identity management standards are commonly used and approved in each of the surveyed countries. The purpose of this section is to clarify all nationally selected eid standards (if any). When standards have been selected this section also provides information about usage of the standard. Correspondences were asked what type of tokens and eidm profiles are selected in the surveyed countries. The following table will present focus on the countries, which have made a selection around industrial standards. Specifically, the overview reports: Name of the country. The Description section provides the names of the selected standards The Details/Authentication usage section provides more accurate information about usage of the selected standards. Country Description Details/Authentication usage Austria SAML, HTTP, XMLDsig (XAdES BES) Belgium VCARD, SAML and WS-Federation (Kerberos) Bulgaria Does not subscribe any of the electronic document delivery SAML is used for the identity link and during the identification and authentication process via MOA-ID. Interoperability is provided by take-up of widely used standards. SAML1.0/1.1 is used for the identity link and during the identification and authentication process via MOA-ID. Access to the middleware is provided using HTTP. The electronic signatures follow XMLDsig (XAdES BES) N.A. For the purposes of the egovernance will be implemented a standard Citizen view Citizen is identified to the egovernment system with Identity Link. The Identity-Link is created as a SAML- Assertion. N.A. Not specified Page 203 of 228

standards. laid down by the new egovernance legal framework which is similar to OSCI. Croatia N.A. N.A. N.A. Cyprus N.A. N.A. N.A. Czech N.A. N.A. N.A. Denmark SAML2 SAML2 is used in authentication and attribute queries. Estonia N.A. N.A. N.A. Finland SAML2, Liberty and WS-Federation (Kerberos) No documented usage of WS-Federation. The Katso authentication service uses SAML2 and Liberty ID-WSF 2.0 standards in user authentication and attributes queries. France Liberty Alliance The Government advocates the use of federated identities and the standard set up by the Liberty Alliance in order to avoid the use of a single unique identifier. Germany No information available Greece Standard XML schemas, Public Key Infrastructure (PKI) and the XML Signature Specification 108 (XMLDSig, XML-DSig, XML-Sig The DGME (the State Modernisation General Directorate) is a formal partner of the Liberty Alliance. No information available Generally standards adopted A central login-service for the citizens of Denmark. User will be able to access several egovernment services with single logon (SSO). A central login-service for the citizens of Finland. User will be able to access several egovernment services with single logon (SSO). (First implemented on tax-services) A central portal service provides login-service for every French citizen to access different services through an identity federation system No information available No information available Hungary No adopted framework No adopted framework yet No adopted framework yet 108 XML-Signature Syntax and Processing (www.w3.org/tr/xmldsig-core/) Page 204 of 228

yet Iceland SAML 109 A few backend Governmental systems make use of SAML for Single-Sign-On procedures. Ireland XML, HTML,J2EE and The Inter-Agency Microsoft Biztalk. 110 Messaging Service (IAMS) is built to share information between agencies. Italy SAML 2.0 From the technical point of view, the reference for the federated identity management, based on EIC/NSC and other tokens, and for the management/validation of the attributes/roles is the framework SAML 2.0 with some personalisation Latvia N.A. N.A. N.A. Lichtenstein N.A. N.A. N.A. Lithuania N.A. 111 N.A. N.A. Luxembourg N.A. N.A. N.A. Malta N.A. N.A. N.A. Using SAML 2.0 in their authentication projects. These services provide Single-Sign-On services for the citizens. No specific citizen aspect in the Ireland solutions yet. Currently planning and developing more citizen oriented system. Services of registry and discovery of identity providers and attribute authorities The Netherlands Norway N.A. 112 N.A. N.A. FEIDE is a shibboleth based solution MyID uses SAML 2.0 FEIDE 113 is an initiative to create a federated identity management system on a national level for the educational sector. MyID SAML (Web Browser SSO Profile, Enhanced Client or Proxy (ECP) Profile, Identity Provider Discovery Profile and Single Logout Profile.) Feide is a concept based on the principle that every user in the educational sector (pupil, student or employee) receives a user name from their school, college or university, which can be used throughout the sector. MyID provides SSO services to several 109 There is no strategy for this, but currently SAML is used in some applications. 110 No adopted framework for industrial identity management standards, but WSFED ready. 111 In esignatures Xades standard is used. 112 DigiD will introduce SAML 2.0 which has been adopted in The Netherlands as the official standard by the Forum and College Standardisation. 113 Federated Electronic Identity www.feide.no Page 205 of 228

different services. Poland N.A. N.A. N.A. Portugal N.A. N.A N.A. Romania N.A. N.A. N.A. Slovakia N.A. N.A. N.A. Slovenia N.A. N.A. N.A. Spain N.A. N.A N.A. Sweden N.A. N.A. N.A. Turkey N.A. N.A. N.A. The United N.A. N.A. N.A. Kingdom Page 206 of 228

Based on the national infrastructure tables, the following global conclusions can be drawn: Out of 32 countries, 11 (34,5%) have some level of specifications to industrial identity management standards (9 in previous study). This is lower that might have been expected, but status is changing due to the common STORK project. It should be noted that some of the correspondents might not have the most recent information available and number of the countries could be higher. Anyway when thinking about implications of such low number of approved industrial identity management standards, we can see the importance of current interoperability studies. o o o 8 of these countries are using SAML (Norway through Shibboleth and France through Liberty). 2 are specifying Liberty as one of the approved industrial standards and 2 are specifying WS-Federation as one of the approved industrial standards. 4.7.4.1 Impact of eidm applications The third examined issue was usage of the industrial identity management standards. The correspondences were asked, which of the recognised (previously studied in other reports of this project) industrial identity standards were used (if any). The received responses (as examined in section 4.7.1.1) indicated that in the area of the industrial identity management standards the surveyed countries have still lot to do. It should also be noted that because of the complexity of such system there could be some implemented and selected standards which were not reported by the correspondences. The study showed that only 11 countries out of the 32 (34.5%) had selected some of the specified standards (still the main finding is that 21 out of the 32 (65.5%) did not have any preference to industrial standards). Only standard showing a little bit popularity between the surveyed countries were SAML, the study indicated that 8 out of the 32 (25%) were preferring SAML as a protocol). Based on the survey sent to correspondence we can map 6 out of 32 (19%) to be implementing eidm applications fully based on SAML standard. Austria o o SAML is used for the identity link and during the identification and authentication process via MOA-ID. Interoperability between other countries is also considered to be implemented using SAML. Belgium o SAML accepted as a standard since 29/09/2004, no additional information about current implementation available. Denmark o o SAML2 is used in authentication and attribute queries. Currently many new egovernment solutions under development. Page 207 of 228

E.g. the Danish Citizen Portal, first version of My Page launched Q1, 2008 Finland o The Katso authentication service uses SAML2 and Liberty ID-WSF 2.0 standards in user authentication and attributes queries. Iceland o A few backend Governmental systems make use of SAML for Single-Sign-On procedures Italy o Services of registry and discovery of identity providers and attribute authorities Based on the survey sent to correspondence we can map 2 out of 32 to be implementing eidm applications based on other IDM standards, which are using SAML standard. France o France is utilizing SAML protocol through Liberty Alliance. Norway o Norway is utilizing SAML protocol through Shibboleth Other identity management standards showed even less popularity between the surveyed countries than above mentioned SAML, The study indicated that 2 out of the 32 (6%) had chosen Liberty as a identity management standards, the study also indicated that 2 out of the 32 (6%) had chosen WS- Federation to be their preferred identity management standard in egovernment applications. Countries who had selected Liberty Alliance: Finland o The Katso authentication service uses SAML2 and Liberty ID-WSF 2.0 standards in user authentication and attributes queries. France o o The FederID project provides an open source IDM solution and Identity Federation for the French National Agency of Research "Mon Service Public" portal. This portal will enable every French citizen to access different services through an identity federation system Page 208 of 228

On the back-office layer the analysis shows that there is no commonly agreed direction for industrial identity management standards. As described above, the survey shows that only few of the surveyed countries have selected any of the standards. The lack of commonly agreed tokens and eidm profiles is challenging. A common STORK and similar studies are becoming more important for European interoperability in close future. These studies should also focus to build the support bases on already existing solutions. Page 209 of 228

5 Impact Assessment 5.1 Introduction Based on the analysis under section 4 above, this section contains an impact assessment of the identified similarities and differences, with a view of identifying the potential for interoperability of eid solutions and hence of the supported egovernment applications. The main goal of this section is to identify and weigh the issues that have a negative impact on interoperability between the eidm solutions presently being used in the surveyed countries. Far from being an academic exercise, this is an essential part of the project, as this section implicitly identifies the problems to be resolved by the interoperability solutions to be investigated and proposed in the third stage of the project. In a sense, this section identifies the design criteria for an eidm interoperability mechanism: any proposed solution must be able to adequately answer all of the issues below. As an update to the 2007 edition of the study, we will also indicate which building blocks have been put in place/are being implemented that may impact each of these issues, and which questions still remain. The impact assessment below is split into two parts: issues at the legal/policy level (section 5.2.1.), and issues at the technical/infrastructural level (section 5.2.2.) 5.2 Identified interoperability issues 5.2.1 At the legal/policy level It is frequently observed that the main difficulties in creating a European interoperability framework stem from legal and socio-political considerations, rather than technical or infrastructural barriers. Such difficulties include policy preferences, social sensitivities, the role of the user in managing his or her own information, interpretations regarding the scope of privacy (or rather: regarding the balance to be struck between privacy and user friendliness), and legal-technical difficulties regarding the competence to regulate any of these fields. This section aims at providing a comprehensive overview of all of these legal/policy issues, as identified through the analysis in section 4 above. 5.2.1.1 Lack of a legal framework on the requirements and effects of electronic authentication One of the questions brought before the national correspondents in the questionnaire was to identify any general legal framework with regard to identification/authentication of users, either in an on-line or offline context, or with regard to identity itself. The purpose was to see if any surveyed country had considered this issue to the point where clear and hard rules were defined. As was somewhat expected, the answer was almost universally negative (see section 4.5.1.), with Austria being the sole exception, and Finnish legislation being under preparation at the time of the data Page 210 of 228

collection; the Finnish act on electronic authentication has since been adopted 114. While specific regulations exist that refer to the need to identify a specific entity (such as the national transpositions of the e-signatures Directive) or that prescribe which documents and registers are kept to identify specific entities (such as laws with regard to identity cards, national numbers, national registers etc.), the concepts of identity, identification and authentication as defined for the purposes of this study have remained unregulated in almost all countries. This is both true for offline authentication (i.e. how a person should identify him/herself physically) and for on-line authentication. In both cases, administrations take a very pragmatic approach, in which they adopt a solution that is suitable for their needs. From a practical perspective, suitable in this context means that the authentication mechanism offers: - Access to the required identity attributes, either directly (e.g. by presenting a series of attributes on a certificate) or indirectly (e.g. by being able to link a username/password to a series of attributes in a back-end database); - Sufficient security for the purposes of the application that the resulting identity attributes are reliable, i.e. correct and belonging to the entity attempting to authenticate itself. As shown in section 4, administrations consider widely varying solutions to be sufficiently secure, depending mainly on national policy preferences and, within the countries, on the application type. It should be noted that this almost universal lack of a legal framework applies to identification and authentication in general, but in certain contexts specific rules do exist (as is e.g. the case at the national level with respect to identity cards, as noted above). At the international level, specific rules have also been adopted with respect to travel documents, most notably via the International Civil Aviation Organization (ICAO). ICAO is an agency of the United Nations which standardizes machinereadable passports, including more recently biometric passports. In this specific context, a clear legal framework is available, including at the European level via Council Regulation (EC) 2252/2004, and Commission Decisions C(2005)409 and C(2006)2909 115. Thus, for travel documents a legal framework does exist. In addition, recent initiatives have focused on improving the interoperability between the PKI based authentication features of the epassports via the ICAO Public Key Directory (PKD), a centralized distribution point for public signing key certificates from all issuers of epassports. However, participation in the PKD is voluntary and presently still limited, counting only 15 countries 116. Finally, it should be kept in mind that these initiatives focus specifically on the travel document context, and are not targeted towards a generalized use. The lack of a general legal framework for identification and authentication is not necessarily a disadvantage. From a national perspective, it has allowed administrations to choose the solutions which they deem suitable according to the definition above. From a cross-border perspective however, it also means that a number of fundamental building blocks are missing, including notably a consensus on which types of information could be used to establish or corroborate an identity, and how the reliability of identity infrastructures could be determined. In addition it means that there is no consensus either on issues such as the acceptability and use of unique identifiers. Obviously, indirectly related regulations (specifically the Privacy Directive and the e-signature Directive s provisions with regard to certification services in general) do remain relevant and must be taken into account. 114 The Act on electronic identification to promote the provision and the use of identification services entered into force on 1 September 2009, replacing the Act on Electronic Signatures of 2003; see http://www.epractice.eu/en/news/293726. 115 See http://ec.europa.eu/justice_home/doc_centre/freetravel/documents/doc_freetravel_documents_en.htm 116 See Participant List at http://www2.icao.int/en/mrtd/downloads/pkd%20documents/pkd_board_participants_list.pdf Page 211 of 228

Impact of this issue on interoperability: The lack of a specific legal framework means that there are no explicit regulations to be kept into account. However, two important elements must be kept in mind from the assessment above: - There is no consensus or common position on which types of information are needed, or which requirements this information should meet. - There is no consensus or common position on how trust in identity information or identity infrastructure can be established at the cross border level. The link between authentication and electronic signatures offers some potential for building interoperability, as will be discussed below. 5.2.1.2 Conceptual link between electronic signatures and electronic authentication As shown in section 4.3.2., PKI is an increasingly popular (being present in 78% of countries) choice as a solution for electronic authentication, though not fully dominant (66% of countries also report the use of non-pki login systems). PKI indeed has several key advantages over more traditional systems such as simple username/password systems or multi-factor authentication, including the potential for greater security, and the possibility of combining authentication and signature functionality by providing a solution with certificates that can be used for both purposes. However, this functionality is not always clearly demarcated. This is most clearly visible in section 4.3.1. of the report in relation to authentication policies, where it was noted that a number of countries indicate that the concept of a qualified signature is considered to be the highest level of authentication, with anything else being considered a lower level. This was observed e.g. in Austria, Italy, Malta, Poland, Romania, Slovakia, and Slovenia. Thus, the status of a qualified certificate is also used de facto as a quality label in an authentication context. It is clear that this opens certain perspectives in relation to interoperability, as the concept of a qualified certificate is a European one, meaning that at least this top level of an authentication policy could be applied in a cross border context to establish trust. Indeed, as was briefly noted above, the Austrian egovernment Act already provides for the option of recognising the equivalence of foreign eid solutions based on qualified electronic signatures, and in Estonia plans exist to explore this possibility to create a policy for accepting foreign qualified certificates both for authentication and for digital signing. None the less, it should not be overlooked that the issues being examined are not identical for esignatures and eidm. While qualified certificates can be used as a suitable basis for building cross border trust in the PKI infrastructure itself, other fundamental questions are not addressed. Page 212 of 228

For instance, the definition of an advanced electronic signature (article 2.2) simply states that the signature must be capable of identifying the signatory, without specifying how this could be achieved; and the definition of a certificate merely states that it must confirm the identity of that person. Indeed, even when referring to qualified signatures, Annex II of the Directive explicitly avoids this issue and leaves its resolution to the Member States: ANNEX II - Requirements for certification-service-providers issuing qualified certificates Certification-service-providers must: [ ] (d) verify, by appropriate means in accordance with national law, the identity and, if applicable, any specific attributes of the person to which a qualified certificate is issued; [ ]. As noted above, the surveyed countries do not typically regulate such appropriate means, at least in a generic fashion. In certain instances, regulation is introduced that governs the use of specific identification means within a specific context (and specifically the use of identification numbers being used in an e-government context, or the mandatory inclusion of specific identifying information in qualified signature certificates). However, extrapolation of these specific rules to a broader context is usually missing. The lack of a generic legal framework for electronic authentication (including through PKI means) does not preclude PKI signature systems from being a perfectly suitable technical solution for eidm: the actual reality in the surveyed countries shows that such systems can and do perform an entity authentication function. However, it is important to note that the Directive itself is not concerned with entity authentication. In short, the issue of entity authentication is not currently regulated on a European level, nor on a national level. None the less, e-signature regulations are often quoted as an applicable legal framework for entity authentication in the national reports. This is based on a misconception on the goal and the scope of the Directive: while e-signatures can be used as a tool for entity authentication, the more fundamental question of how an entity is identified is not resolved in a consistent manner: while any advanced electronic signature by definition requires that the signatory can be uniquely identified, the Directive does not address how this effect is to be realised or implemented. Impact of this issue on interoperability: A consensus must be reached on how an entity should be identified, at least in electronic cross border situations. The e-signatures Directive builds on the assumption that this problem has been resolved, as the ability to uniquely identify the signatory is part of the definition of an advanced electronic signature. The analysis shows that this is not the case: while all of the analysed PKI systems identify an entity internally, there is currently no vision on how this effect can be extended in a cross-border context. At the same time, it must be acknowledged that electronic signatures using a PKI system can be a functional and suitable solution for entity authentication. However, the underlying normative framework is incomplete, and mostly has a beneficial impact on electronic signatures based on qualified certificates. Page 213 of 228

5.2.1.3 National perspective Another key question that was asked through the questionnaires in the study was whether or not specific interoperability measures had been taken to improve the cross border availability of applications. Specifically, this question aimed at identifying whether a Member State accepted IDM credentials issued in another country without requiring prior registration with a local administration. The response was universally in the negative, except insofar as esignature means were used for authentication purposes. In the latter case, qualified electronic signatures are used in a cross border context to a limited extent. For more details on this specific issue, we refer to the 2009 Update of the Preliminary study on mutual recognition of esignatures for egovernment applications [RD10]. IDM systems as such however are still by and large designed with a homogeneous user group in mind, namely that of entities residing or registered in the application owner s country. This should of course not be taken to mean that non-resident entities (foreign citizens without residence in the country and companies established in another country) are excluded from using egovernment applications requiring some form of authentication; indeed, the examples in section 4 show that governments are showing increasing attention to the needs users other than their own citizens, e.g. by offering foreigner eid cards to resident foreigners, by allowing soft certificates which are also available to foreign citizens or companies, or by using username/password systems relying only on on-line registration without resorting to information that is only available to citizens. None the less, the surveyed countries clearly take a purely national perspective, not in the sense that non-resident entities are excluded from egovernment applications; but rather in the sense that they only permit the use of credentials which are issued and managed by the governments themselves, or by private partners established within the country itself. Exceptions to this rule, i.e. where foreign Page 214 of 228

credentials are accepted as valid and sufficient without requiring prior registration in the application owner s country, are rare to non-existent, with the exception of signature solutions based on qualified certificates. The extent to which this is considered a problem depends on one s interpretation of the notion of interoperability. One might consider that a system is interoperable if it allows non-resident entities to gain access to the system and use it under conditions that are not unduly burdensome, even if this does require prior registration and the issuing of country-specific credentials. However, true interoperability requires that a system allows non-resident entities to gain access to the system and use it by relying on the credentials issued by the non-resident entity s country, without prior registration or the issuing of new country-specific credentials. Under that criterion, none of the surveyed countries offer a truly interoperable authentication solution outside of a signature context. Impact of this issue on interoperability: All IDM systems that are currently in common use require non-resident users to register again and/or to receive new credentials which are useful only in a specific country or context. No real identity federation in a policy sense exists on a cross border scale outside of the context of electronic signatures based on qualified certificates. Page 215 of 228

5.2.1.4 Use of protected identifiers As shown in section 4.1.2.1. and following, the surveyed countries use a wide variety of unique identifiers for electronic identity management, some of which are subject to specific legal protection regimes (i.e. beyond the general protection conferred on the data subject on the grounds of the Data Protection Directive). All countries have introduced identity numbers of some sort for the entities registered within their borders; however, the situation is noticeably different for legal entities and for natural persons. For legal entities, the problem of privacy is irrelevant (except of course insofar as the privacy of natural persons managing the companies may be concerned), and it is therefore not very surprising to observe that identification numbers for legal entities are both omnipresent and largely unprotected. This is intuitively clear based on e.g. VAT regulations, which imply that VAT numbers are accorded to legal entities (and entrepreneurs) who are economically active and subject to VAT regulations, which already covers a substantial part of European legal entities. Thus, the practice of issuing unique national identity numbers does not present specific legal or policy issues. In contrast, the situation is much more complex for natural persons. As discussed more extensively in section 4.5.3., a large variety of situations exists. While again all countries issue identity numbers in some form to their residents, the use of identity numbers is frequently difficult or even impossible in cross border situations. Apart from the general difficulties stemming from the applicability of the Data Protection Directive and its national transpositions to a cross border authentication framework, several countries actively oppose the use of generic and non-sector specific identification numbers for natural persons, including e.g. Germany and Hungary (which both oppose generic identity numbers on constitutional grounds), or only permit the use of such identifiers in specific authorised contexts, which never include cross border use cases. Such restrictions are of course permitted under the Data Protection Directive, which explicitly notes that 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 of the Data Protection Directive); however, cross border usage of such identifiers can become highly problematic. This is also one of the key problems currently being explored in STORK: how can users be uniquely identified, other than by relying on national identity numbers which may not be re-usable at the cross border level for legal reasons? Several options are being explored at the present stage, including the use of opaque and transient identifiers 117, but it is not yet clear how these will be used in practice. This is one of the open issues which will also be explored in the remainder of this study, including possibly through the drafting of a Memorandum of Understanding. Impact of this issue on interoperability: For legal entities, cross border use of identification numbers is generally not problematic. However, for natural persons this approach is politically difficult and potentially legally impossible, as it clashes with national laws and policies in several countries. Thus, generic and permanent national identification numbers will likely not be a part of a European electronic identity concept for natural persons. 117 See http://www.eidstork.eu/index.php?option=com_processes&itemid=60&act=streamdocument&did=577 Page 216 of 228

5.2.1.5 Inadequate local identity infrastructure As discussed in section 5.2.1.1., on-line identification relies on two basic requirements: a basic data set that provides sufficient information to consider the authenticating entity to be identified, and sufficient certainty that this information is correct. From this understanding we can conclude that a country wishing to see uptake of its national eidm solution in foreign countries needs to be able to guarantee both. This has an essential implication for cross border authentication. Specifically, a country offering an authentication mechanism must offer sufficient guarantees that the information that its system provides is correct and reliable. Without any guarantees in this respect, the usability of an on-line authentication mechanism will be negatively impacted, as other approaches will need to be found to determine the reliability of the provided identity information. Such other approaches (e.g. reputation based identification) may be difficult to use at a cross border level, as the context in which a foreign identification mechanism was created and operated may be difficult to determine for relying parties in another country.. Thus, reliability and trustworthiness of cross border electronic identification implies that the country itself (or the entity that it relies on to offer the eidm solution) must have a sufficiently elaborated identity infrastructure to allow this functionality. In short: each country must be able to draw on reliable local data sources. In some countries, this process has been facilitated by taking up the authentic source principle, i.e. by designating one source (such as a register, database or token) as authoritative and correct for any specific identity attribute. This means that any relying party receiving data from that source can assume that the information it is receiving is correct. Such a system is can be beneficial to the creation of an interoperable identity infrastructure, since it means that a specific source for reliable and accurate data exists. Formal acceptance of an authentic source principle was however reported in only 6 countries out of 32 (19%), virtually equal to the 2007 edition of the study (5 out of 32). A further 10 countries (31%) had informally adopted the principle (as compared to 9 in 2007), with another 3 (10%) planning to do so (idem as in 2007). Generally, the table shows that 60% of countries have formally or informally decided to adhere to the authentic source principle, or are planning to do so. As the quality of the underlying identity infrastructures continue to improve, this number can be expected to rise, which could prove to be enabling to cross border authentication, as it would become easier to obtain accurate identity information or to verify it. Regardless of whether or not such an authentic source principle is accepted, it is clear that the creation of interoperability between existing eidm systems requires that countries have a reliable identity infrastructure in place, i.e. an identity infrastructure in which identity information is kept up to date, and in which inaccurate information (including erroneous duplicate information) is removed or corrected. The overview in section 4.1.3.1. shows that this is not always the case, neither with relation to unique identifiers (where duplicate numbers assigned to different entities are rare, but not completely unheard of) nor in relation to identity databases (where duplicate/incorrect data is occasionally observed). Impact of this issue on interoperability: The availability of accurate and reliable sources of identity information is a prerequisite for interoperable identity management. Countries which cannot or will not offer sufficient guarantees with regard to the reliability of their local identity information infrastructure will not be able to partake in a pan-european interoperability mechanism, as even a small number of failures would undermine the credibility of the concept. Page 217 of 228

Page 218 of 228 eid Interoperability for PEGS: Update of Country Profiles

5.2.1.6 Defining identity from a semantic perspective As noted above in sections 5.2.1.1. and 5.2.1.2., one of the core problems to be resolved is that there is no clear national concept of electronic identity in most countries, nor a European one. Both notions are currently being interpreted from a purely pragmatic perspective, looking at the informational and security need of each specific application as it is being designed or modified. None the less, a common European interpretation on the semantics behind the concept of electronic identity is necessary, if only to ensure that a consistent set of identity information can be exchanged when needed and permissible. This does not necessarily require regulatory intervention; a common understanding can also be developed via other means, such as the STORK large scale pilot. None the less, a governance model will need to be established to sustain this approach beyond the pilot duration. Building on the recommendations of the 2007 edition of this study, the STORK project aims to develop inter alia a model which is built on local (typically national) Pan-European Proxy Services (PEPS) that are interconnected in a federated model, and which would be able to connect directly other PEPS in other Member States, or directly to identity providers in countries that rely on a middleware approach without implementing PEPS portals. Generally speaking, in this model Service Providers (SP) would pass a certificate validation request to its local PEPS, which would redirect this request to the PEPS of the Member State in which the issuing CA is established (or directly to an Identity Provider (IP) if that Member State is a middleware country). The targeted IP then issues a certificate validation response which will be re-routed back to the initiating SP. This offers an opportunity to address semantic identity management issues in a more systematic way, as a PEPS could conceivably collect local identity information (from PKI certificates or authoritative databases) which are then mapped by the local PEPS to a common XML based format, which could then be resigned by the PEPS to ensure its trustworthiness. Thus, this issue can be addressed at the pilot stage via the STORK project. In addition, the aforementioned CROBIES work also provides a crucial input to address this issue for qualified certificates, since it will result in a harmonised serialnumber becoming a mandatory component of qualified signature certificates, which could also prove to be a vital component for the STORK model to link the e-signature verification functionality to the identity management issue. It remains to be seen however how these initiatives can be brought to a more permanent form. Impact of this issue on interoperability: Without a common interpretation of the semantics behind electronic identity, at a minimum for legal persons and natural persons, application owners are forced to decide on a case by case basis which information they need, and how they should interpret the information they received. A common European concept of the semantics behind electronic identity needs to be identified. Page 219 of 228

5.2.1.7 Engendering trust It was noted in section 5.2.1.1. that electronic authentication implies two components: access to adequate identity information, and sufficient certainty that this information is correct. Section 5.2.1.6. directly above dealt with the former issue (defining a specific informational data set), and the current section deals with the latter (engendering trust in the information provided). This is a particularly thorny issue in the field of identity management, since section 4 has shown that the surveyed countries use a wide variety of solutions, some of which could be considered highly secure (e.g. smart cards containing certificates which are only issued after prior identification in person and relying on multiple pre-issued identity documents) and some of which have an almost negligible security value (e.g. username/passwords which are sent by unsecured e-mail after an electronic online registration in which a simple web form is filled out). Clearly, not all solutions are equal, and not all are suitable for all applications. Regardless of the authentication solution being used (smart card, username/password, two factor,...), there must be some form of legal guarantee with regard to the accuracy of the identity information being provided through the system. That is to say, a relying party who receives identity information after a successful authentication process must have a tangible guarantee that this information is indeed the information that the authentication solution provider has stored on his system. Without such guarantees, there is little reason to trust an electronic authentication system. This is a question that is currently also being explored in the STORK project: to what extent are national assurances needed in relation to the national components of a cross border identity infrastructure, and how can these be formalised (e.g. via supervision or accreditation processes)? Impact of this issue on interoperability: Trust is a key component of electronic authentication. A way must be found to ensure the trustworthiness of national identity infrastructure at a cross border level. This implies that a common trustworthiness classification mechanism (i.e. an authentication policy) is defined; that all eids to be used at a cross border level are classified in this mechanism; and that a governance model is implemented which allows relying parties to have faith in this classification. In the absence of such a classification mechanism, there is no realistic way to assess the trustworthiness of foreign eids. 5.2.1.8 Authentication policies In section 4.4. an overview was provided of the surveyed countries policies toward authentication policies, i.e. the definition of multiple levels of authentication means, which allow specific authentication solution to be accorded a specific security level. As was shown and discussed in section 4.5.4., uptake of such policies tends to be informal: of the 32 surveyed countries, only five claimed to have formally (i.e. through some form of governmental decision) adopted authentication policies, with another thirteen having informally embraced this. The definition of authentication levels is of key importance to the creation of a pan-european interoperability framework, as was already stressed in the Roadmap for electronic identity Page 220 of 228

management 118. The reason for this is merely of a practical nature: in order to allow egovernment applications to accept foreign eidm credentials, they must be able to determine whether the provided solution offers the necessary guarantees with regard to security and reliability. The only alternative is an ad hoc approach, where governments decide on a case by case basis which foreign eidm credentials are sufficient for their applications, keeping into account their national policy preferences. However, such an ad hoc approach is inefficient, requires all countries to perform the relevant assessments individually with possibly inconsistent results that would encumber the proper functioning of the internal market, and does not scale since it offers no way of easily accounting for changes in technology or in policies. As was noted above, this perspective has already been taken to some extent in Austria and Estonia, with the Austrian egovernment Act already providing the option of recognising the equivalence of foreign eid solutions based on qualified electronic signatures, and in Estonia plans exist to explore this possibility to create a policy for accepting foreign qualified certificates both for authentication and for digital signing. However, both of these approaches rely uniquely on the concept of qualified certificates. At the European level, a broader perspective would be favourable. A first step to address this issue was taken in the 2007 edition of the present study, which included the development of a Proposal for a multi-level authentication mechanism and a mapping of existing authentication mechanisms 119. This proposal has received some further attention at this time, including via the work within the European Network Information and Security Agency (ENISA) to translate the proposal to SAML v2.0 120. In addition, STORK has further developed and enhanced the proposal for its own purposes, via the STORK Quality Authentication Assurance scheme 121, which could lead to further refining in the longer term. Each of these developments represent a significant step forwards since the previous edition of the study. However, as acknowledged in the STORK deliverable, the challenge of addressing compliance assessment and supervision in applying such a scheme at the national level still largely remains to be addressed. Impact of this issue on interoperability: Interoperable identity management on a European scale requires the definition of authentication levels and the classification of all eidm means into such classifications. This entails three phases: 118 See http://ec.europa.eu/information_society/activities/egovernment_research/doc/eidm_roadmap_paper.pdf 119 See http://ec.europa.eu/idabc/servlets/doc?id=29622 120 See http://www.enisa.europa.eu/act/it/eid/idac-saml 121 Phase 1: The definition of multiple authentication levels on the basis of abstract criteria. Substantial prior work has already been done in this field that can be built on, most notably the IDABC efforts and the STORK QAA scheme Phase 2: The classification of existing authentication methods being used in the surveyed countries into the levels above. Within the STORK project, this is being done at a pilot stage for the participating countries; in the longer term, a more encompassing solution must be found. This also implies the creation of sufficient assurances, possibly including accreditation and auditing schemes. Phase 3: The Member States should commit to specify a security level as an authentication requirement of their egovernment applications, rather than requiring a specific means (i.e. level 3 required, rather than national eid card required); and they should accept any authentication means that has been granted the required security level or better. Published at http://www.eidstork.eu/index.php?option=com_processes&itemid=60&act=streamdocument&did=577 Page 221 of 228

5.2.1.9 Data protection and private sector involvement As noted above in section 5.2.1.2., electronic authentication services that are only usable in egovernment applications have a fairly weak business case, since the average user has little need to communicate with public administrations in everyday life. Restricting electronic authentication means to this purpose only would therefore risk alienating users by offering them a solution with limited possibilities and a sub-optimal added value over non-electronic transactions. For this reason, extension of the use of the authentication means to the private sector is generally considered to be a favourable trend, both as an identity consumer (i.e. a single set of eid credentials can be used both in public sector applications and private sector applications) and as an identity producer (i.e. eid credentials are issued or managed by a private sector service provider (like a financial institution or telecoms provider) and can be used in public sector applications as well. However, it is also clear that an authentication system that can be used in private sector applications or that uses private sector identity infrastructure will have to offer at least the same privacy protection level that a similar offline authentication process would offer; and any technical measure to improve privacy protection beyond this standard (e.g. by limiting the amount of provided identity data to the strict minimum required for the purposes of the application) should be seriously considered, as dictated by the basic principles and key provisions of the Data Protection Directive. In all circumstances, it should be the data subject that controls the authentication process and the released data to the maximum extent possible, and not the owner of the authentication infrastructure or the application owner. In practical terms however, this is extremely challenging at the cross border level, since all existing challenges that already exist at the national level remain (including lack of knowledge and awareness with participants in the systems), and new challenges are added (including language barriers when attempting to obtain informed consent from an end user for an authentication process and the possible clash between two national legal regimes). These issues are being explored in the context of the STORK project as well, and will also be a part of the remaining work planned for the present study. Impact of this issue on interoperability: Cross border identity management should include private sector involvement. However, sufficient safeguards should be built in to ensure that the identity attributes of natural persons remain under their control to the maximum possible extent; i.e. the data subject remains the data owner, and he/she alone can decide to give her identity attributes in stewardship to private sector users. All technical means should be considered to ensure that the transfer of identity data will remain limited to the strict minimum required for the purposes of the application. Beyond the aforementioned challenges in relation to unique identifiers, the main complexities will be to find a way to address data protection challenges in a cross border environment, and in resolving possible conflicts between national laws. Page 222 of 228

Page 223 of 228 eid Interoperability for PEGS: Update of Country Profiles

5.2.2 At the technical level Based on the technical analysis under section 4.6 above, this section contains an interoperability impact assessment of the identified technical infrastructures. The main goal of this section is to identify technical similarities and differences, which have an impact on interoperability of eid solutions and hence of the supported egovernment applications. Earlier in this report we observed that national identity management infrastructures are not stationary, on the contrary identity management infrastructures are one of the most nascent ICT fields in EU Member States. In the analysis chapter of this report we already addressed both present identity infrastructures and planned identity infrastructures. Both of these development phases were then compared to results of an earlier study which was conducted in 2007. Due to this constant advancement of the technical identity infrastructures the importance of understanding the impacts of the technological direction becomes more essential. 5.2.2.1 Incomplete local identity infrastructure In sections 4.7.2.1-4 we observed that most of the countries have already developed their local identity infrastructures using centralized governance and processing model. Particularly this type of approach to the local identity infrastructures has grown since the last study conducted in 2007. As noted earlier, local identity infrastructures are in a state of a constant movement, so this type of development is also on-going in several countries (i.e. some of the countries were currently planning such advancement to their infrastructures). This constant development process elevates the importance of understanding the impacts of used technologies and standards in local identity infrastructures. Standardization of different processes and technologies in European identity management field has also been advancing simultaneously with the local identity infrastructures. We were pleased to notice that most of the countries currently on a pre-development phase have decided to use these European standards, because of this they will have a slight advance against the countries already using local standards during the implementation of a European interoperability network. In a sense, countries can be divided into three different sections: a) Developed eid countries with a central eid infrastructure. These countries usually already have working infrastructure for eid and they also maintain specified planning for future development of such systems. b) Developed eid countries with a distributed eid infrastructure. These countries usually already have working infrastructure for eid and they also maintain specified planning for future development of such systems. In contrast to the centralised approach these countries have chosen to work with several different distributed systems (usually these methods are then accepted authentication mediums for central locations). c) Non-developed eid countries, which usually either do not have anything implemented and planned; or which have nothing implemented, but are currently ongoing development on planning phase. Page 224 of 228

Impact of this issue on interoperability: New developing eid countries are focusing more on common EU standards and putting more weight on interoperability already on a beginning of their implementation phase. This will help them to attach their infrastructures more easily to pan-european eid system. Thus more detailed best practices would help them more during the initial planning phase. A consensus must be reached on how to connect different eid approaches. The analysis shows that two different approaches are used. A pan-european eid system needs to connect both decentralized and centralized approaches. Connecting countries with selected decentralized approaches will cause more complicated trust structures. Standards and already existing interoperability projects should be advertised more to EU Member States. 5.2.2.2 Continuously evolving national frameworks As shown in 4.7 and following, several countries are continuously in a state of future implementation. In the course of this study of the surveyed countries infrastructure it was found that not all necessary information about planned eid structures was either ready or publicly available. How to promote and build architectural plans for European level identity management if not all information is made available? We can also see several improvements and changes between the study performed year 2007 and this current study. For example, several countries have selected to adopt smart cards, but at the same time some of the Member States have decided to change from smart cards to other hardware tokens. This also raises the question, how can the development of an interoperable architecture be stable if the countries are moving to totally different directions? Most rapidly growing authentication method seems to be different type of mobile authentications (when comparing previous and this study). More countries are adopting mobile phone as certificate carrier or implementing different type of SMS-based mobile authentication schemes. At the same time when Member States are developing their electronic identities used by citizens also other important aspects of eid infrastructures are evolving. The eid platforms and applications used are undergoing constant development. The current trend in eid architecture seems to take Member States closer to a centrally managed egovernment infrastructure. Currently several Member States are integrating or planning to integrate some kind of central gateways to their egovernment services. Authentication and authorization portals are the next step of evolving Member States eid architectures. This trend is already seen between the two studies (2007-2009). Impact of this issue on interoperability: It is essential to include future infrastructural plans of Member States within a European Level identity Management scheme. This should be noticed also in different on-going interoperability pilots. The semantic interoperability need to be achieved. Member States need to commonly agree set of rules how eid schemes are developed. System interoperability in communication and syntax of transmitted data needs to be stable. Once achieved interoperability in exchange of data should not be compromised by evolvement of one Member State eid infrastructure. Page 225 of 228

5.2.2.3 Multitude of token types / identity mechanisms As shown in 4.7.1.1 Member States have chosen different type of tokens to be used. Based on our analysis we can see that most of the countries have selected to build their own national eid based on one smart card vendor and profile. Thus some of the countries have outsourced the production of their national eid, in most cases this leads to situation where there is several different smart card types. The third method is not to select any primary approach to national eid, but instead use and accept all evaluated CSP and their systems to be used in egovernment services access. Even if a Member State is using a smart card based eid, it is not clear that the systems will be interoperable. Member States have implemented and continue to implement totally different types of identifiers inside smart cards. Some of the Member States are relying on PKI based certificate usage within smart cards, but at the same time others are using other predefined set of data to identify citizen with smart card. Impact of this issue on interoperability: The lack of commonly agreed identity mechanisms and differentiating tokens are creating challenges both on the system authentication level and on the cross border visitor s level. - Entity authentication and authorization which is done on system level in user s home country should be standardized. Depending on the level of security within authentication, user should be able to access different type of services. - Entity authentication inside a foreign country should have a proof that identity token and mechanisms used within his/her home country can be used. Challenge of both interoperability of carried medium and commonly agreed security levels of carried medium. 5.2.2.4 Incompatible middleware issues As shown in 4.7.1.4 Member States are using different varieties of middleware to enable usage of their identity tokens. Some of the counties are developing their own middlewares, some are using open middlewares and some are using vendor produced solutions. From the citizen s point of view this is the most problematic issue when travelling between different countries. Currently there is no common way to read a citizen identity token between Member States. This creates problems for citizen and public officials if identity information needs to be retrieved from citizen home country when citizen is located in other Member State. As noted earlier there are several different type of National ID cards issued by National governments for their citizens. Most of the new identity cards issued by the Member States are now including a chip (microprocessor), which increases the security due to the fact that those are virtually impossible to be counterfeited. These types of new e-id cards can then be used as storage of a unique electronic user data. On a local government level those types of cards can then be used by user when logically accessing the egovernment services. But due to current non-standardized implementations of such eid cards several different type of smart cards are being used and this creates a challenge to the European interoperability network. To harmonize such data and security architectures in EU-area and to create more complete interoperability both on a card and on a middleware level the specification called European Citizen Card (ECC) was created. ECC is an open application standard, defining logical data structure, security and privacy mechanisms of the data and interface and communication protocols. Selecting such common European standard the national government increases the country s readiness to cross border interoperability in eservices. Page 226 of 228

Impact of this issue on interoperability: A common middleware on the level of a token or on the level of a middleware needs to be achieved or a common smart card standards need to be followed in each EU Member State. Both of these issues could be solved if EU Member States would agree to follow the commonly agreed standards: The technical aspect of the specific middleware is based on guidelines, EIFspecifications and standards. eid card compliant with the European standards requirements (like EN 15480 Identification card systems - European Citizen Card). 5.2.2.5 Design of authentication and authorisation models The Member States do not currently have a commonly agreed model for identity verification and authentication of entities; this is an additional challenge to be resolved. Some of the countries are accessing services on a service level and some of the countries are using authentication gateways to access egovernment services. Thus since the last study (2007) the single point of access model is gaining more popularity in EU Member States. As shown in 4.7.2 and following there are several different types of solutions for authentication and authorization of users in Member States. Based on the country profiles we can see that PKI as an authentication method is becoming more and more popular and several countries which are not yet using it on a significant scale are planning to do so in coming years. This is development which will resolve a part of the question of authentication, but still it will not answer the question of authorization. The question of authorization is even more problematic than the authentication: who can decide which kind of services can be accessed by the authenticated user? Countries without centralized systems to achieve this might have both technical and internal political reasons to do so. If a citizen of a Member State cannot access all egovernment services without registering individually for all different services, then how this can be managed in European level? Impact of this issue on interoperability: It is essential to solve the problem of missing commonly agreed citizen authentication method and method when exchanging authorization and authentication data between different peers. The Member States need to agree on services accessible by European system and consensus should be found how entities can be identified to these systems. There are several good on-going interoperability studies which should be followed, including the CROBIES study, the STORK pilot, and ongoing eid related work in the other large scale pilots. Page 227 of 228

5.2.2.6 No European identity framework As pointed out above national eid infrastructures are constantly evolving. Member States have a will to build their systems to be interoperable on European level. Several Member States have even stated this one of most challenging problems for their own development. Currently countries are either just developing their system for internal use only, while some countries are attempting to predict what the European level identity framework will be. And some are participating in smaller scale pilots, where only few countries are as a participant. There are no common standards, so how should Member States build interoperable systems? Impact of this issue on interoperability: Building a European identity framework is important for future interoperability. If Member States are to follow a European identity framework, there needs to be one first. More Member States should be involved in to currently on-going interoperability projects, such as STORK, Peppol and Spocs 5.2.2.7 Tokens and eidm profiles As shown in 4.7.4 the most open question for Member States is still the architectural model of the eid infrastructure. Out of 32 countries only 11 have specified some details of their preferred token model when exchanging authorization and authentication data between different eservices. Thus this number has risen from the previous year 2007 study from 7 to 9, but still no higher development can be seen on this section. Countries which have chosen a model are most often using a SAML based approach. From this section we can also see that the project STORK is seen as one of the most important development project for interoperability between the EU Member States. Impact of this issue on interoperability: The lack of commonly agreed tokens and eidm profiles is challenging. Already during our previous study we noticed that a common structure of tokens needed to be drafted. Project STORK should be given all possible support to achieve this goal. Page 228 of 228