2. AS-IS
2.1 Description of requirements
While setting out to create a predictable regulatory environment for trust services and ensuring that people can use their own national electronic schemes to access public services online in other EU countries, the state of play demonstrates shortcomings to the full implementation of the eIDAS regulation. As the implementation date for the SDGR and its 21 prescribed online procedures approached, national administrations faced a dual challenge of enforcing two complex and resource demanding regulations. However, as the eIDAS and SDGR are interrelated, the challenges prove similar for many countries. Resolving the central obstacles through cross-border cooperation is the key. One of these obstacles is identity matching.
Figure 1 Identification matching areas affected by regulations (eIDAS, SDGR, OOP, GDPR).
Figure 1 illustrates what areas of identification and record matching are affected by regulations described below in this chapter. For the sake of the volume of this document and because of wide coverage of the topic elsewhere, the in-depth description of GDPR is not included. However, GDPR and identity matching are related because identity matching processes often involve the handling of personal data, and GDPR provides the legal framework for the protection of personal data within the European Union. Organisations conducting identity matching activities must comply with GDPR regulations to ensure the privacy and security of individuals' personal data.
2.1.1 eIDAS – electronic IDentification, Authentication and trust Services
The eIDAS Regulation:
- ensures that people and businesses can use their own national electronic identification schemes (eIDs) to access public services available online in other EU countries.
- creates a European internal market for trust services by ensuring that they will work across borders and have the same legal status as their traditional paper-based equivalents.
The first version of eIDAS was ready in 2014 and implemented in 2016. Now, the Commission is already working on an updated version. The Commission proposal amends and updates the existing eIDAS Regulation by responding to the challenges raised by its structural shortcomings and limited implementation and to technological developments since its adoption in 2014.
The reason for updating the regulation was that not all eID key interoperability components of the older version of eIDAS were obligatory for EU Member States. As a result, only 14 of them completed their eID schemes which were all different. The new provisions will be mandatory for countries, which punishes those who have already achieved more and makes finding a common solution quite difficult. Madis Ehastu, Estonian Seconded National Expert at the European Commission who is actively developing the new eIDAS regulation, said that one of the key difficulties lies in finding common approaches considering substantial variations in legislations and cultures.
Regarding identity matching, eIDAS requires that electronic identification means used for cross-border transactions must be reliable and secure, and the identification of the user must be verified using robust authentication mechanisms. This means that the eID system must use methods that can confirm the identity of the user with a high degree of certainty and establish rigid issuance process and lifecycle management of electronic identities.
Additionally, eIDAS requires that the identification process must be carried out in compliance with data protection laws, with due regard for the privacy and security of personal data. This includes ensuring that the user’s personal data is processed only for the purposes of identification and that it is not disclosed to unauthorized parties. Furthermore, eIDAS also sets out specific requirements for the electronic identification means themselves, including technical specifications for the security features and mechanisms used for protection against unauthorized access and data breaches.
Identity matching is typically done by looking up and matching the identity received with the identities registered. For this purpose, the eIDAS Unique Identifier (eIDAS UID) can only be directly used if it is already known by the Evidence Provider. This may be true in cases where the Evidence Provider has already linked the eIDAS UID to a known identifier or has access to such a record. The eIDAS UID is a mandatory attribute in the minimum set of person identification data specified in the EC implementing regulation,
Commission Implementing Regulation (EU) 2015/1501 of 8 September 2015 on the interoperability framework pursuant to Article 12(8) of Regulation (EU) No 910/2014 of the European Parliament and of the Council on electronic identification and trust services for electronic transactions in the internal market
Notwithstanding the mandatory stipulation of the eIDAS UID, the persistency of eIDAS UID is not enforced and as consequence undermines its uniqueness characteristics. Some Member States issue an outbound identifier for each Member State, which is also usually derived. This means that the third part of the Unique Identifier, the combination of readable characters, may not have the same value for all requesting Member States. This means that in such cases, the eIDAS UID (PersonIdentifier) was issued for the specific context of the Online Procedure Portal, and it cannot be used by the relying party (Data Service).
How these outbound identifiers are generated is specific to each Member State and/or eID means. The derivation process could potentially prove challenging (or impossible even) for a matching function from the issuing Member State to identify the user based only on this identifier. Additional attributes may be needed. The information on the Unique Identifier, if it is derived and/or receiving Member State specific is communicated during the notification procedure and in the following resource. This information could be requested from the eIDAS Cooperation Network and configured accordingly.
2.1.2 SDGR – Single Digital Gateway Regulation
The purpose of the Single Digital Gateway (SDG) is to
- reduce any additional administrative burden on citizens and businesses that exercise or want to exercise their internal market rights, including the free movement of citizens, in full compliance with national rules and procedures,
- to eliminate discrimination and
- to ensure the functioning of the internal market regarding the provision of information, of procedures, and of assistance and problem-solving services.
The Regulation makes it mandatory for Member States and EEA countries to provide access to 21 digitalized administrative procedures in a safe and convenient way. The procedures include (amongst others): requests for a birth certificate, vehicle registration, starting a business or submitting a corporate tax declaration.
Full list of services is available in the Annex II of SDGR: https://eur-lex.europa.eu/TodayOJ/
The SDGR sets out several requirements related to Identity matching, which are detailed in the following paragraphs:
- Secure and reliable electronic identification: The SDGR requires that electronic identification means used for cross-border transactions must be reliable and secure, and the identification of the user must be verified using robust authentication mechanisms. This means that the eID system must use methods that can confirm the identity of the user with a high degree of certainty, such as biometric authentication or multi-factor authentication. The regulation requires that the eID means used must be certified under the eIDAS Regulation. This ensures that the eID system complies with strict security and privacy requirements.
- Reuse of existing data: The SDGR requires that public authorities must use existing data and information collected from other public authorities whenever possible. They must avoid collecting the same information from citizens and businesses more than once unless the information is necessary for a specific purpose.
- Limited collection of personal data: The SDGR requires that public authorities limit the collection of personal data to what is necessary for the provision of a specific public service or the fulfilment of a specific legal obligation. They must not collect more personal data than necessary or retain it for longer than necessary.
- Protection of personal data: The SDGR requires that public authorities protect personal data from unauthorized access, disclosure, or misuse. They must comply with the General Data Protection Regulation (GDPR) and other data protection regulations when collecting, processing, and sharing personal data.
- User consent: The SDGR requires that public authorities must obtain the explicit request of the user before collecting, processing, or sharing their personal data. Users must be informed about the purpose of the data collection, the legal basis for the processing, and their rights under data protection laws.Regulation (EU) 2018/1724 of the European Parliament and of the Council of 2 October 2018 establishing a single digital gateway to provide information, procedures, assistance and problem-solving services and amending Regulation (EU) No 1024/2012
Cross-border OOP will become a reality in the EU at the end of 2023, when the Member States are expected to finalize the integration of the 21 online procedures with the OOTS.
The procedures in directives listed in SDGR article 14.1 also must be integrated with OOTS i.e., Service directive, Professional qualification directive and Procurement directives.
Access to the gateway will be available via the search function of the Your Europe portal, which has existed since 2006 to provide citizens and businesses information on EU and national rights. The establishment of a single-entry point will contribute to a more comprehensive and user-friendly package of information and assistance, which will help EU citizens and businesses navigate the internal market. Furthermore, the gateway will be conducive to more transparency in terms of rules and regulations relating to different business and life events.
2.1.3 OOP – Once Only Principle
The principle states that:
- citizens and businesses should only be required to provide information to public authorities once, regardless of how many times that information is needed by different public authorities.
- Under the OOP, public authorities must share information and collaborate with each other to ensure that data is collected only once and reused by other public authorities as needed. This means that citizens and businesses do not need to provide the same information repeatedly, which reduces the time and effort required to interact with public services.
The OOP applies to all EU member states and covers a range of public services, including social security, taxation, and starting a business. It is intended to promote the efficient use of public resources and reduce the administrative burden on citizens and businesses. The implementation of the OOP requires the use of advanced digital technologies and interoperable systems to enable the sharing of information between different public authorities. This includes the use of electronic identification and authentication systems, secure data exchange platforms, and data protection measures to ensure that personal data is processed securely and in compliance with data protection regulations.
The main objective of the OOP – reducing the administrative burden of users and businesses by re-organizing public sector internal processes – derives directly from the overall political objective of improving economic efficiency of the EU by facilitating cross-border trade through such initiatives as digital single market.
EU eGovernment Action Plan 2016-2020.
- different understanding of the once-only principle,
- different approaches to public service provision,
- different IT systems that make such services possible,
- but also, different understanding of issues relevant to the once-only principle, such as protection of personal data, for example.Krimmer, R., Kalvet, T., Toots, M., Cepilovs, A. and Tambouris, E., 2017. Exploring and Demonstrating the Once-Only Principle: A European Perspective. In Proceedings of the 18th Annual International Conference on Digital Government Research (pp. 546-551). ACM.
While the OOP does not specifically regulate identity matching, it can impact the way in which identity matching is performed in cross-border transactions. In general, the OOP requires that public authorities should only request information from citizens and businesses once and should make efforts to reuse this information for subsequent transactions, provided that the information is still up-to-date and relevant. This can include personal information such as identity documents and tax identification numbers. When implementing the OOP, public authorities must ensure that they comply with relevant data protection laws, such as the General Data Protection Regulation (GDPR), and that they have appropriate measures in place to ensure the security and privacy of personal data.
European Commission. (2020). European Interoperability Framework - Implementation Strategy. Brussels: European Commission.
2.2 Technological readiness
2.2.1 Data required for identity and record matching
When people are moving, working, or studying abroad, it is usually only a matter of time when some services are needed while being in another country. Even though people are moving across borders more and more,
The Nordic Statistics database. (2020, October 30). Who goes where in the Nordic region?
Three different scenarios of three different fields were studied and are described below:
- opening a bank account in another country
- identifying the person and accessing past medical history
- recognition of professional qualifications
These three scenarios are described from the two main aspects of technological readiness: data and actors.
Banking: opening a bank account in another country
Opening a bank account is a process that involves identification of the person and collecting data related to the person’s financial behaviour. Process must follow EU’s anti-money laundering and countering the financing of terrorism (AML/CFT) rules.
Preconditions for opening a bank account vary depending on the chosen registration method. A physical presence in the bank office is suitable for all persons who qualify with banks’ general terms. Usage of e-services with eID means for same purpose does impose significant limitation. Namely the eID mean issued within country of bank’s residence is commonly required and must be complemented by person’s physical ID-document. The latter can be either a person’s national ID-document or the one issued by authorities of bank’s country of residence.
Availability of personal identification number issued by the county where the bank is operating is crucial for identity verification. Imposed limitations for e-services channels are justified with strict requirements coming from AML/CTF rules, and risks coming from cross-border identity matching based on eID means can be seen as un-acceptable liability considering potential operational, financial, and reputational damages. Thereof person’s eID mean originating from a country other than a bank’s residence country cannot be used for onboarding through e-services.
Data
Data collected during the opening of bank account through eID mean supported e-service must enable identity verification (1:1) of the person in the context of banks’ country of residence.
Data collected from eID mean comprises of following attributes:
- family name(s)
- first name(s)
- date of birth
- personal identification number
Data available from person’s physical ID-document:
- family name(s)
- first name(s)
- date of birth
- place of birth
- document number
- personal identification number in document issuing country.
- citizenship
In addition to personal identifiable information (PII) banks do request data that enable fulfilment of due diligence defined by AML/CFT rules.
Additional data presented by person:
- contact address (formal/informal)
- types of incomes
- tax payment countries
- expected monthly incomes and cash transaction amounts.
- accounts in other banks
- other country’s regulation specific data
Actors
Table 1 Opening a bank account in another country actors and responsibilities
Actor | Action | Necessary preconditions, successful authorization of: | Successful identification/authentication of: | Other directly involved' actors |
Customer from country A | Identifies him/herself in bank of country B | eID mean issued in country B. Possession of physical ID-document | Authentication with eID mean issued in country B. Validity checks and verification of presented physical ID-document | eID provider in country B Database of stolen or lost documents (country of document’s origin or Interpol SLTD (stolen or lost travel documents) database Identity proofing service provider of bank |
Bank in country B | Validates PII retrieved from eID mean and physical ID-document. Validates additional data submitted following AML/CFT rules | All requested customer related data is made available to bank | PII and additional data are successfully validated against population registry and potential black/grey lists of banks. Additional data meets criteria established by AML/CFT rules | Population registry of country B |
Customer from country A and bank in country B | Entering contractual relationship | PII is validated and AML/CFT rules fulfilled. | Acceptance of bank’s terms and conditions by customer. Signing of contract by customer and bank. |
To conclude, cross-border usage of eID means is not supported for opening a bank account in another country. Limitations coming from AML/CFT rules force banks to restrict account opening e-services to accept only eID means issued within the residence country of the bank.
Health: identifying the person and accessing past medical history
Treatment of patients without proper information on the patient’s medical background and history poses a lot of risks. There are already ongoing collaboration and practices between the Nordic and Baltic countries. A good example of an already working operational solution is the ePrescription exchange between Finland and Estonia. There are also projects such as the health care and care through distance spanning solutions – project (VOPD) led by Sweden.
Healthcare and care at distance. (n.d.). Healthcare and care through distance spanning solutions
Data
Today, European cross-border health data exchange consists of two services:
- cross-border digital prescription and
- patient summary
These two services are a part of eHealth Digital Service Infrastructure (eHDSI)
The eHealth Digital Service Infrastructure (eHDSI or eHealth DSI) is the initial deployment and operation of services for cross-border health data exchange under the Connecting Europe Facility (CEF)
The most important entities of eHealth DSI system are human beings (patients, HPs, administrators, etc.). However, there are many non-human entities in the eHealth DSI. The most important of them are documents in electronic form, which are of course always linked to a human entity.
Example (data related to human entity): Daniela Altenberg, born 29.12.1979 in Vienna, Austria, Father Gottfried Altenberg (*6.6.1953), Mother Elisabeth Altenberg (*6.3.1956, maiden name Eugenie) address of residence Vienna, Castle of Schönbrunn, No 1.).
Identity matching is completely a responsibility of the health care provider. For example, in Estonia, HCP must make an enquiry to a patient’s previous home country, previous home country checks from the population register whether a person has personal identification number, the person is alive and has allowed to share its medical records. Patients themselves don’t have electronic access to their previous medical records with foreign country’s ID.
However, patients still can request an extract from the medical records.
Within the eHealth DSI environment physical identity sources (passport, ID, diploma etc.) can be used within identification and authentication processes. At least two-factor authentication
eID authentication: ID number + password or electronic ID card.
It is the responsibility of each country to upload its own International Search Mask (ISM), to the configuration settings of the platform. And then this Search Mask clarifies what information about one’s patient needs to be asked to uniquely identify a patient, which varies a lot among countries. Many countries have just one ID: it can be a personal identification number, or document number, social security number etc. However, some countries use multiple.
The eHealth DSI environment is a set of National Contact Points (NCP) communicating by means of public networks. NCPs are interfaces or proxies between national eHealth domains. These national eHealth domains are not under direct control of eHealth DSI. Patient data and identities of patients, HPs, HCPOs are placed in registries, repositories, or databases in national domains and most of the data processing takes place there. Therefore, it must be distinguished between processes running in the intrinsic eHealth DSI environment and the processes running partially or totally outside the intrinsic eHealth DSI environment within the national domains. eHealth DSI and authorities/participants from national domains will together provide identification and authentication services.
The intrinsic eHealth DSI identity confirming and forwarding covers the following points:
- Management of selected identity datasets and/or identifiers:
- of single persons (HP, patient).
- of a group of persons (legal entity of healthcare providers, e.g., HCPO).
- of single documents (patient consent).
- Management of outgoing requests for validation of provided identities within the “Circle of Trust.”
- Management of incoming requests and responses to such requests.
- A secure, trustworthy, and reliable acknowledgement and vouching for the correctness of information provided by the national infrastructure and the HPs.
National authorities and institutions from national domains will provide:
- the accurate management of identities lifecycle, from the creation of identifiers of entities until they terminate.
- the accurate management of identity assurance, authentication of the identity information, and the assessment of the required level of risk assurance for collecting and using identity information (named “trust level” in the following descriptions).
- the accurate management of identity information at the level of the relevant identity authorities and.
- the accurate management of local systems and/or services which support the “Circle of Trust” (NCP).
The eHealth DSI services include the transfer of sets of agreed data, particularly, a patient summary, that also includes a medication summary and data related to the ePrescription (prescription and dispensation). Most of the data included in those sets correspond to health data and therefore these documents are referred to as health data. Utilizing eHealth DSI services to access health data is contingent on successful identification and authentication of the health care professional, the identification of the patient, the fact that the eHealth DSI system “knows” the appropriate documents and the requestor is assigned to a role which is authorized to gain access to eHealth DSI.
Currently, only patient summary is digitally accessible cross-border, provision of other medical data is the responsibility of the patient (printing out the medical history, translation etc.). Currently, the patient summary dataset must include active health problems, diagnosis codes and history of previous diseases. Optional content includes blood pressure data, blood group and rhesus factor data, allergy data, facts about smoking and alcohol consumption, and surgeries and procedure data. The patient summary is more of a standardized dataset that can be provided in a coded form. And in many countries provision of even this data is not possible yet.
Actors in MyHealth@EU
The following table summarizes the relevant activities of actors belonging to eHealth DSI roles (according to the basic scenario – HP from Country B needs patient’s health documents from patient’s home Country A). eHealth DSI is based on distributed systems and many functions will be executed by actors within national domains. The eHealth DSI role management depends strongly on cooperation with national authorities and operators of local systems. (See Table 2)
HCPO: In every country involved in eHealth DSI a national authority or a group of regional authorities must exist, able to define/manage HCPOs from its domain, participating in eHealth DSI. NCP will communicate with the respective national authority to keep the actual list of HCPO. eHealth DSI would define the minimal set of information necessary for unambiguous identification of HCPO.
HP: HPs identities will be managed in national domains. A national authority will maintain the list of all HPs in its domain and provide it to its national NCP. HCPO will provide NCP the roles assigned to its HP (if necessary). eHealth DSI would define the minimal set of information necessary for unambiguous identification of HP.
Patient: Each use case accessing the patient data, such as the Patient Summary and ePrescription/eDispensation use cases, requires the minimal set of necessary information for identification of a patient.
Authorized Third Party (optional): For member states allowing it, an authorized third party can perform any action the patient can perform.
Health data administrator: A health data administrator is primarily responsible for running systems which exchange health data on NCP. The second responsibility covers the support of patients whenever they want an extract of audit log data. Health data administrators are working for or on behalf of national authorities and from an eHealth DSI point of view the standard professional and security requirements fully suffice for this role.
Table 2 MyHealth@EU actors and responsibilities
Actor | Action | Necessary preconditions, successful authorization of: | Successful identification/authentication of: | Other directly involved actors |
HP B | Requests services from Country A | HP in Country B | HP in country B the patient by Country A | National Infrastructure B, NCP B NCP A |
Patient | Requests check and provision of audit log concerning the accesses to his health data | Successful authorization of HP | authentication of the patient at PoC | NCP A, Health data administrator |
Authorized Third Party (optional) | For the member states allowing it, can perform any action the patient can perform | Successful authorization of HP and authentication of the patient at PoC NCP-B and NCP-A must both authorize a third party to act on behalf of the patient | patient at PoC | Patient, NCP A, Health data administrator |
NCP B | Requests services from Country A | Successful identification and authorization of NCP A Authentication of the patient | NCP in county B The patient by country A | NCP A |
NCP A | Responds to service requests of NCP B | Successful identification and authentication of NCP B Authentication of the patient Authorization of HP/HCPO | The patient by country B NCP A | NCP B Identity authority managing the databases of patients, HPs, HCPOs |
HCPO or other external service provider | Provides required information to NCP | Mutual successful authentication of both parties | Both parties | NCP B HCPO or other external service provider |
Health data administrators | Administrate systems processing data and pro- vide some services (e.g., excerption of audit logs) | Successful identification of health data administrators Authentication of health data administrators Assigning the role of health data administrators | Health data administrator | NCP or HCPO |
EHDSI- Identity Management in MyHealth@EU
In many countries, not all the health care providers have joined with the services, so for example in Netherlands, there is currently just one Hospital that uses eHDSI. Main concerns for many countries are data security, trust issues and encryption used. Standards, privacy issues, technologies and translations are decided and included in eHealth Digital Services Infrastructure and the decisions made already in eHDSI are preferences for many countries.
It is planned that in 2025–2026, the technical prerequisites for the European Commission's central solution will be created, so it will be possible to share laboratory analysis data, hospital treatment summary data, medical records, and test response data.
Academia: recognition of professional qualifications
Professional recognition is the appreciation of a foreign qualification for the purpose of employment in a certain profession. The recognition of qualifications for professional (employment) purposes depends largely on whether the profession in question is regulated or is not regulated in the host country.
Data
IMI allows competent authorities to check data within the EU by making inquiries to other countries’ competent authorities and verify the data. ENIC/NARIC Network allows to make an analysis on a diploma and gives assurance about the higher education institution and confirms that the diploma was issued to a particular person.
However, there are no general rules for identification of persons. Competent authority generates a deed of identification that is not shared amongst other competent authorities and is not updated in case of personal data changes. So, if a person has different qualifications in different fields, one must go through two separate processes for identification and recognition of foreign qualifications.
Actors
Depending on the field of study, different competent authorities (usually ministries, professional associations, etc.) must evaluate a person’s qualification according to the Directive 2005/36/EC.
Directive 2005/36/EC of the European Parliament and of the Council of 7 September 2005 on the recognition of professional qualifications
Table 3 Recognition of foreign qualification, actors and responsibilties
Actor | Action | Necessary preconditions, successful authorization of: | Successful identification/authentication of: | Other directly involved actors |
Person (from country) A | Requests diploma recognition from country B | Person identification following Competent Authorities requirements Presenting diploma | Person A in Country B | |
Competent Authority of country B | Verifies diploma data and qualification | Data exchange system (IMI, ENIC/NARIC) | Competent Authority of country A | |
Competent Authority of country A | Confirms diploma data and qualification | Data of diploma | National data sources for educational and qualification records in country A | |
Competent Authority of country B | Issues deed of recognition | Diploma data and qualification confirmed by Competent Authority of country A |
Currently, competent authorities are mainly using ENIC/NARIC
2.2.2 An analysis and discussion of the availability and machine-readability
Based on three different scenarios of three different domains studied and are described in chapter 2.2.1, one can see remarkable challenges to be tackled if cross-sectoral data availability and data machine-readability would be targeted. Main aspects that must be confronted would be following:
- Implemented systems do vary from country-to-country dependent on availability of resources and/or volumes of cases. In addition, within the country implementations in sub-domains of specific domain may have significant discrepancies.
- Identity management processes are defined following requirements and risks-imposed domain. Requirements for identifying persons can be missing although the domain is regulated on EU-level, and matching identity with record is crucial.
- Domain specific data is not deployable for cross-sectorial usage, as it is commonly prohibited due to data protection constraints, data can be non-disclosable for reason of being a business/bank secret.
- Data is handled by numerous competent authorities, who have their own registries. Data is not often shared to allow automated processes for further use based on the received (digitized) data.
- Personal identifiable information at rest in most domains’ registries is not updated if any change in attributes occurs.
- There are EU level systems for domain specific communication and data exchange, but their interfaces are designed differently. Besides human-to-machine interaction human-to-human interfaces are still deployed. Human-to-machine interface does provide better options for data machine-readability, whereas human-to-human interfaces exploit free text data fields, and no format harmonization has been achieved either for evidence exchanged as digital files. A lot of cross-border identity and record matching is based on paper documents and manual work.
- Implementations are made to solve single domain specific use cases at the time and do not scale nor provide reusability of data.
To sum up the aspects provided above, it can be stated that availability and machine-readability of data is constrained by existing implementations and legislation. Thus, deploying them as-is for a large-scale identity and record matching is not feasible.
From identity and record matching perspective it should be targeted, that personal identifiable information is handled in cross-domain use cases in a manner that enables deployment of harmonized principles facilitating the matching necessities. Providing solution, which centrally deals with identity management (creating identities accompanied by adequate attributes, mechanisms for updating the attributes (while keeping initial values) and enriching identities with attributes originating from other countries (e.g., personal identification numbers) and is available for cross-domain usage should be focused on.
2.2.3 Description of identity matching in the Once only technical system
To date all countries have opted to consider unique user only within a member state. Linking data between member states based on user attributes (see Table 4) is almost non-existent.
The technical and operational specifications of the Once-Only Technical System (OOTS) is laid down in the European Commission’s Implementing Regulation (EU) 2022/1463. Regulation (EU) 2022/1463 foresees usage of eIDAS nodes for cross-border authentication of a user by electronic identification means issued under electronic identification schemes notified in accordance with Regulation (EU) No 910/2014.
eID schemes from the Member State of the Evidence Provider, which are deemed adequate for the access to the Evidence Providers' services may also be relied upon. This includes both notified and non-notified eID schemes.
Identity matching is the role and responsibility of evidence providers following Regulation (EU) 2022/1463. Evidence providers’ application services shall be capable of identifying the user through eIDAS node, perform matching of PII with identities known to evidence providers and retrieving correct identity evidence from their records. Evidence providers may require users to provide additional attributes beyond the mandatory attributes of the minimum data set listed in the Annex to Implementing Regulation (EU) 2015/1501 for the purpose of identity and evidence matching. Referenced additional attributes can be either optional attributes of the eIDAS minimum data set and/or sector specific attributes that may be made available via the eID scheme used, if it is allowed by the national law and if the user gives their consent for this purpose. However, the use of eIDAS node does not preclude the use of other mechanisms to provide complementary or additional security measures.
It is mandated that evidence can be processed only in case identity matching generates single result.
Neither Regulation (EU) 2022/1463 nor OOTS Technical Design Documents do specify methods for identity matching. OOTS Technical Design Documents do acknowledge the variety of combinations of how personal identification numbers may be presented through eIDAS node (personal identification number being derived or not, derivation receiving Member State specific or not), but logic design for handling various combinations is left up to national implementations.
Hereby table of Identity attributes will be compiled to illustrate possibility of finding common solution for Nordic-Baltic countries (Table 4).
Table 4 Identity attributes of European countries
COUNTRY | EIDAS BASIC DATASET | ADDITIONAL ATTRIBUTES | ||||||||||||
EUID | FIRST NAME | FAMILY NAME | DATE OF BIRTH | GENDER | OTHER NAMES | NATIONALITY/CITIZENSHIP | COUNTRY | PLACE OF BIRTH | CENTURY OF BIRTH | CURRENT ADDRESS | BIOMETRY | FIRST NAME AT BIRTH | LAST NAME AT BIRTH | |
Estonia | x | x | x | x | x | x | x | |||||||
Spain | x | x | x | x | x | x | ||||||||
Luxembourg | x | x | x | x | x | x | x | x | x | x | ||||
Netherlands | x | x | x | x | x | x | x | |||||||
Norway | x | x | x | x | x | x | x | x | ||||||
Lithuania | x | x | x | x | x | |||||||||
Exceptional in this regard is cross-border data transfer between Nordic countries based on population registry and connected to migration data. There are procedures where a new address in a new member state of the person moving out from a country is listed automatically to the population registry of the country person migrated from.
2.3 A state of play of processes and solutions for identity and record matching in the EU/EEA.
The development of a European digital identity is not new. The 2014 eIDAS regulation has set standards for digital identification methods across the European Union (EU) for citizens and legal persons. The goal of this regulation is to strengthen the European Single Market by promoting confidence and convenience in cross-border electronic transactions. These benefits have not come to fruition as initially planned: since the regulation came into effect in September 2018, only 59% of the EU population (living in 14 Member States) can use an electronic national identity document cross border. To achieve the eIDAS’ goals, the Commission has proposed an amendment of the regulation (eIDAS 2.0) which mandates a European Digital Identity Wallet (EUDI-Wallet). This is a nationally provided mobile application with which each EU citizen can identify themselves at every public institution in the EU, as well as at private parties which rely on unique identification for the provision of their services.
European Commission art. 12b, 2021
To assess the potential cross-border usage for public services, different proxies can be used. According to Eurostat, in 2019, less than 4% of EU citizens of working age were residents of another EU Member State than where they hold their citizenship. In principle, they should be able to use one eID to access public services in both Member States. In addition, there are online public services where user authentication is needed and that can be used by e.g., tourists (about 30% of EU population travel yearly to another Member State) such as buying tickets for public transport, museums or subscribing to bike rentals.
To assess the overall potential of eID use, we can rely on existing use as proxies. Available data from some Member States (e.g., NO, SE, EE, LV, LT), where user authentication solutions are widely re-used by different service providers, authenticating oneself with a legal identity is done roughly around 20 times per month, of which 1 occurs in the public sector. If that relationship is extrapolated to the EU level, we can assume the potential for EU to be roughly 100 billion user authentications per year of which 5 billion in the public sector. Based on these assumptions, for example, if we expect 3% of people living in another Member State to only use eIDAS in the current scope, the potential of eIDAS authentications in this case would be 150 million per year.
Regarding the articulation of relationships between eIDAS and private sector service providers, these are expected to remain suboptimal. Even if all notifying Member States potentially open their eIDAS nodes to the private sector services providers across the Union, the diversity of national conditions for the use of the national eID infrastructures will still make it very difficult for the service providers to build a sustainable business plan or to accurately estimate the potential of this openness to expand their business cross-border. Besides, private sector service providers have made available cross-border usage of eIDs and digital signatures through gateways like Signicat, Dokobit, TrustLynx amongst many other companies. Moreover, given the difficulty raised by the constraint to harmonize the various approaches followed at national level, a revenues model and establishing clear liability rules would be difficult to construct.
2.3.1 Processes and best practices for identity and record matching in EU/EEA countries
After the desk research of identity matching best practices in EEA countries,
Interviews revealed three main phases of the identity and record matching process which are used to structure the interview summaries (below) of the referred five countries. Those three phases are: providing identity; identity matching; and data sharing and record matching.
Those phases were refined during further analysis and merged process (see Ch.2.3.3) is described also by three-part, but somewhat different division (identity matching; e-service usage; and record matching). However, high level process descriptions of interviewed countries consist of five steps for providing more details.
Germany (DE, not interviewed)
The German eID is based on government-issued chip cards (eID cards) using certified chips and strong cryptographic protocols. The following types of eID cards are currently part of the scheme:
- German identity cards (Personalausweis) issued to German nationals living in Germany or abroad,
- German resident permits (Aufenthaltstitel) issued to non-EU nationals living in Germany, and
- German eID card for Union citizens (Unionsbürgerkarte) issued to citizens of the European Union and nationals of the European Economic Area.German_eID_Whitepaper
Due to the nature of the German eID system that operates without a central component, the German eID scheme is integrated into the eIDAS Interoperability Framework via the middleware integration model in accordance with the eIDAS technical specifications.
German_eID_Whitepaper
Public-sector bodies of other Member States of the European Union are authorized to request person identification data from the German eID of a user. For this purpose, Germany will provide an authorization certificate to each Member State free of charge. Identification and the initial registration at a commissioned authorization CA will be performed via the Point of Single Contact according to a dedicated procedure. After initial registration, the German eIDAS middleware automatically updates the authorization certificates. Provisioning of authorization certificates also includes the necessary eID revocation lists.
German_eID_Whitepaper
Poland (PL, not interviewed)
Currently there is no specific solution in place in Poland to enable universal cross-border identity matching.
For foreigners who live in the Poland there is a possibility to apply for a Polish identifier (a PESEL number regulated by the Act of 24 September 2010 on the Population Register) and one of the national notified eID means – trusted profile (pl. profil zaufany). Having a PESEL number and a trusted profile opens access to all Polish public digital services. Moreover, Poland allows access to certain public digital services for holders of notified eID means from other Member States through the biznes.gov.pl domain.
Malta (MT, not interviewed)
Identity Malta Agency, being Malta’s identity management national authority has successfully pre-notified the Maltese scheme of the Maltese eID card and e-Residence documents and has been confirmed as achieving level of assurance “high” in line with the e-IDAS Regulation. In Malta the e-IDAS Node permits Maltese citizens to use digital public services of other EU MS and gives European citizens access to the digital services of the Maltese government. It provides for a reliable authentication mechanism and allows for the mutual recognition of national electronic identification schemes. The technical infrastructure is operated by MITA, being the public entity vested with the responsibility to provide ICT infrastructures, systems, and services to the Government of Malta.
Spain (ES, interviewed)
The Spanish national identity card, known as the Documento Nacional de Identidad (DNI) or carnet de identidad, contains the following information:
- Last names (all Spanish citizens are required to have two last names)
- First name
- Gender
- Nationality
- Date of birth
- Serial number, which includes a security feature, expiry date, and signature of the cardholder
- Photo of the cardholder, in black and white and a bigger size than all the previous cards
- DNI number and security letter under the photograph
The Spanish ID card has evolved over time, and the current version is an electronic identity card with unique features.
Providing identifier
The DNI is issued by the National Police and is mandatory for Spanish citizens (fourteen years or older). The same identity number (identifier) is also used for tax purposes, receiving the name of Número de identificación fiscal (NIF)
- For individuals: The NIF for individuals is the same code as their identity document. For Spanish citizens, it will be the DNI (Documento Nacional de Identidad), which consists of 8 digits and one letter for security. The letter is found by taking all 8 digits as a number and dividing it by 23. The remainder of this digit, which is between 0 and 22, gives the letter used for security. The letters I, Ñ, O, U are not used. The letters I and O are omitted to avoid confusion with the numbers 0 and 1, while the Ñ is absent to avoid confusion with the letter N.
- For foreigners residing in Spain, the NIF will be the NIE (Número de Identificación de Extranjero), which is 9 characters in the format A-NNNNNNNA, where the first character is either X, Y or Z and the last character is a checksum letter.
- For legal entities: The NIF format for legal entities consists of a letter that will depend on the legal form it has, 7 digits, and the control code that can be a letter or a number.
Foreigners legally residing in Spain or who intend to purchase property are issued with a Número de Identificación de extranjero (NIE) or Foreign Identification Number
- If they are nationals of other Member States, they use their own national identity card to prove their personal identity (e.g., a French CIE) but they use their NIE as identifier for any relationship in Spain.
- If they are nationals of third countries, they get issued a Tarjeta de Identidad de Extranjero (TIE) or Foreigner Identity Card,
containing the NIE identifier, which they use to prove their personal identity. The NIE is also used for tax purposes.
The Foreigner Identity Card (TIE) which is issued to foreigners authorized to stay in Spain for more than six months
Full list of services is available in the Annex II of SDGR: https://eur-lex.europa.eu/TodayOJ/
- The card contains the individual's information, name, surname, period of validity, and a unique number known as the Foreigner Identity Number (NIE)
- The NIE is a personal unique number given to every foreigner who intends to stay in Spain longer than six months and appears on all documents of the foreigner processed and issued in Spain, including the Foreigner Identity Card
- The identity and record matching system in Spain is done to increase the success rate of identity and record matching done on the side of the Online Procedure Portal
There are several digital options available in Spain for applying for a personal ID or using public services:
- Spanish Digital ID: Spanish citizens and non-Spanish legal residents can apply for a digital ID online, register with the system using a DNIe or previously installed FNMT (Fábrica Nacional de Moneda y Timbre) digital certificate, or apply for a digital certificate from the National Currency and Stamp Manufacturer (Fábrica Nacional de Moneda y Timbre)
- Digital Certificate: A digital certificate is needed to verify a person’s identity online and formalize any legal process effectively. It can be obtained by any Spanish or foreign citizen over 18 years old who holds a DNI, NIE, or NIF, from the Sede Electrónica website. The certificate can be used to sign and prove identity safely online and allows the holder to do online procedures with the Spanish Public Administration, such as paying taxes, applying for certificates from the Civil Registry, or applying for the Spanish Criminal Record Certificate.
It is also needed not only to register as self-employed (Autónomo), but also to register documents when person is applying for TIE, making tax declarations, and joining the Social Security system, among other things
Identity matching
To obtain a digital certificate, an applicant needs to fill in personal information such as NIE, first surname, and email address. The process may require video identification and may cost a fee.
Not all municipalities are digitally approachable for using services. That depends on the size of municipality and the regional governments support to the digital services.
- In smaller municipalities (up to approximately 50 000 inhabitants) mostly or only data sharing “on paper” is in use.
- Larger municipalities (starting from approximately 50 000 inhabitants) also provide digital services for persons who have national identity (personal code and digital certificates).
For several years there has been an active push from the government to use electronic id. E.g., regarding taxes and any introduction to public services eID is a main key in terms of public services (see Figure 2).
- The TIE application process requires the submission of various documents, including proof of identity and capacity, and foreign documents must be legalized or apostilled and, where applicable, must be submitted together with an official translation into Spanish
- The student must apply for a Foreigner Identity Card within a period of one month from their entry into Spain, at the Foreign Nationals' Office or the Police.
Figure 2 High level process of Identity and record matching in Spain
Data sharing and record matching
Already identified users (with valid TIE) can connect either by national or eIDAS identifier. When connecting digitally, a respective choice will be presented to the person to use national or eIDAS identifier.
- Today it is possible to recognize EU Member States identifier as well as save it and use it for identity.
- Earlier data about the past of a foreigner cannot be matched.
- If a person is from the EU, then eIDAS identifier can be used for identity matching.
- France and Portugal create the most of identity matching cases. Both citizens can use their national electronical ID
- If a person is not for the EU, then a PIN based account can be made.
National ID has to the be Spanish identifier for most local services, but there are some sectoral exceptions and issues regarding (see Table 5):
- services meant only for residents: to use those one must have Spanish national ID. For the rest of the services also other countries national ID can be presented.
- banking: privacy focused now, so when person is asking credit from bank in Spain, then only identity is not enough, but person can decide, what data to present. Still the bank can refuse to serve if the data are not enough.
- education: When person needs to get in contract with university the problem raises when there is need to provide current degree from abroad – the documentation must be translated to Spanish and proofed by certified authority. Older diplomas from years ago are not digitized. In EU degrees from resent years are in digital database and most EU universities can share their records (degrees). (see Ch 2.2.1).
- Matching issues remain in regards of name changes or with people from third countries. For those people a new sectoral identity must be created, and data connection made to an earlier degree.
- No automatic connection between a person’ s new and former sectoral ID-s are made.
Table 5 Spain – identity and record matching related issues
Regarding | Description of the issue | Solved how? | IF not 100% solved, then why? |
Process | Smaller municipalities are not providing digital services | Government policy and nudging towards digital services | Depends on decision and available funds of every municipality |
Subject | Sectoral ID-s are causing multiple identities | Manual connections are made between data and identities | - |
Object | eIDAS – number of credentials is too limited for the Spanish national ID | Creating national Identifier for the person (duplicated identity) | - |
Regulation | eIDAS data set limits set by regulation | - | Not under control of single Member State |
Relying Parties | - | - | - |
Technology | - | - | - |
Infrastructure | - | - | - |
EU | - | - | - |
Compiled according to the interview with the representative of University of Murcia (expert of security and identity related topics)
Summary of differences in the process of obtaining a digital certificate for foreigners (for use in Spain):
- Foreigners need to obtain a Foreigner's Identity Number (NIE) before applying for a digital certificate. The NIE is a unique identification number assigned to foreigners in Spain, and it is required for all financial and administrative matters.
- Foreigners can apply for a digital certificate online through the Sede Electrónica website, just like Spanish citizens. However, the application process may require additional documentation, such as a copy of the applicant's passport and a copy of their NIE.
- Foreigners may need to provide proof of their legal status in Spain, such as a residency certificate or a work permit, to obtain a digital certificate.
- The process of video identification may be different for foreigners, depending on their legal status in Spain. For example, non-residents may need to provide additional documentation to complete the video identification process.
- To summarise, while the process of obtaining a digital certificate is similar for Spanish citizens and foreigners, foreigners may need to provide additional documentation and proof of their legal status in Spain.
Luxembourg (LU, interviewed)
In Luxembourg, identity matching of citizens relies on a persistent national identification number, as foreseen by the law of 19th June 2013 on identification of natural persons.
Providing identifier
Foreign citizens can obtain a LU national identification number via various registration processes, including fully online if they own an eID means notified under eIDAS. When a person from abroad requests for LU national ID, an eIDAS identification is used today. To support the process, the original minimum dataset required for LU national ID was changed, as previously gender was asked, but e.g., Germany doesn’t provide this attribute. That means using only eIDAS minimum dataset today (see Table 6).
The Luxembourg national identification number has a different format for natural and non-natural persons.
- For non-natural persons, the identifier has 11 digits, and the last digit is a check digit.
- For natural persons the national identification number for natural persons has 13 digits
. The digits in the national identification number represent the following data: - RRRRRR: Birth date of the person in the format YYMMDD
- SSS: Serial number assigned by the National Registry of Natural Persons
- C: Check digit
To evidence the information required for the creation of the national identification number, the natural person should provide the following information: names, surname, date, place, and country of birth, gender, nationality, and private address.
Table 6 Luxembourg – identity and record matching related issues
Regarding | Description of the issue | Solved how? | not solved why? |
Process | Sector specific approach to datasets and sharing principals | Some data are shared “on paper”, which means not shared digitally. | No standardized approach agreed in state, sector specific processes |
Subject | Citizen from abroad can have multiple eID’s from same country or different country. | Manually associating the various eIDs with a single LU identity (i.e., the one in LU national population register). National population register calling the person, requesting documents, checking, and then merging data. | - |
Object | Legislation prohibits to share national ID number with parties abroad | Derived unique identifier based on LU national ID number, created by algorithm, by country and by relying party. The same code is used also in the future and tied: unique person eID = requesting country + requesting organization | National regulations |
Regulation | ID number cannot be saved by private sector (with some exception, e.g., healthcare) | Person can choose what to share by giving an official consent | National regulations |
Relying Parties | Largely sector specific processes | - | Every sector and organization are deciding their solution. Private sector cannot store national ID number, with a few exceptions which are all enumerated in a national law |
Technology | - | - | - |
Infrastructure | - | - | - |
EU | Pinpointing false positive or negative matching cases | - | eIDAS minimum dataset |
Identity matching
Matching and providing of services is based on national identifier – 1 identifier per natural person. When asking for service, one must provide the national ID, which is a primary key to access all the information in various databases.
- Person can apply for national ID via web page
by providing minimal set of data. If additional data is required, the consent will be asked, and applicant can decide whether to share more data or not. All additional checks (points 1,2,3 below) are done separately and manually by agents of the National Population Register service, outside of the online eIDAS-based registration. - Identity document and facial biometry matching,
describes how the document should look like), the same information about ID documents from outside EU is also available. - Electronic security – chip with signed data from member state, mobile app is used for that.
- Question of document validity – many public sector institutions have no access to the SLTD database to check is this document stolen for example? In case of doubt the authorities of issuing MS will be contacted.
- Business owner is connected to the company, that must be registered in Luxembourg. EU network business register BRIS
links all the business registers data from all MS’s.
Figure 3 High level process of Identity and record matching in Luxembourg
Data sharing and record matching
Every person with LU national ID can have a personal digital space provided by LU on the national citizen portal (MyGuichet.lu)– where the person can use different services. This service is available to everyone with a national identifier, but a person must request its creation. There are some issues (Table 6):
- Citizens can have multiple eID from the same country or different countries, as well as different names for some cases. Unique identifiers provided by various eID means of single person are not matching, so different identities must be manually associated. For this association the National Population Register will call the person, requesting documents, checking, and then merging data.
- Private and public sector service providers options are quite different.
- In the public sector all sector-specific processes rely on the national identification number. And public administrations supporting these processes have access to the central national population register.
- But national ID numbers cannot be stored by the private sector, therefore they must use another way to identify the person.
- On education field depends on University, but mainly the data should be provided “on paper”. Some Universities in certain networks can exchange data directly.
- Medical sector – patient history from abroad is shared mainly “on paper.”
- Financial sector - some banks are online, some have digitalized part of their bank account opening process, some are still operating with data sharing “on paper”.
When interacting with LU public entities, citizens provide their identification number for identity matching. Alternatively, they may use their notified eID means and authenticate via eIDAS, since their eID means has been associated with their national identification number during registration.
Netherlands (NL, interviewed)
In the Netherlands, online unique identification in the public sector is often established by comparing a citizen’s Citizen Service Number (CSN) to a record of that citizen at a public RP
Relying Parties
Providing identifier
Dutch CSN is a unique number of 9 digits, including check digit; that contains no personal data.
Besides the CSN, the following four unique and persistent identifiers are used in the Dutch eIDAS identity matching process of foreign eID means (Nora, 2017; Verheul, 2019).
- eIDAS identifier: the identifier which is used in the eIDAS minimum data set (PID). For each MS, the identifier is formatted as: [home_MS/destination_MS/ID (e.g., GE/NL/1234AB)
- PP-EU: a polymorphic pseudonym which is derived from the eIDAS identifier. This identifier is used for Dutch RPs in the private sector.
- PP-BSN: a polymorphic pseudonym which is derived from the BSN. Every eID mean a citizen uses receives a different PP-BSN. The BSN is only derivable from the PPBSN by Dutch RPs which have a decryption key. This key is only given to authorized RPs.
- PP-RP: a pseudonym specifically for each Dutch RPs. It is a pseudonym of the former two identifiers (the PP-EU, PP-BSN), constructed by encrypting this identifier with the public key of the RP. Therefore, only the authorized Dutch RP can derive the decrypted identifier. A RP does not have access to the PP-EU, PP-BSN, and PP-PS: they are only for internal communication between the Dutch eIDAS Connector and the BSN Connector.
Identity matching
Focus on identity matching is to avoid false positive matches first and only after those false negative ones. Matching is done starting with surname and date of birth (age). In case of one positive match, additional ID document data are asked, if these are not shared then last 3 digits of CSN is provided and confirmation is asked from the person. If more than one match is found in the database, then the matching is forwarded immediately to the manual process (back office). More attributes will be asked from the country of origin and the person must give consent for that. If still in doubt, then identity match won’t be done to avoid false positive and possible frauds caused by it. (see Figure 4)
Figure 4 High level process of Identity and record matching in Netherlands
Matching itself is not a problem, the data are – e.g., people already with multiple identities in other countries and in addition there are problems with old identity documents. The more identity related data is gathered through time, the better the matching will be.
A person with no eID code must come to the physical location and present ID (paper documents, ID card) Local ID document is linked to the name, date of birth, gender, nationality, and home address. For people from abroad the main identity matching attributes are birth date and family name. In case of doubt the data of parents are requested, but sharing these is not obligatory. Still, when refused to share this information, and if it leaves doubt of person’s original identity (from abroad), this can end up with refusal to provide CSN. (see the list of issues at Table 7)
It is possible to connect identities manually. This option was created because of 2 main reasons:
- Differences in spelling of names in different languages (e.g., prefix De’: In Netherland it is separated, in Belgium it is concatenated into one name)
- Very common names witch even together with birth date can give more than 1 positive hits from database. (e.g., German surname with a very common name in Netherlands can give up to 10 hits with the same birth date).
On the other hand, it creates another problem, where connections could be made recklessly. To prevent that from happening the procedure allows only 2 people to connect identities, and related logs are stored.
Data sharing and record matching
In the Netherlands, all public organizations working with personal data use the Citizen’s Service Number to identify people and to communicate between public organizations. Without this CSN it is not possible to access most of the public services of more than 1000 government institutions.
Table 7 Netherlands – identity and record matching related issues
Regarding | Description of the issue | Solved how? | If not 100% solved, then why? |
Process | Person who doesn’t have CSN code, must come to the office and present data | From abroad people can connect via eIDAS and can use eIDAS identifier. | Still physical presence is required for identity matching |
Subject | False negative matches can happen because of the spelling differences between languages | The name details (letter combinations like name prefixes etc.) are coded to match language specific changes in the surname | Focus is on avoiding false positive matches. |
Object | More than one positive hits from database | In case of 2 positive hits person is asked to confirm last 3 digits of CSN (yes/no) Manual connection of identities is possible | If still in doubt, then the connection of identities will not be done (to avoid false positive and possible frauds) |
Regulation | In case of doubt in >1 positive hits legislation prevents from demanding additional data. Either new identity should be provided, or identity connection made. | Person is asked to share data voluntarily | Person can refuse sharing additional data and public services must be provided still but under new identity |
Relying Parties | Most public service providers have their own systems established | One central database with all the persons, accessible to all service providers | - |
Technology | - | - | - |
Infrastructure | - | - | - |
EU | - | - | - |
Compiled according to the interview with the representative of the National Office for Identity Data (Ministry of the Interior and Kingdom Relations)
Incoming eIDAS-traffic comes with a Unique ID and attributes (name, surname, date of birth). Service will be provided if the attributes can be matched to a registered identity.
Norway (NO, interviewed)
Providing identifier
The identification process requirements when applying for identification documents depends on an individual's citizenship and the basis for their residence permit in Norway
- Nordic citizen: Norway, Sweden, Iceland, Finland, Denmark, the Faroe Islands or Greenland
- Passport or national ID card with a photograph of the person and information about the person’s citizenship and gender is required. When moving to Norway from another Nordic country, a valid driving license will also be accepted, together with a printout from the national population register of the country one is moving from, with information about citizenship and gender. The printout must be dated and no older than three months. It must also be signed and stamped.
- Children under the age of 18 may use their birth certificate/printed confirmation of their birth registration from the National Population Register in a Nordic country together with a passport photo and a printout from their home country’s national population register that shows their citizenship and gender. The printout must be no older than three months. It must also be signed and stamped.
- EU/EEA/EFTA citizens: Passport or national ID card with a photograph and information about citizenship and gender.
- There are some exemptions for some groups, like asylum seekers, refugees, persons who are unable to get a passport from their home country, and others.
The Anti-Money Laundering (AML) legislation requires that customers provide valid proof of identity when entering a customer relationship. Valid proof of identity includes Norwegian and foreign passports, Norwegian national ID cards, Norwegian driving licenses, Norwegian bank cards with photographs, national ID cards issued by an EEA country, Norwegian immigrant's passport, Norwegian refugee travel document, and electronic proof of identity in accordance with the AML Regulations.
For permanent ID any person should have a permit for residency – this can be acquired by presenting a passport (ID document).
- To apply for work, permit also sending documents is accepted today, but the quality of this method is questionable and will most probably be discontinued. Physically appearing to receive the work permit the office.
- Enrolment for ID cannot be done digitally today. It is under decision whether to issue national identity card for foreigners, but still, physical appearance is required to receive the ID document.
All together three kinds of identifiers can be defined regarding Norway:
- Personal unique identifier, restricted by population register legislation, prevents changes of attributes, as every change requires change in the legislation.
- Internal identifier – sectoral numbers (like in taxation or health care)
- Third identifier is under consideration – which would be more flexible in regards of Norway legislation and would allow additional attributes and change of some data (like address and similar).
A national identity number consists of eleven digits
- Date of birth: In most cases, the date of birth is the first six digits. For example, if person is born on 22 June 1976, the first six digits in your national identity number are 220676.
- Individual number: The next three digits are individual numbers, where the third digit refers to the holder’s gender: even numbers for women and odd numbers for men.
- Verification number: The two last digits are for verification.
- The last five digits in the national identity number can be referred to as a “personal number”.
- In some cases, the first six digits are not the date of birth – in case there are no available national identity numbers for some dates. Then, the first six digits will show the day and month on which person received your national identity number instead. The correct date of birth will still be recorded in the National Population Register in the field for date of birth.
Changing information regarding one’s identity is possible: person can apply to change their registered information regarding place of birth, country of birth, citizenship, and date of birth through the Norwegian Tax Administration.
Identity matching
All foreigners working onshore in Norway are required to meet at a tax office for an ID control to verify their identity.
Data sharing “on paper” is only under discussion if a person cannot be identified with regular processes. Norway focuses first on avoiding frauds with multiple identities – so priority is to avoid false negative matches and right after those false positives. (see also Figure 5)
The status of person’s identity basis can be either checked or not checked
Figure 5 High level process of Identity and record matching in Norway
Biometric data are considered sensitive and not used for eID. It is considered using web apps for digital biometric enrolment, but not explored much so far. Central passports register stores photos and fingerprints, and these data can be checked, to make sure that no duplicate identities are created. However, double identities cannot be completely ruled out since one-to-many queries are not allowed with biometrics. Biometrics can only be used for a 1:1 comparison, to make sure that the person is who he/she claims to be. This process is under the control of the police. Current legislation does not comply with the identity matching solutions connected to biometric data. Uniqueness and quality of personal identity decreases, therefore. (see the list of issues at Table 8)
Data sharing and record matching
The population register is very high quality, and it is very often used as a comparison for other systems, which means that national identity number is used very widely. If people from abroad cannot be connected to the registered ID number, it is not possible to use public services. There are some exceptions – e.g., applying to university or paying taxes, for that internal identifiers are used. Health care also handles foreign patients – who don’t get Norwegian identifiers, and very limited range of digital services are accessible for them. In corona pandemic situation those internal identifiers were temporarily used as a person’s identifier in Norway, but this system was not extended.
Table 8 Norway – identity and record matching related issues
Regarding | Description of the issue | Solved how? | If not 100% solved, then why? |
Subject | If persons from abroad cannot be connected to the registered ID number, it is not possible to use public services. | Sectoral internal identifiers are used. In corona pandemic situation those internal identifiers were temporarily used as a person’s identifier in Norway, but this system was not extended. | There are some exceptions – e.g., applying to university, paying taxes or receiving critical health care. |
Object | People have a long history and rights for services (like pensions). They come with a minimum data set from abroad or with a passport. And data quality differs a lot therefore. | A person is asked to share additional data and documents to find a match. Status of identity check is available to public and private enterprises that use the National Population Register. | Inflexibility in population register and rigorous government systems connected to that register. |
Regulation | Personal unique identifier related regulation prevents changes of attributes | Third identifier is under consideration – which would be more flexible in regards of Norway legislation and would allow additional attributes and change of some data. | Restricted by Population Register legislation and therefore every change requires change in the legislation. |
Relying Parties | Data is not shared between countries flexibly. | Physically appearing to present data and or receive work permit or ID document. | Variations of legislation of population registers in different countries. |
Technology | - | - | - |
Infrastructure | - | - | - |
Cultural | People are not ready to consider possibility to use EU unified identifiers. | - | - |
EU | In some cases, it is not possible to find a user in the eIDAS register, even if the person is registered. | - | eIDAS mandates sharing information but does not mandate access to services. |
Compiled according to the interview with the representative of The Directorate of Digitalisation
Estonia (EE, interviewed)
Estonia has personal identification code and ID documents as many other countries, that allow foreigners to deal with their personal or business matters.
Providing identifier
All Estonians, no matter where they happen to reside, have a state-issued digital identity. This electronic identity system, called eID, has existed since year 2002 and is the cornerstone of the country’s e-state. e-ID and the ecosystem around it is part of any citizen’s daily transactions in the public and private sectors. All Estonian eID tools operate primarily on the Estonian personal identification code for identification. People use their e-IDs to pay bills, vote online, sign contracts, shop, access their health information, and much more.
ID-card is mandatory for every Estonian citizen and residence card is mandatory for all residents living in Estonia. Estonians can use their e-ID via state-issued ID-card, using Mobile-ID, which can be used on any mobile device with SMS functionality, or Smart ID app on their smartphones. Holders of a digital identity need not be Estonian residents anymore, however.
Since 2014, an e-residency of Estonia (also called virtual residency or E-residency) concept was implemented for anyone who wishes to become an e-resident of Estonia and access its diverse digital services, regardless of citizenship or location. Behind that is an aim to make it easier for foreigners to access Estonian business environment remotely and thereby attract location-independent entrepreneurs such as software developers.
E-Residency of Estonia is a program that enables creating a borderless digital society for global citizens. The program provides holders of e-Residency with a transnational digital identity (e-Resident’s digital ID) that allows to securely authenticate non-Estonians in Estonian online services, such as company formation, banking, payment processing, and taxation and sign documents.
A personal identification code is a number formed based on the gender and date of birth of a person which allows the specific identification of the person.
- the EVS 585:2007 standard “Personal identification code. Structure”
- the Population Register Act
- and the regulation by the Minister of the Interior which regulates the formation, distribution and granting of personal identification codes.
Personal identification code consists of 11 digits, the first of which shows the gender of a person as well as the century of birth, and the next six show his or her date of birth. The following three digits are sequential numbers for children born on the same day and the last is a control number which is calculated according to a special formula.
The personal identification code is provided during the registration of family events, but it is not provided based on family relationships (for example, a personal identification code is given to a child born abroad to an Estonian citizen, but not to their foreign parent who has no other connection to Estonia).
In the case of residing in Estonia, it doesn't matter whether it is temporary or permanent residency. If a person obtains the right of residence or a residence permit for living in Estonia, they will also receive a personal identification code. However, a personal identification code is not provided to foreign nationals staying in Estonia based on a long-term (e.g., one-year) visa.
- If an individual stays in Estonia temporarily; for example, lives in Latvia but works in Estonia, he or she may apply for a personal identification code in the nearest local government of the county centre in person. If an individual cannot apply in Estonia, he or she can do so in an Estonian foreign mission in a foreign state.
- Citizens of the European Union can submit their application for a personal identification code to the local government agency together with their notice of residence.
Foreigners can apply for e-Residency in Estonia, according to these steps (During this process, the person will be assigned an Estonian personal identification code):
- Check eligibility: Foreigners who want to apply for e-Residency in Estonia must ensure that they have a clear understanding of the reason they are applying for e-Residency
- Apply for an e-Residency digital ID: Foreigners can apply for an e-Residency digital ID, which provides access to Estonia's business environment, by applying to the Estonian Police and Border Guard Board (PBGB).
- Submit identification documents: The identification documents accepted by the PBGB are passports or European Union identity cards
- During the application process, applicants will need to provide their CV, motivation statement, copy of their travel document/ID, and passport-style digital photo
- Pay the application fee: Applicants need to pay the application fee using VISA or Mastercard
- Wait for approval and card delivery: The Estonian Police and Border Guard Board will review the application and conduct a background check. Applicants may be asked additional questions for clarification purposes. Once the processing of the application is complete, the applicant will be notified by email. After the application is approved, the unique card is printed and delivered to the chosen pickup location.
- Collect the e-Residency digital ID: Applicants can collect their e-Residency digital IDs at the PBGB service office indicated in the application or at an Estonian embassy. That means applicants need to cover also travel costs to get to the pickup location.
Granting a personal identification code does not grant the right to stay, live or work in Estonia – these rights must proceed from other bases prescribed by law. A personal identification code shall be granted to a person after they are entered in the Population Register.
In any case, once the personal identity code (identity) is created in the Population Register, it will be stored there forever and never will be archived. Therefore, in time, different status is added to the identity, depending on the status of the person (e.g., “living” or “deceased”). Every service provider can decide themselves which identity statuses are acceptable for providing their services.
Identity matching
Foreigners who apply for a personal ID number in Estonia, which is different from e-residency, go through an identity matching process (see Figure 6):
- Application: The applicant must apply for a personal ID number to the Estonian government
- Verification of identity: The applicant must provide proof of identity, such as a passport or national ID card, to verify their identity.
- False positives are prevented, as possibly duplicated identities are not automatically merged, but will be manually validatedThis is done by officials who, based on experience, send queries with different datasets to various databases, to find possible previous EE identities.
- Issuance of personal ID number: If the applicant passes the verification (population register) the Estonian government issues them a personal ID number.
Foreigners who wish to obtain an Estonian identity document and/or e-residency must also go through identity matching process (Refer to Step 2 in previous list and Figure 6).
- Once the identity matching process is complete, foreigners can use their e-Residency digital ID to access Estonian public e-services, declare Estonian taxes online, and more.
Figure 6 High level process of Identity and record matching in Estonia
With an Estonian citizen who has a valid ID document, everything is simple and clear. If a foreigner applies to a municipality for example in connection with the registration of a place of residence, a simple search will be carried out on applicant in the Population Register in different combinations (if necessary, the surname will also be excluded from the search if it has been changed). The problem may arise if the search is not carried out with sufficient thoroughness, because if a match is not found, then the local government will create a new identity. Later, when duplications are detected, the Population Register connects the identities manually.
Digitally, identity cannot be matched with eIDAS now. Estonian e-services operate mainly based on an Estonian personal identification code, and today there is no e-service solution that could issue an Estonian personal identification code to the user of the eIDAS eID tool (incl. the identifier provided therein).
Population Register can also add the foreign personal identification code to the identity data and these data are collected whenever possible. It is still entered in the free text field since the actual quality of the foreign personal identification code obtained is not known. However, this information has legal significance, as does any other information entered.
Data sharing and record matching
Once the e-Residency digital ID is collected, foreigners can use it to access Estonian public e-services, declare Estonian taxes online, and more as described earlier.
In this regard, a distinction must be made between two types of IDs. Personal identification code, which is used for entry into the state's data system, and database-based unique identifier (UID), used to identify and link a person's data solely within a specific database. In the latter case, the document will not be issued, only the code. This code is used for example when the employer needs to formalize the person's employment in the Workers' Register. As this employee will never come to Estonia, he/she does not need an Estonian identity document.
There are extremely few people who do not have a personal identification code in Estonia and who at the same time receive any service.
Table 9 Estonia – identity and record matching related issues
Regarding | Description of the issue | Solved how? | If not 100% solved, then why? |
Subject | - | - | - |
Object | Digital association with eIDAS is not possible yet | - | - |
Regulation | For personal ID an applicant must choose gender on a dual scale (female/male) | There are ongoing discussions how to build multiple scale for describing gender | The gender is built in the personal ID code and cannot be excluded. |
Relying Parties | Quality of background check depends quite often on the experience of the person conducting search | In most cases the process brings the identity matching to the most experienced party (SMIT) and the duplication will be discovered | - |
Technology | - | - | - |
Infrastructure | - | - | - |
Cultural | - | - | - |
EU | - | - | - |
Compiled according to the interview with the representative of The Estonian population register.
Data exchange works in Estonia with Finland, Latvia, and Lithuania, whereas Finland does not share personal identification code, which means manual work for the Estonian side. The information exchange takes place regarding Estonian citizens, in connection with the registration of residence and (in the Baltics) also regarding family events (birth, death, marriage, divorce, etc.). In the case of other persons, there will be a one-time flow of data in the future, where, for example, if a Russian citizen with an Estonian residence permit moves from Estonia to Finland, a one-time set of data will come to Estonia about the fact that the person arrived in Finland.
2.3.2 Summary of Issues and best practices
Interviews of representatives of five countries (Spain ES, Luxembourg LU, Netherlands NE, Norway NO, Estonia EE – see Ch. 2.3.1) revealed some issues which have an influence on the process and its information exchange. During the analysis different countries were analysed from different aspects (see Table 18 in Ch. 4.5) and therefore issues and difficulties are described from two different angles: related to processes (here in Ch. 2.3) and related to structural challenges (see Ch. 2.4).
All those countries share a common issue, that at least one physical contact is required at some point in the process of enrolment for local ID, which means that at least once a person must come to the issuing authority for the identity matching.
Quite common is also treating the personal ID number as sensitive personal data, which cannot be easily stored or shared by service providers, therefore. That is an issue as historic secrecy has led to processes when knowledge of this code is considered proof of identity and most of the personal ID numbers viewed include semantic information that for privacy reasons persons may choose to rather not share. Also, it can be an issue in the countries where ID number can be easily used to make financial commitments, leading to frauds.
When it comes to using public services with acquired local ID, it can happen that not all municipalities offer digital services and there are lots of private sector specific processes, that are not connected to national ID and are often not digitalized.
These are all important obstacles to overcome when planning flexible and comprehensive cross border identity and record matching solution. To sum up issues, all the countries face the possibilities of both positive false matches (accidentally connecting different people’s identities) and negative false matches (not connecting the same person’s different identities).
To overcome those issues, different strategies as best practices are used by countries, like:
- one central database of all identities (including small amount of available information of foreign identities connected to the local ones),
- video identification,
- central passports register stores photo and fingerprints, which can be checked, to make sure that no duplicate identities are created,
- manual supervision over connecting duplicated identities (same person with more than one matches from the database),
- name details are coded to match language specific changes in the surname,
- infinite shelf life of ID number (= identity) with added status (like “living” or “deceased”),
- and using digital signature together with ID number for making any commitments.
Following Table 10 covers common and country related issues and best practices.
Table 10 Identity and record matching best practices and issues across EU/EEA countries.
Icons in table: “+” best practice solution for process related issue; “-“reason behind unsolved process related issue.
Icons in table: “+” best practice solution for process related issue; “-“reason behind unsolved process related issue.
Member state (interviewed) | Providing identifier | Identity matching | Sharing data to service providers | Record matching |
Common issues for many countries | - Physical contact required at some point in the process of digital enrolment for local ID. | - Citizen can have multiple eID from same country or different countries, as well as different names for some cases. | - Personal identifier considered as sensitive personal data. | - Private sector specific processes, not connected to national ID and often not digitalised. |
Spain | + There are several digital options available in Spain for applying for a personal ID or using public services. - Depending on its size, not all municipalities are digitally approachable for services. | + Video identification is possible. | - In some sectors (like degree documentation in education sector) the documentation must be translated to Spanish and proofed by certified authority. | - Sector specific processes, not connected to national ID and mostly not digitalised. |
Luxembourg | + Fully online application process available for persons owning an eID means notified under eIDAS. | + Possibility to manually connect identities. | - Private sector service providers cannot store national ID. | - Private sector specific processes, not connected to national ID and mostly not digitalised. + Education sector EU wide networks allow digital data sharing. |
Netherlands | - One central database with all identities. | + The name details (letter combinations like name prefixes etc.) are coded to match language specific changes in the surname. + Possibility to manually connect identities. | + Presenting a polymorphic pseudo-ID to abroad. | - Every service provider has access only to its own records. |
Norway | + Unique national identifier from other MS (if received) is stored in the population register. - Enrolment for ID cannot be done digitally today. | + Central passports register stores photo and fingerprints, and these data can be checked, to make sure that no duplicate identities are created. | + Status of identity check is available to public and private entities that use the National Population Register. | + In many cases today the national identifier of other countries is stored in population register, which increases hit rate significantly. |
Estonia | + Unique national identifier from other MS (if received) is stored in the population register. + Online application process is available (e-residency), still requiring one physical contact to receive the personal ID. - Digital association with eIDAS is not possible yet. | + The identity of the person, once created in database, is forever. Only its status will change in time (e.g., “deceased”). - Quality of background check depends quite often on the experience of the person conducting search. | + Personal ID code is not considered as sensitive data, as the code alone cannot be used for any services or transactions (e.g., frauds). | + Digital certificates (as signature) are used together with personal ID code (both included in e-ID) for approaching to services. |
2.3.3 Identity and record matching processes and sub-processes
As mentioned earlier, the interviews revealed three main steps in identity and record matching process: providing identifier; identity matching; and data sharing and record matching. Those phases were refined during further analysis and a new three-part division was derived, as well as following sub-processes were drawn accordingly:
- Identity matching – which includes all steps of acquiring an ID of Member State (MS).
Figure 7 Identity matching sub-process happy path
- E-service usage – that describes steps from applying for MS service by using the identity of foreign MS up to providing service.
Figure 8 E-service use sub-process happy path
- Record matching – involves steps after service providing, when service-related data are stored and matched with the identity.
Figure 9 Record matching sub-process happy path
Processes are drawn in Bizagi modeler, and BPMN notation is used. The description includes starting, intermediate and ending events, as well as tasks, related systems, and data. All processes are described as a “Process Happy Path”, which is an ideal and less complicated version of the process, where no interruptions or terminations occur.
According to interviews conducted during analysis, a merged process of identity and record matching was drawn (see Figure 10). This generalized approach was initiated by the fact that the process itself in different countries was basically the same. Only the method of some steps varied from manual to digital and the names of systems used were different. So, all the gathered knowledge of the processes in different countries are merged into one view and the steps that varied from manual to digital are highlighted in bold italic font on the process graphical notation at Figure 10. The latter is accompanied by process sequence table that describes details of every step (see Table 11). While graphical notation gives broader overview of the process, the sequence table allows to analyse steps and their relations more closely.
Sub-processes (see Figure 7, Figure 8 and Figure 9) are described without distinguishing Relying Parties, intermediate events and gateways (referred as Event and Gate at Table 11). Due to their sequence, the sub-processes are joint into one merged process (see Figure 10) by using vertical distributor for their distinguishing. Separate horizontal lanes are used for appointing main Relying Parties and service users.
Table 11 Sequence tabel of identity and record matching process.
Step | Description | Type | Belongs to sub-process of | Related system involved (first acquaintance) | Relations | Relying party* or service user | Next step |
E0 | Applying for MS (2) Identifier | Start | Identity matching | - | - | Person with MS (1) eID | 1. |
1. | Authentication | Task | Identity matching | Local e-service; eIDAS node | - | Identifier issuing MS (2) | 1.1 |
1.1 | Requesting personal data for identification | Task | Identity matching | - | - | Identifier issuing MS (2) | E1 |
E1 | Consent is given | Event | Identity matching | - | - | Person with MS (1) eID | 2. |
2. | Providing required personal data for application | Task | Identity matching | eID provider MS (1); eIDAS node | Person with MS (1) eID | 3. | |
3. | Validating personal data | Task | Identity matching | Validation related data source in MS(x) | eIDAS eID identifier/ ID document | Identifier issuing MS (2) | 4. |
4. | Initial identity matching | Task | Identity matching | Local identifier database | - | Identifier issuing MS (2) | G1 |
G1 | “Any doubts?” | Gate | Identity matching | - | - | Identifier issuing MS (2) | 4.1;4.3; G2 |
4.1 | Requesting for more attributes from country that issued ID presented by person (MS1) | Task | Identity matching | - | G1 “YES” | Identifier issuing MS (2) | 4.2 |
4.2 | Sharing or additional attributes | Task | Identity matching | Local identifier database MS (1) | - | e-service from MS(x) | 5. |
4.3 | Requesting for more data from person | Task | Identity matching | - | G1 “YES” | Identifier issuing MS (2) | 4.4 |
4.4 | Sharing additional data | Task | Identity matching | - | - | Person with MS (1) eID | 5. |
5. | Identity matching | Task | Identity matching | - | G1 “NO” | Identifier issuing MS (2) | G2 |
G2 | “Match found? | Gate | Identity matching | - | - | Identifier issuing MS (2) | |
5.1 | Creating new local identifier and connecting identities | Task | Identity matching | Local identifier database | Gate: “NO”; eIDAS eID identifier/ ID document; New local identifier | Identifier issuing MS (2) | 6. |
5.2 | Connecting provided and existing identities | Task | Identity matching | Local identifier database | Gate: “YES”; eIDAS eID identifier/ ID document; Existing local identifier | Identifier issuing MS (2) | 6. |
6. | Providing identifier (new or existing one) | Task | Identity matching | - | - | Identifier issuing MS (2) | 6.1 |
6.1 | Receiving identifier | Task | Identity matching | - | MS (2) identifier | Person with MS (1) eID | 7. |
7. | Requesting service from foreign MS | Task | e-service usage | - | MS (xx) identifier | Person with MS (1) eID | 8. |
8. | Authentication | Task | e-service usage | eIDAS node | - | e-service from MS(x) | 8.1 |
8.1 | Matching with local identifier | Task | e-service usage | Local identifier database MS(x) | - | e-service from MS(x) | 8.2 |
8.2 | Receiving service request | Task | e-service usage | Local e-service | Service request | e-service from MS(x) | G3 |
G3 | “Service specific data needed?” | Gate | e-service usage | - | - | e-service from MS(x) | E2;10. |
E2 | Request for service specific data is sent out | Event | e-service usage | - | G3 “YES” | e-service from MS(x) | G4 |
G4 | “Digital e-service channel available?” | Gate | e-service usage | - | - | Person with MS (1) eID | 8.3;8.4 |
8.3 | Providing requested data to receive service | Task | e-service usage | - | G4 “NO” | Person with MS (1) eID | 9. |
8.4 | Giving consent | Task | e-service usage | Local e-service of MS (xx) | G4 “YES” | Person with MS (1) eID | 9. |
9. | Validating dataset | Task | e-service usage | - | Additional attributes MS (xx) | e-service from MS(x) | 10. |
10. | Providing service | Task | e-service usage | - | G3 “NO” | e-service from MS(x) | 10.1 |
10.1 | Using service | Task | e-service usage | - | - | Person with MS (1) eID | 10.2;10.3; E3 |
10.2 | Providing/ creating new data | Task | Record matching | - | Personal data related to service use | Person with MS (1) eID | E4 |
E3 | End of service use | End | Record matching | - | - | Person with MS (1) eID | - |
E4 | New personal data received | Event | Record matching | - | Service records | e-service from MS(x) | 11. |
10.3 | Providing/ creating records | Task | Record matching | - | - | e-service from MS(x) | 11. |
11. | Record matching with local identity | Task | Record matching | - | - | e-service from MS(x) | 12. |
12 | Storing records | Task | Record matching | Local e-service | - | e-service from MS(x) | E5 |
E5 | End of service case | End | Record matching | - | - | e-service from MS(x) | - |
*Relying parties in this process are Identifier issuing MS (2) ; e-service from MS(x) and service user: Person using eID provided by MS(1).
Figure 10 Graphical notation of Identity and record matching process Happy Path, generalized across member states.
Based on interviews and process analysis of Spain (ES), Luxembourg (LU), Netherlands (NL), Norway (NO) and Estonia (EE).
Text in Bold Italic refers to the identity or record matching activities that are not fully digital in countries referred.
*Happy path is an ideal and less complicated version of the process, where no interruptions or (almost none) terminations occur.
Based on interviews and process analysis of Spain (ES), Luxembourg (LU), Netherlands (NL), Norway (NO) and Estonia (EE).
Text in Bold Italic refers to the identity or record matching activities that are not fully digital in countries referred.
*Happy path is an ideal and less complicated version of the process, where no interruptions or (almost none) terminations occur.
2.4 Common issues and difficulties
During the analysis different countries were analyzed from different aspects (see Table 18 in Ch. 4.5) and therefore issues and difficulties are described from two different angles: related to processes (see Ch. 2.3) and related to structural challenges (described below).
2.4.1 Description of the structural difficulties in Nordic-Baltic countries
Identity matching is difficult with the data currently available via eIDAS authentication. All the countries agree that there is no easy way to solve this issue. Most of the Nordic-Baltic countries already have the current eIDAS in use. However, it is not federated and requires additional steps to confirm authentication in cross-border situations. Identity matching of returning citizens in cross-border situations is not currently possible in most of the countries, but many of the countries are building national solutions to enable identity matching and reliable authentication, and there are authorities who already have built their own systems.
Denmark
Denmark has taken the current eIDAS in use for its own citizens with level of assurance (latvi) substantial and high. The country has an e-Identification system in which foreign users register remotely with an eID and a passport. They may also need to provide some additional attributes. Returning users can be matched, but the current method requires manual work, and, in some cases, matching is not possible. An automated process for identity matching has been available since October 2023.
The CPR number is unique to the person and is used in Denmark as an ID number. The CPR number consists of ten digits. The first six digits are date of birth (day, month, and year) while the last four digits provide a unique identification number for all citizens in Denmark. The CPR number is referred any time the person uses state-provided services. The CPR number can only be obtained on site in Denmark.
In case of identity matching, CPR number acts as a user provided attribute, which is used to start a search in the registry. The ID number was not initially considered as sensitive information, but it has been realized over time that it can be misused. Therefore, it is now personal sensitive information.
Currently, two different processes are being used for identity matching: manual and automatic. The manual process works as follows:
- Requesting a connection of CPR number and eID through DK Connect service (IdM).
- Login with national eID through eIDAS node.
- Information from national eID, self-type information and identity documents are being compared before IdM.
Figure 11 Danish manual identity matching process.
The Danish Agency for Digital Government.
The Danish Agency for Digital Government.
Challenges of the manual process:
- Troublesome for users to register in IdM solution due to the complex user journey.
- Several sites and systems connected to the solution – long journey with many clicks and redirects.
- Too many steps and the requirement of photos of ID documents.
- Processing IdM applications manually demands resources, which makes it difficult to use on a large scale.
Prerequisite: Foreign citizen must have a notified eID from another member state that is connected to the Danish gateway, as well as a Danish CPR number. If the automatic match fails, the user will be prompted to match with their Danish eID that includes a CPR number, if they have one. If the user cannot or does not want to match with their Danish eID, they will be directed to the manual application for IdM. Automatic matching is only done if the cross reference with the CPR register with date of birth, given name and family name gives one result that matches with the CPR number. If zero or more than 1 match is found, automatic IdM will not be done.
The automatic process works as follows:
- The user will provide their Danish CPR number (in addition to the automatically provided attributes from the eID).
- If the family name, given name and birthdate match with the information from the CPR-register, it will be automatically matched, and the user is redirected automatically to the self-service they were attempting to access.
- Names are concatenated and algorithms for transliteration is applied. If the eIDAS attribute for nationality is available, it is also be used for matching the datasets.
- If matching is successful, the user is redirected automatically to the self-service to be accessed.
- If step 1 of matching fails or is skipped, the user can provide their CPR number by logging in with their Danish eID, if they possess one.
- If both steps fail, they will be redirected to the manual identity matching process, where they will fill out the application.
Figure 12 Danish automatic identity matching process.
Source: The Danish Agency for Digital Government.
Source: The Danish Agency for Digital Government.
Challenges of the automatic process:
- Names are registered differently across systems and countries. E.g., cross reference between foreign eID and CPR register fails, due to middle name(s) being omitted in either.
- Accents and dialectic names (e.g., Cyrillic).
- First name and last name attributes can change.
- Common names increase risk of >1 matches.
- Few mandatory attributes to mitigate this.
According to the interviewees, one of the biggest future problems regarding identity matching will probably be the complexity of the user journey, which from the user’s perspective can lead to lower satisfaction of the services. The process can become even more complicated when new eIDAS attributes are required. Another challenge is related to resources: as processes are growing safer and more regulated, it requires more workforce to process the requests and avoid false positive and false negative matches.
Faroe Islands
The Faroe Islands is an autonomous territory within Denmark. Although most inhabitants are Danish citizens, a Faroese inhabitant does not possess a Danish national ID number (CPR number) unless the person additionally fulfils the requirements for registration in the Danish population register.
In the Faroese P-System (Civic Registration Number System) a person is registered if
- the person is born in the Faroe Islands or has moved to the Faroe Islands as a resident or
- the person according to the Faroese Tax Administration is taxable to the Faroe Islands.
The Faroese P Number (p-tal) is used in almost all communication with public authorities. The p-tal consists of nine numbers. The first six numbers are a person’s date of birth, and the remaining three numbers are private and only known to the individual.
In cases where a person is not a Faroese resident, but where the Faroese Tax Administration at the same time finds the person taxable to the Faroe Islands, e.g., as an employee, the Faroese Tax Administration issues an identification number (v-number). The structure and format of this Identification number is similar, but not identical to the P number issued by the National Registration Office.
The population register is separate from the Danish jurisdiction. There is currently no solution to match cross-border service users with the population register. There have been plans for banks to allow a local identity for all cross-border service users, but this process would be quite cumbersome, so it has not been taken forward. The number of use-cases is too small considering the costs that could be involved.
According to interviewees, eID implementation is still in early phase, starting in 2020, so there are no major reform plans besides improving the infrastructure. The system was built from scratch with both public and private funding. Best practices were considered when building the solution, the solution is audited, so there are no major security risks.
Greenland
Greenland is an autonomous territory within Denmark. All residents in Greenland get a CPR number (the same as in Denmark) that is used for almost all communication with public authorities and therefore also in tax matters. The CPR number is also issued for all non-residents in Greenland where the Greenlandic Tax Administration finds the person is taxable to Greenland.
The GER number for non-natural persons and legal entities is issued according to different tax- and excise laws. The GER number is administrated by Skattestyrelsen (The Greenlandic Customs and Tax Administration) placed under the Greenlandic Ministry of Finance.
As a local eID solution, MitID
MitID, can be obtained through local banks, by contacting a citizen service centre in person or at www.nemid.nu. The Digital Agency of Greenland is the authority in acquiring eID-s and assists the municipalities in administration of the MitID scheme.
Population operations in Greenland are conducted using the Danish population register. However, information about residents in Greenland is maintained as a separate copy in Greenland. The use of e-services, including identity matching, is like in Denmark, and it relies on Danish infrastructure. Greenland has a single point of contact for e-services, such as hunting license, residence certificate and digital mail.
During the interview, it was emphasized that, due to Greenland's vast size and sparse population, the presence of eID and the accessibility of e-services are considered crucial because they enable service usage in regions where it would not be possible without eID. According to the interviewee, approximately 2,000 individuals (out of a total population of around 57,000)
Estonia
Estonia also has the current eIDAS eID means in use for its own citizens with level of assurance high. Citizens from other member states can sign into some of the Estonian public e-services with eIDAS if the member state has a notified eID means. As the attributes of the current eIDAS do not enable reliable identification, most of the e-services cannot be fully accessed (there are currently only a few SDG online procedures that can be accessed with eIDAS in EE). Estonia is also missing a central identity matching process for public e-services. Therefore, many digital services in Estonia require local authentication that uses the national ID number. The underlying issue, as in Finland, is that most online services cannot handle the foreign identifiers since they are dependent on the Estonian national identity code format to identify the user. Therefore, even if the authentication service passes the eIDAS eID attributes to the e-service application, the e-service might not recognize or accept eIDAS authentication or the eIDAS eID user will be forwarded to a manual process for identity matching and verification.
To simplify the adoption of eIDAS for relying parties, RIA operates a government authentication gateway service (TARA) that translates eIDAS SAML protocol to OpenID Connect (OIDC). For cross-border eID interoperability within the EU, RIA operates a centralized eIDAS Node services (eIDAS Proxy Service and eIDAS Connector) that use the TARA interface which translates eIDAS SAML protocol to OIDC. The eIDAS-Node application in the Estonian eIDAS-Node implementation is part of the European Commission’s eIDAS-Node sample software that is responsible for a secure communication between member states eIDAS-Nodes using the eIDAS SAML protocol. On the authentication with Estonian eID means in eIDAS Network, the eIDAS minimum data set (MDS) for a natural person contains current family name(s), current first name(s), date of birth and unique persistent identifier (Estonian personal identification code). The minimum data set for a legal person contains current legal name, Business Registry code (identifier for a legal person in Estonia). MDS attributes for a natural person are fully based on data on the Estonian eID certificate, for legal person the MDS attributes are requested from Estonian e-Business Registry using X-Road data exchange layer.
Authorization/access to Estonian e-services are based on a unique identifier (see more in Ch. 2.3.1 “Estonia (EE, interviewed)”).
The population register is a database which unites the main personal data on Estonian citizens, citizens of the European Union who have registered their residence in Estonia, and e-residents who have been granted a residence permit or right of residence in Estonia.
Personal identification code is always formed in the population register. However, minimum set of data needed for formation of the PIC (name, date of birth, gender, place of birth and citizenship) can move to population register in different cases by following authorities:
- Vital statistics office (local authority, notary, Foreign Ministry/representation): registration of a vital statistics event in Estonia or data entry from foreign vital statistics document.
- Police and Border Guard Board: issuing an identity document/residence permit or other proceedings provided by law.
- Health care provider: for new-born children’s medical birth certificate.
- County town local authority: for entry into a database based on a person’s application.
- Local authority: entering of residence of European Union citizen in the population register.
- Other agency for public duties (Foreign Ministry, Maritime Administration, etc.): performing their duty of entering the personal identification code in a state database.
Finland
Most Finnish public eServices have eIDAS authentication as part of Suomi.fi authentication but as it does not contain enough information it cannot be used as authentication as such. Most competent authorities require more information from the user to be able to use their eServices. Many digital services in Finland still require local authentication in the form of the Suomi.fi-authentication that uses the national ID number. The underlying issue is that most online services in Finland still only accept a Finnish national identity code to identify the user. Therefore, even if the authentication service passes the eID to the application, the other application may not recognize or accept eIDAS authentication. This prevents the authentication and use of Finnish digital public services with any other authentication identifiers, which hampers the use of services across borders.
In Finland, identity management is based on the idea that a person has only one identity, to which all transactions are attached. This is important, for example, from the point of view of paying benefits or pensions, as well as from the point of view of taxation. The problem is solved by asking as much information as possible about the person, either from an official document or by asking the person himself. This information is used to ensure that the identity is not already found in the Finnish population information system. If no information is found, one’s identity can be registered in the population information system. However, it currently requires face-to-face identification.
The problem is that a person can have multiple identities. Connecting these identities requires a lot of manual work by the officials. There is also a problem with eIDAS authentication, which provide too little information. People must be directed to a service where they will be asked for more information. In Finland, only a few organizations have built eIDAS support into their services, that is, few organizations can process a person's data with an eIDAS personal identifier.
According to Finnish legislation, a person cannot be registered in the Finnish population information system remotely. When a person is registered in the population information system for the first time, the person must be met face-to-face. In Finland, there was a draft law regulating remote registration (HE 132/2022) under consideration by the government, but the government did not have time to process it. A new government has been formed and according to the government's program, there is no intention to promote remote registration.
- For example, according to current legislation, a person must generally have a residence permit before a person can be registered in the population information system.
- For asylum seekers, it can take months, even years, before registration can be done. However, events related to a person must be processed by different organizations, and for processing to be possible, an organization-specific identifier is created for the person in the systems for processing.
- This organization-specific identity will later be manually associated with the centralized identity when it can be created. In the bill, which did not have time to be discussed, it was suggested that a centralized identity could be created earlier, e.g., when applying for a residence permit.
From the state perspective, the major challenge is that it cannot be ascertained whether the person has a centralized identity in the population information system and the systems of organizations. However, from the user’s perspective, the main difficulty is that the person must be asked for more information to find the identity information and it slows down the service.
In Finland, a study is underway on how eIDAS identifiers could be linked to a national identity, if such exists. If, on the other hand, there is no identity, the person could be registered remotely in the centralized population information system. However, all of these require a legislative change and, according to the government’s program, at least remote registration will not be promoted.
Latvia
Latvia has eIDAS in use for its own citizens with LoA high. Identity matching in case of one person with few Member State identities is considered problematic also in Latvia and a need for a Europe-wide unique person identifying mechanism or solution is recognized. Pre-analysis shows that standard attributes may be enough to identify a person in case the central permanent IDs implementation is going to be made or cross-country IDs relation scheme will be established. Decentralized or country-specific intention to match identities will complicate an OOTS system development and successful identity matching.
For now, the country has a unique and persistent identifier in use for the nationals, but due to a renewal project any person is currently allowed to change the identifier once, if they have the old form of the identifier. However, according to the interviewee, due to the change in the personal identification code format, there have been no insurmountable problems. Compatibility with the old personal identification code is ensured, and there is a system in place to verify the linkage between the new and old codes.
Citizens from other member states can sign into some of the Latvian Procedure portals and complete an eIDAS compatible services, but data or services provided may be imprecise or non-relevant for user because of already defined identity matching issues and unavailability to identify single person with multiple IDs.
State services operate with a personal identification code. When interacting with the government, registration in the Register of natural persons is required. The eIDAS authentication user is assigned a personal code in the Register of Natural Persons automatically.
In case of eIDAS authentication users, there may be duplicate records; for example, when a person arrives from Germany with an Estonian personal identification code, these records cannot currently be matched. Matching may also encounter issues when individuals arrive at different times with various documents issued by foreign countries. The foreign country's identification code is primarily used for information exchange and filtering with other nations, but currently, it is not machine-readable.
Data exchange using personal identification codes currently only works with Estonia (Population Register). Data exchange with Scandinavia or Lithuania does not function, and the matter is not particularly on the agenda now. Most cross-border users are mainly connected to the Baltic states, Sweden, or Norway.
According to interviewee, Latvia is not yet ready for everyday use of biometrics. Biometrics have a separate register that communicates with, among others, the driver's license register, and the population register. With biometrics, it is possible to perform searches, but it is not used daily because records cannot be matched one-to-one, and the search consumes a significant number of resources.
Main challenges include:
- When registering a company, it is not necessary to provide all the attributes that would be required for registration in the population register when registering the owner.
- There is a desire to create new e-services continuously, but often they are not developed from the users' perspective.
- The use of biometrics could increase, but currently, there are not very good solutions. To ensure consistent data quality in the population register, people's biometrics should be collected when recording personal data. Once this is achieved, viable solutions can be developed.
Lithuania
Lithuania has the current eIDAS in use for its own citizens with LoA high. The e-services are designed for nationals of the country whose national personal identification codes are connected to the public registries and databases. Foreigners (not only EU residents) need to apply for a resident ID („eRezidentas“) to get access to electronic services and a visit to the authority is required.
There is a central identity matching process for public e-services. Data of foreigners is stored in foreigner's registry and linked with Lithuanian identity code. The same matching process is applied to foreigners with resident ID and the ones who are coming through eIDAS. The process may still require some manual work.
Identity matching service is performed at the information system of Electronic Migration Services (MIGRIS). MIGRIS is managed by Migration Department under the Ministry of the Interior of the Republic of Lithuania. eIDAS node is at The State Information Resources Interoperability Platform (SIRIP).
When foreigner initiates log in directly from SIRIP via eIDAS, SIRIP webservice sends a data request to MIGRIS for checking if in the register of foreigners, the person has assigned ILTU code.
- If foreigner has assigned ILTU code, then personal profile is updated.
- If foreigner hasn’t assigned ILTU code, then MIGRIS creates a new one.
When a foreigner comes directly to SIRIP and logs in for the first time, the new user is asked to provide contact information as phone no., email address.
When a foreigner initiates log in from another procedure portal (external system) then the portal redirects the person for identification to SIRIP via eIDAS node. SIRIP WS sends a data request to MIGRIS for checking if in the register of foreigners, a person has assigned ILTU code.
- If foreigner has assigned ILTU code, then a personal profile is updated at SIRIP and eIDAS personal data + ILTU code are transferred to the requesting Procedure portal.
- If foreigner hasn’t assigned ILTU code, then MIGRIS WS creates a new one then personal profile is updated at SIRIP and eIDAS personal data + ILTU code are transferred to the requesting Procedure portal.
In this case, the person does not need to provide contact information: foreigner comes to SIRIP just for identification service from another Procedure Portal. In all cases ILTU code is provided with eIDAS data attributes.
Identity matching is performed by using the following attributes: name, date of birth and nationality. However, nationality attributes are calculated from the eIDAS code (PersonIdentifier) since for now there are no other working solutions.
Norway
Norway has the current eIDAS in use with LoA high. Norway's situation similar as in other Nordic-Baltic countries: even though eServices are widely used among nationals, identity matching of foreign users is difficult (see Ch. 2.3.1 Norway).
The Norwegian Tax Administration is responsible for the Norwegian National Population Register and the registration of residents living in Norway. This register is used as the basis for the registration for an electronic identification means.
Norway has bilateral and multilateral agreements between governments and authorities on population registration - E.g., the agreement between Denmark, Finland, Iceland, Norway, and Sweden. Exchanging the country’s national ID numbers with authorities in other countries is allowed between the Nordic countries to identify a person, and as documentation if someone asks and has got a legal reason to ask for it. Foreign eID codes and corresponding national ID numbers are registered in a separate register.
Sweden
Sweden also has eIDAS in use for citizens with LoA substantial. In Sweden, UID from other Nordic countries is stored in population register for residents that have moved to Sweden (from e.g., Norway, Denmark, and Finland). However, eUID is not stored in the Swedish population register. So, if a Nordic member state uses an identifier that is different in format as eUID compared to the holder’s UID, the match is unsuccessful.
Sweden defines matching based on three different confidence levels: A; B; C; The C level is the lowest confidence. The C level is possible to achieve if the UID provided by the user (that has been identified through eIDAS) is found as single hit in population register and person is registered as emigrated. If there are more than one person with the same name and birthday in the population register, then C level is not possible. The data is stored in a service that is integrated to the Swedish eIDAS node. Data is created based upon request by user. Sweden widely uses BankID, Freja and Svenska Pass
Passport or confirmation by relatives are used to create a match on A level. I.e., to strength the proof of being the holder of the national UID.
The Swedish Tax Agency is responsible for the population register and the registration of residents living in Sweden. This register is used as the basis for the registration for an electronic identification means. As set out in the Population Registration Act (1991:481), The Swedish Tax Agency is responsible for the civil registry of Sweden. Persons permanently living in Sweden are registered in the population register with a unique identifier (Swedish personal identity number). Normally a person keeps this identifier their whole life, only under very rare conditions can someone change their personal identity number. Persons not permanently living in Sweden receive a unique coordination number.
A personnummer (Swedish UID) is a 10-digit number (YYMMDD-XXXX)
When stored or handled in a structured way, the law states handling it with the full length of the year:
YYYYMMDDBBBC
The year a person turns 100 the hyphen is replaced with a plus sign.
Coordination numbers are used for persons who need to interact and/or live in a short period of time (less than a year). Coordination numbers expire. If a person stays for example a year or longer, then she will get a personnummer that replace her coordination number. Coordination numbers are also found in the Swedish population register. However, if a person is subsequently listed in the Swedish Population Register and receives a personal identity number, this will be linked with the coordination number. Coordination numbers are structured in a similar way to personal identity numbers, but 60 is added to the day on which an individual was born. So, someone born on 24 September 1990 would be given the coordination number 900984, followed by four digits. In coordination numbers for men, these four digits are odd numbers. For women, they are even numbers.
Coordination numbers can be requested in two ways
A third way is that an employer can request a coordination number for an employee.
- Usually, a public authority will request a coordination number for an individual if it is needed for its own activities or to coordinate with other public authorities. If this is the case, the public authority in question will manage all interaction with the Swedish Tax Agency.
- If a person has no contact with any public authority but still needs a coordination number, the person can apply for one by visiting a Swedish state service centre.
Moreover, Sweden has a new system that creates coordination numbers on all 3 different levels of confidence for identity proofing. To get the highest level of confidence, the person must visit the Swedish state service center and have necessary records for identification.
Sweden does not issue eID means to legal persons, however a natural person can be authorized to represent a legal person. Sweden has an eID system that can provide a pseudonym unique identifier for a person that acts in his/her job position and not as a private legal person. The attribute is in the format of uid@oid.
To simplify the handling of users and identities in Swedish services the Swedish eIDAS node generates a standardized identity attribute for users that have been authenticated using a foreign eID, a so-called Provisional ID (PRID). The eIDAS node will also create an attribute that declares which persistence, or lifetime, the PRID attribute has. The PRID attribute is generated based on attributes values received from the foreign authentication according to specific methods for each country. Every combination of country and method a graded based on expected persistence, i.e., how likely it is that an identity for a person is changed over time. This makes it possible for Swedish services to customize the communication with the user and to proactively provide features for a user whose identity has changed and make it possible for this user to access his or her account.
In some cases, a person that has been authenticated using a foreign eID may hold a Swedish personal identity number. It can, for example, be a Swedish citizen that has moved abroad and obtained a foreign eID, or a foreign citizen that is, or has been, registered (folkbokförd) in Sweden and has been assigned a Swedish personal identity number.
According to interviewees, the main challenges regarding identity and record matching include:
- few valuable digital solutions that in reality work with only eIDAS. Public relying parties have a strong tradition on building systems based on identifiers managed in the Swedish population register. Individuals and information about individuals are identified via Swedish identification number.
- no digital solution for onboarding new people to the Swedish identification system, i.e., during the period that starts with the first contact to the point when person receives PID or a Swedish coordination number.
- Lack of governance that would bridge the digital and physical world. A good example is the challenge of providing a digital support for onboarding people to Sweden.
- Legal challenges, especially when several governments are involved in building a common system.
- Bad user experience and difficulties in understanding whom to contact for support. Users must use interfaces provided by different relying parties, eIDAS-nodes, eID provider, and soon also an identity matching system.
According to interviewees, in most cases today where relying parties attempt to authenticate the user through eIDAS, the user is authenticated, but relying party doesn’t know how to connect the user to records and information in their business processes. From a user point of view, also it would be important to be able to use identity matching across all Swedish public organizations.
Today, the Swedish population register has access to the Nordic countries’ personal identification numbers for citizens who live in Sweden. If there was an agreement between the Nordic countries to provide such attribute through the eIDAS nodes, identity matching could be performed with a higher confidence, i.e., when the eIDAS assertion contains an identification number that also exists in the Swedish population register.
Iceland
In Iceland, persons and enterprises are issued a unique identification number (kennitala) which is recorded in the national register and register of enterprises. ID numbers are composed of ten digits. The first six of these are the individual’s date of birth in the format DDMMYY. The seventh and eighth digits are randomly chosen when the ID number is allocated (ranging from 20 to 99), the ninth is a check digit and the tenth indicates the century of the individual’s birth: ‘9’ for 1900–1999, ‘0’ for 2000 and beyond. ID numbers are often written with a hyphen following the first six digits, e.g., 120174-3389. The ID number from national registry is the main unique identifier used in Iceland.
In Iceland, foreigners who come to work or relocate for various reasons are assigned a System ID, which is structured similarly to the personal ID number.
Process has started to make a new version of the System ID which will look different from the kennitala - it will be a random number, which starts with 8.
Personal ID numbers are issued at birth to all children born in Iceland and Icelandic citizens born abroad. Personal ID numbers are also assigned to all individuals who register their domicile in Iceland. When domicile is registered in Iceland a personal ID number is assigned in the national register, or in cases where individual is already registered in the system ID register, the system ID no. is moved from register of System ID No. to the National register. Entitlement to public services and assistance is generally dependent on having a registered legal domicile. It is therefore recommended that individual register their legal domicile as soon as possible.
Audkenni is the only issuer of eID means today and the company is 100% owned by the state.
One issue is that having an ID number is usually a prerequisite to accessing most government services, banking services and even some businesses transactions. This can be a hinderance to newly settled residents, as it takes some time to apply and be issued a new ID number. Employers typically apply for System IDs on behalf of their foreign workers before they arrive in Iceland, because these IDs are a prerequisite for starting work.
The following table (Table 12) gives an overview of different personal identification codes used in Nordic-Baltic countries, current eIDAS status and main challenges that emerged from the analysis of the current situation.
Table 12 Used PIC(s), Uniqueness Identifier,
Describes how the PIC is made visible to other countries via eID.
Country | Used PIC(s) | Uniqueness Identifier | eIDAS status | LoA | Main challenges |
Estonia | personal identification number (isikukood) | Estonian personal identification code | notified | high |
|
Finland | personal identity code (henkilötunnus or hetu) | – | un-notified | – |
|
Norway | national identity number (fødselsnummer) D-number (issued to people with temporary connection to Norway) | Derived from the Norwegian Personal Identification Number | notified | high |
|
Sweden | personal identity number (personnummer) coordination number (issued to people who need to interact with public authorities, but have never been listed in the population register) | Derived from the Swedish Personal Identification Number | notified | substantial |
|
Iceland | System ID number Personal ID number | – | un-notified | – |
|
Faroe Islands | civil registration number (p-tal) V number (for legal persons) | – | un-notified | – |
|
Denmark | personal identification number (personnummer or CPR-nummer) | Derived from DK’s unique PID number | notified | substantial |
|
Lithuania | Personal code (asmens kodas) | Personal ID number | notified | high |
|
Latvia | Personal code (personas kods) | The new type of personal code consists of eleven digits, ensuring the non-repetition of personal codes. The first digit of the personal code is "3", the second digit is an automatically generated random number from "2" to "9" by the system, and the remaining digits are automatically generated random numbers from "0" to "9" by the system. | notified | substantial and high |
|
Greenland | – | un-notified | – |
2.4.2 Overview of data’s quality and trustworthiness in the Nordic-Baltic region
Nordic-Baltic region countries are following the same principles in terms of how data about country’s population is maintained. All Nordic-Baltic countries have implemented centralized digital solution for population registry, which assures common practice of population management, reliability of data and high system availability.
The framework and implementation of population registries is stipulated by respective law and implementing acts. Legal acts stipulate the composition of data in the population registry and the procedure for maintaining the population registry, entering data to registry, ensuring access to data, and supervising these activities. Any activities within population registry must be in line with Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April 2016 on the protection of natural persons about the processing of personal data and on the free movement of such data and repealing Directive 95/46/EC (General Data Protection Regulation – GDPR). It is common to have a single authority who is responsible for the maintaining of population registry.
Population registry’s main purpose is to keep population records and by this assist governmental authorities, local authorities, and other legally entitled entities to perform their duties. Population registry is the tool for identity management, as correctness of personal identifiable information entered therein is assumed. In addition to personal identifiable information and persons’ statuses (i.e., alive or dead) the population registry may contain data about marital status, kinship, education, etc.
Nordic and Baltic countries have established data exchange amongst themselves for managing population migration. The receiving country does notify the country of origin about residence settlement if respective agreements have concluded between two countries. Not all Nordic-Baltic countries have concluded such agreements that can lead to outdating of persons’ residence data in population registry of country of migration origin.
Population registries operate based on primary key identifier, which is the personal identification number issued to a person. Some population registries also contain personal identification numbers assigned to persons by foreign countries or data about ID-document issued to population registry’s subject by foreign countries. These named records may have only informative value.
Given the above-described circumstances it can be stated that data quality and trustworthiness is well handled by population registries of Nordic-Baltic countries. Potential identity and record matching solutions can incorporate and rely on personal identifiable information stored in population registries. On the other hand, depending on identity and record matching solutions, the population registries might be subject to further development in terms of composition of data in registries and new application programming interfaces (APIs) for data exchange and handling between identity and record matching actors/components.
For clarification the identifiers are described in Table 13 below.
Table 13 Uniqueness and data structure of local identifier (PIC) per country.
Country | PIC derived? | Digits* | 1 | 2 | 3 | 4 | 5 | 6 | h | 7 | 8 | 9 | 10 | 11 | 12 | 13 |
Estonia | + | 11 | G/Cn | Y | Y | M | M | D | – | D | Sq | Sq | Sq | Ch | – | – |
Finland | + | 11 | D | D | M | M | Y | Y | +/-/A | Sq | Sq | G | V | – | – | – |
Norway | + | 11 | D | D | M | M | Y | Y | + | Sq | Sq | Sq | Ch | Ch | – | – |
Sweden | + | 11 | Y | Y | M | M | D | D | + | Cn | Sq | Sq | G | Ch | – | – |
Iceland | + | 10 | D | D | M | M | Y | Y | + | R | R | Ch | Cn | – | – | – |
Denmark | + | 10 | D | D | M | M | Y | Y | + | Cn | Sq | Sq | G | – | – | – |
Faroe Islands | + | 9 | D | D | M | M | Y | Y | + | V | V | G | – | – | – | – |
Lithuania | + | 11 | G/Cn | Y | Y | M | M | D | – | D | Sq | Sq | Sq | Ch | – | – |
Latvia | - | 11 | 3 | R | R | R | R | R | – | R | R | R | R | R | – | – |
Greenland | + | 10 | D | D | M | M | Y | Y | + | Cn | Sq | Sq | G | – | – | – |
“+” = yes, “-“ = no
* DD-day, MM- month, YY-year, G-gender, Cn-century, Sq-sequence, R-random, Ch-check, H-hyphen, V-verification.
* DD-day, MM- month, YY-year, G-gender, Cn-century, Sq-sequence, R-random, Ch-check, H-hyphen, V-verification.
2.4.3 Joint difficulties to tackle in collaboration
Through the whole AS-IS analysis five main issues popped out more often and were associated with most impact by most countries interviewed (see Table 14):
Description of the issue | Problem area |
A. Recurring work is done for identity verification and matching. If a person’s activities engage different domains, then identity matching results are not shared within the state. Moreover, the identity matching results are not shared between the states. | Scope |
B. There are differences in PII (Personal Identifiable Information) datasets operated by states due to their legal and cultural particularities (e.g., place of birth logic, contact address obligation, facial biometric data storage/usage, derived PNOs towards other states, pseudonyms). Therefore, common best practices are hard to be defined. | Principles |
C. Motivation for changing status quo is low due to high initial investment costs, even though risks associated with potential identity mismatch are serious. Current fragmented processes allow also to keep the scope of any error clearly local. | Principles |
D. Low capability of Population Registries to adapt to any changes in PII dataset or modifications/improvements in processes of PII handling. As central repositories with also crucial national importance Population Registries primary responsibility is to each Member State, persons currently not residents of MS may not get attention and budget. | Technology |
E. Identity verification and matching is manual work performed by personnel who are not trained/experts in ID-management (healthcare, educational personnel, etc.). | Scope |
Table 14 Five main issues with most impact on achieving the common vision
Those issues were validated in a physical workshop, which brought together respective parties of Nordic-Baltic countries. Every issue was analyzed from different angles, considering countries perspectives (see 2.4.4.
Vision
Main issues above should be solved by achieving a “Happy Day” vision for different stakeholders. And a future solution must be designed accordingly for those (three main) stakeholders:
- A person with positive intentions towards use of identity and record matching services can easily connect all one’s identities and relating records in any information system across Nordic States.
- A person with negative intentions towards use of identity and record matching services cannot hide one’s other identities across Nordic States and their related records.
- States can find duplicated identities from Population Registries across Nordic States, and match records accordingly.
Difficulties causing issues
Description of the difficulties to be tackled in co-operation | Where the Problem MAINLY LIES?* |
| Technology |
| Scope |
| Principles |
| Principles |
| Technology |
| Technology |
| Technology |
| Scope |
| Scope |
| Scope |
| Technology |
| Scope |
| Technology |
| Scope |
| Principles |
* The problem can manifest in more than one area, but here the main issue is highlighted. | |
Table 15 Fifteen difficulties that are causing five main issues.
Those fifteen difficulties are resulting in unwanted situations regarding either service user or the services itself:
- user is denied access to cross-border services.
- user is not matched to identity.
- records are not matched to the user.
- cross-border services are not used or developed.
All those elements described above “vision for stakeholders + situations + difficulties + problem area” are joint together in Table 16 to illustrate the complexity of the situation that future Nordic-Baltic identity and record matching solution must unravel.
Table 16 Summary of difficulties in regard to Single Digital gateway vision
Difficulties (in the middle of this matrix) are numbered the same, as it was done previously in Table 15
Single digital gateway use vision:1 | Fully digital process and uninterrupted customer journey | Unified maturity level | Set of attributes ensures compatibility with relying parties | ||||
Concerning: | Scope (States: internal or cooperation) | Technology and infrastructure | Principles and Regulations | ||||
Situation caused by difficulties: | user is denied of access to cross-border services | duplicated ID-s | user is not matched to identity | records are not matched to user | Cross-border services are not used or developed | ||
Impact on: | Person with positive intentions | …can easily connect all one’s identities in any information system across Nordic States |
|
|
|
|
|
Person with negative intentions | …cannot hide one’s other identities and related records across Nordic States |
|
|
|
|
| |
States | …can find a duplicated identities from Population Registries across Nordic States, and match records accordingly |
|
|
|
|
| |
2.4.4 Summary of common issues and input to solutions
On joint seminars 5 previously mentioned issues (from A. to D. at Table 14) were analyzed and possible solutions were discussed. Most importantly, the question “What could be the solutions to overcome the problem?” was asked. The following lists present the results from the seminar, and therefore gave a direct input to TO-BE analysis.
- Recurring work is done for identity verification and matching if person’s activities engage different domains as identity matching results are not shared within the state. Moreover, the identity matching results are not shared between the states.
- Why is this a problem in the first place (what consequences may arise from it)?
- Clients must re-identify themselves (inconvenience)
- No overview of the person on country level
- What does this mean (what might accompany this problem)?
- Possibility of fraud
- How has this problem arisen (for what reasons)?
- Needs for different sectors are different.
- High-level of match making is not necessary for all
- Why is the problem unresolved (for what reasons)?
- Whose responsibility it is?
- Decentralization
- Lack of regulations
- What could be the solutions to overcome the problem?
- National ID solutions
- Common framework for ID matching in EU level
- There are differences in PII (Personal Identifiable Information) datasets operated by states due to their legal and cultural particularities (e.g., place of birth logic, contact address obligation, facial biometric data storage/usage, derived PNOs towards other states, pseudonyms).
- Why is this a problem in the first place (what consequences may arise from it)?
- We need solutions for eIDAS and SDG.
- What does this mean (what might accompany this problem)?
- Problems in providing e-services.
- Problems in e-identification
- Why is the problem unresolved (for what reasons)?
- GDPR restrictions (conflict with identity matching goals)
- It’s a new problem.
- No agreement on datasets
- Legal and cultural background is different.
- What could be the solutions to overcome the problem?
- Common rules on datasets; in ID numbers
- Data from passports
- Passports mandatory
- Risks associated with potential identity mismatch and the economic benefits of enhanced/automated processes are small/minimal. Thus, motivation for changing the status quo is low.
- Why is this a problem in the first place (what consequences may arise from it)?
- Nothing changes
- No e-services and no clear ownership
- What does this mean (what might accompany this problem)?
- Low usage of cross-border e-services
- Low eID means usage.
- How has this problem arisen (for what reasons)?
- Not doing anything is less of a burden.
- No value in resolving (lack of motivation)
- Why is the problem unresolved (for what reasons)?
- GDPR conflict
- Mistrust of governance
- Low nr of (cross-border) e-services
- Low volume of users
- Too few attributes (risk of mismatch)
- What could be the solutions to overcome the problem?
- More attributes mandatory
- Data sharing agreement in NBC
- Store eID dataset in registries
- NBC voluntary identifier
- Biometrics
- Fingerprint as a minimum dataset
- Have a friend in every country to validate you as a person.
- Low capability of Population Registries to adapt to any changes in PII dataset or modifications/improvements in processes of PII handling.
- Why is this a problem in the first place (what consequences may arise from it)?
- Old registries
- Any changes are large-scale ones.
- What does this mean (what might accompany this problem)?
- Changes can brake systems.
- How has this problem arisen (for what reasons)?
- Motivation is low.
- The cost of changes is high.
- No small things and quick fixes
- Why is the problem unresolved (for what reasons)?
- Low motivation
- What could be the solutions to overcome the problem?
- Cooperation on NBC level
- Sharing data between population registries
- piloting
Identity verification and matching is manual work performed by personnel who are not trained/experts in ID-management (healthcare, educational personnel, etc.)
- Why is this a problem in the first place (what consequences may arise from it)?
- Manual work takes time and workforce.
- What does this mean (what might accompany this problem)?
- Time, cost
- Can’t access services.
- How has this problem arisen (for what reasons)?
- you need to have an eID.
- Why is the problem unresolved (for what reasons)?
- Low motivation
- Population registries capability
- What could be the solutions to overcome the problem?
- financing
According to the vision and to address today’s difficulties (see 2.4.3), 10 possible solutions for Nordic-Baltic identity and record matching were derived, which were also validated on the joint workshop.