Integrating Unique Identification Numbers In Civil Registration © 2018 International Bank for Reconstitution and Development/The World Bank 1818 H Street, NW, Washington, D.C., 20433 Telephone: 202-473-1000; Internet: www.worldbank.org Some Rights Reserved This work is a product of the staff of The World Bank with external contributions. The findings, interpretations, and conclusions expressed in this work do not necessarily reflect the views of The World Bank, its Board of Executive Directors, or the governments they represent. The World Bank does not guarantee the accuracy of the data included in this work. The boundaries, colors, denominations, and other information shown on any map in this work do not imply any judgment on the part of The World Bank concerning the legal status of any territory or the endorsement or acceptance of such boundaries. Nothing herein shall constitute or be considered to be a limitation upon or waiver of the privileges and immunities of The World Bank, or of any participating organization to which such privileges and immunities may apply, all of which are specifically reserved. Rights and Permission This work is available under the Creative Commons Attribution 3.0 IGO license (CC BY 3.0 IGO) http://creativecommons. org/licenses/by/3.0/igo. Under the Creative Commons Attribution license, you are free to copy, distribute, transmit, and adapt this work, including for commercial purposes, under the following conditions: Attribution—Please cite the work as follows: World Bank. 2016. Integrating Unique Identification Numbers In Civil Registration, Washington, DC: World Bank License: Creative Commons Attribution 3.0 IGO (CC BY 3.0 IGO) Translations—If you create a translation of this work, please add the following disclaimer along with the attribution: This translation was not created by The World Bank and should not be considered an official World Bank translation. The World Bank shall not be liable for any content or error in this translation. Adaptations—If you create an adaptation of this work, please add the following disclaimer along with the attribution: This is an adaptation of an original work by The World Bank. Views and opinions expressed in the adaptation are the sole responsibility of the author or authors of the adaptation and are not endorsed by The World Bank. Third Party Content — The World Bank does not necessarily own each component of the content contained within the work. The World Bank therefore does not warrant that the use of any third-party-owned individual component or part contained in the work will not infringe on the rights of those third parties. The risk of claims resulting from such infringement rests solely with you. If you wish to re-use a component of the work, it is your responsibility to determine whether permission is needed for that re-use and to obtain permission from the copyright owner. Examples of components can include, but are not limited to, tables, figures, or images. All queries on rights and licenses should be addressed to World Bank Publications, The World Bank, 1818 H Street, NW, Washington, DC, 20433; USA; email: pubrights@worldbank.org. 2 I NTEGRATING U NI Q U E I DEN T I F I CATI O N N U MBERS IN C IV IL R EGIST R AT ION Table of Contents About ID4D i Acknowledgements ii Abbreviations iii 1. Introduction 1 2. CRS—Process Flow 5 Elements and Processes of CR 6 In Summary 7 3. UIN Structures—An overview of existing experiences 9 Structured Versus Random UINs 10 Checksum Models 12 International Standards 13 In Summary 13 4. UINS—USE Cases 15 How to Link BRNS and UINs 15 Recommended UIN Structure and Point of Issuance 16 In Summary 19 5. Summary of Digital Practices for Linking CRS and CIS 21 Proposed Architecture Minimum Layer 23 Microservices Critical to a CRS 23 Microservices Associated with a CIS 25 Protection of Personal Data and Privacy Considerations 26 In Summary 26 References 27 Annexes 28 Appendix A: Description of Unique Identification Numbers (UINs) of More Than 70 Countries 28 Appendix B: Architecture Diagrams of a Minimum Layer for Civil Registration and Civil Identification Systems 34 Appendix C: Outline of System Architecture Report 37 Overview 37 Terminology 37 FIGURES FIGURE 1. Birth Registration Process 7 FIGURE 2. Unique Identification Numbers: Average Number of Digits 11 FIGURE 3. Aadhaar Linking to Birth Registration 17 FIGURE 4. Unique Identification Number (UIN) Structure with Pregenerated UIN Stickers 18 FIGURE 5. Overview of a Country’s Identification System 24 TABLES TABLE 1. Unique Identification Number (UIN) Elements 12 TABLE 2. Existing Country Identification System Components 22 4 I NTEGRATING U NI Q U E I DEN T I F I CATI O N N U MBERS IN C IV IL R EGIST R AT ION About ID4D The World Bank Group’s Identification for Development (ID4D) initiative uses global knowledge and expertise across sectors to help countries realize the transformational potential of digital identification systems to achieve the Sustainable Development Goals. It operates across the World Bank Group with global practices and units working on digital development, social protection, health, financial inclusion, governance, gender, legal, among others. The mission of ID4D is to enable all people to access services and exercise their rights, by increasing the number of people who have an official form of identification. ID4D makes this happen through its three pillars of work: thought leadership and analytics to generate evidence and fill knowledge gaps; global platforms and convening to amplify good practices, collaborate and raise awareness; and country and regional engagement to provide financial and technical assistance for the implementation of robust, inclusive and responsible digital identification systems that are integrated with civil registration. The work of ID4D is made possible with support from World Bank Group, Bill & Melinda Gates Foundation and Omidyar Network. To find out more about ID4D, visit worldbank.org/id4d.  i Acknowledgements This paper was prepared by the Identification for Development (ID4D) initiative, the World Bank Group’s cross-departmental effort to support progress towards identification systems using 21st century solutions. The WBG team wishes to thank all those involved in the preparation of this paper, especially Sanjay Dharwadker, Head of Global ID Consultancy, WCC, Utrecht, The Netherlands. Mia Harbitz, Samuel Mills, and Robert Palacios (World Bank Group) provided expert inputs. Comments from Mijung Kim (Korea National IT Industry Promotion Agency) are gratefully acknowledged. Vyjayanti Desai (World Bank Group), Jonathan Marskell (World Bank Group), Wim Rietdijk (WCC), and Ludger Weller (WCC) provided overall guidance. This work is a product of the staff of the World Bank with external contributions. The findings, interpretations, and conclusions expressed do not necessarily reflect the views of the World Bank, its Board of Executive Directors, or the governments they represent. The World Bank does not guarantee the accuracy of the data included in this work. ii I NTEGRATING U NI Q U E I DEN T I F I CATI O N N U MBERS IN C IV IL R EGIST R AT ION Abbreviations ADL architecture description language BRN Birth registration number CI Civil identification CIS Civil identification system COTS Commercial off-the-shelf CR Civil Registration CRS Civil registration system DD Day ICAO International Civil Aviation Organization ICT Information and communications technology IEC International Electrotechnical Commission IEEE Institute of Electrical and Electronic Engineers ISO International Organization for Standardization MM Month MRTD Machine-readable travel document UIN Unique identification number UNICEF UN Children’s Fund YY Year  iii 1. INTRODUCTION Target 16.9 of the U.N. Sustainable Development Goals, which states, “By 2030, provide legal identity for all, including birth registration,” presents an opportunity for countries to link civil registration (CR) systems (CRSs) and civil identification (CI) systems (CISs), which has the potential to benefit multiple sectors. The United Nations defines CR as the universal, continuous, permanent, and compulsory recording of vital events provided through decree or regulation in accordance with the legal requirements of each country (UN Statistics Division 2014). Identity refers to the unique set of features and characteristics of a person, including his or her name and other biographical characteristics (IADB 2011a). The CRS encompasses the institutional, legal, and technical norms that the government establishes to conduct CR in a technical, sound, coordinated, standardized manner throughout the country, taking into account cultural and social circumstances particular to the country (IADB 2013). Within the CRS, birth registration is the starting point for establishing an individual’s identity, and the civil register records all relevant biographical information (e.g., name, date of birth, place of birth, parents’ names). The CRS is the foundation for enrollment in the CIS and other functional registers. The CIS, which is the technical and organizational infrastructure used to define, design, and administer the attributes of an identity (IADB 2011a), includes all information from the CRS and may include other attributes such as a unique identification number (UIN), signature, photo, and biometrics (e.g., fingerprint, facial recognition, hand geometry, voice recognition, iris scan, retinal scan), which may be used at the time of identity record creation to ensure uniqueness through deduplication (using one-to-many comparison). Biometrics may also be used for identity verification or authentication (using one-to-one comparison), although birth registration establishes legal identity in the first place. Functional registers such as electoral rolls, health records, insurance records, pensions, driver’s licenses, passports, income tax records, and municipal records tend to contain subsets of the population; for example, electoral rolls contain only people who are aged 16 (or 18) and older and thus exclude children. For this reason, they can never be a substitute for an interconnected and effectively managed CRS strongly coupled with a CIS. In addition to systems, processes, and standard operating procedures, interconnection between CRS and CIS requires concerted efforts to develop rules and regulations, infrastructure, and human resources. It also requires In t roduction 1 effective communication with end users, citizens, and residents. In low- and middle-income countries with limited capacity and resources, this effort calls for specific long-term support to ensure not only one-time implementation, but also sustainability. Although many low- and middle-income countries have had CRSs for centuries, these systems have been paper based. A number of countries have modernized their CRSs and CISs to bring them in line with contemporary needs and practices, but many more need to do so, and the current target of achieving universal legal identity for all, including birth registration, by 2030 requires urgent action so that no country and no person is left behind. The objective of this report is to examine the process for assigning UINs at birth and the mechanism for incorporating them into the civil register and including them on the physical birth certificate. This report will discuss the CRS and the practical steps necessary to ensure a system that can establish the identity of a person and issue a trusted certificate to attest to his or her civil status. Although it may serve as a reference for country-specific discussions, the overarching issues are universal. This report is divided into three main sections. ƒƒ Description of the process flow associated with CR, with emphasis on birth registration, to lay out a generic set of processes needed for any system. Description and analysis of UIN structures. ƒƒ Overview, description and analysis of UIN structures, followed by use cases. ƒƒ Description of necessary steps and good practices for linking CRS with CIS, using UINs as a common denominator. 2 I NTEGRATING U NI Q U E I DEN T I F I CATI O N N U MBERS IN C IV IL R EGIST R AT ION In t roduction 3 2. CRS—PROCESS FLOW This section describes the flow and generic set of processes required for any CRS, using birth registration as an example; and provides an overview of the elements of birth registration, taking into consideration protection of personal data. CR is performed primarily to establish the identity of a person and to issue the corresponding legal documents that the law provides for to verify the person’s civil status. The civil register is a main source of vital statistics, which are used to plan and monitor national development plans. Complete coverage, accuracy, and timeliness of CR are essential for quality vital statistics. CRSs play three essential roles: to establish the identity of a person at birth and maintain the record of that person’s civil status throughout his or her life, to issue the relevant certificate for his or her civil status, and to inform the national statistics office of the occurrence of vital events for the production of vital statistics. The vital events recorded in the CRS are birth, death, fetal death, adoption, marriage, divorce, recognition, legitimation, annulment of marriage, and judicial separation of marriage (UN Statistics Division 2014). Since the United Nations adopted the Sustainable Development Goals in 2015, the focus on the importance of CRSs and CISs has increased, resulting in a number of global initiatives to improve and connect these systems. The existence of national CISs and the need for unique identification and authentication of individuals has also increased recognition of universal birth registration as the foundation of a person’s unique and legal identity. Furthermore, governments around the world rely on efficient functional registers (e.g., for health, education, pensions, social benefits, and voter registers) for provision of benefits and access to civic rights. Governments also depend on timely statistics for informed decision-making, and having quality vital statistics depends on comprehensive and timely registration of civil events and associated information, as defined by law. Different ministries or departments often manage the civil registry, the CI registry, and the vital statistics office. The civil registry is usually the least centralized of the three agencies, consisting of various field offices, whereas the CI registry and the vital statistics office tend to be more centralized. CRS —P rocess Flow 5 A CRS establishes the legal foundation of an individual’s identity by recording the individual’s biographical information (e.g., name, date and place of birth, name(s) of parent(s)) that helps establish legal identity. Birth registration is not necessarily synonymous with citizenship. In some cases, place of birth might determine citizenship, if the principle of jus soli (of the soil) applies. Similarly, the names of parents are important in cases of jus sanguinis (of blood descent). By the same token, some countries do not permit citizenship to be passed through the mother. ELEMENTS AND PROCESSES OF CR The UN Principles and Recommendations (UN Statistics Division 2014), and UN Children’s Fund (UNICEF) and the Inter-American Development Bank’s “Toward Universal Birth Registration” (Harbitz and Gregson 2015) describe the processes for CR. For birth registration, this involves notification of birth, registration of the birth, and issuance of an official birth certificate (figure 1) that includes the following elements: a. Name of the process: birth registration. b. Purpose: registration of the identity of the individual and issuance of a birth certificate. c. Person responsible for initiating the process or declaring the event: legal guardian(s), as defined in the national legal framework (e.g., mother, mother and father), health facility, or birth attendant. d. Required documents (including the registration submission): for example, mother’s or other legal guardian’s identification and notification of live birth. e. Officers responsible for the process: the individuals authorized to process registrations. f. Authorizing officer of the civil registry: officer of the civil registry who is legally accredited to approve or authorize (usually director). g. Content of a birth record: such as name of child, date of birth, place of birth, name of parent(s) (or legal guardian), sex. The civil registry assigns a folio or registration number, which is entered into the record; a UIN may also be assigned at this stage. h. Document to be issued: first birth certificate, with unique registration number, free of charge. i. Documents to archive: supporting documents of the mother and father (if identified) and the medical certificate of live birth or record of foundling1, as described by the law. A birth certificate contains the person’s basic identity information, but it cannot be used to authenticate identity, which can be done only if additional attributes are added to the CRS and to the document itself. A starting point is to issue a UIN at birth, which is critical to ensure the identity of the individual throughout his or her life; it is important to be able to link vital events to one another in the CRS and CIS. The birth registration process is similar to those of other vital events, and the archiving function is a critical element for linking all vital events of an individual. By its very nature, the civil registry is local and often part of the village or municipal office. The link between the local registry and the central registry is often not efficient, especially when it is paper based. Many such systems, even after they have been computerized, maintain their decentralized nature to the extent that individual municipal systems are developed in isolation from one another, and it will require substantial effort to make them interoperable with the central level and with one another. Because of the decentralized nature of these systems, data pertaining to a single individual could be entered at various locations when the person moves. A person may be born in one place, marry in another, 1 foundling is an infant whose parents have abandoned it and someone has discovered and is caring for. 6 I NTEGRATING U NI Q U E I DEN T I F I CATI O N N U MBERS IN C IV IL R EGIST R AT ION Figure 1. Birth Registration Process Declaration of birth by informant Notification of birth (by hospital, midwife, village chief) Registration of birth by civil Notification (additional in some countries) Supplementary evidentiary documentation (e.g., hospital attestation of birth) given to informant Issuance of birth certificate by civil registry to present to registrar or given to civil registrar directly Source: UNICEF 2013. and die somewhere else. In addition, when parents migrate or are displaced, they may opt to reregister a child in the new place of residence if the original birth certificate has been lost. A birth certificate is often required to access health services or to start school. If the CRS is manual and paper based, it is difficult to ensure a unique identity for a person. As countries upgrade their CRSs to be electronically based, a UIN is an additional attribute that will contribute to uniqueness and can be provided at birth. IN SUMMARY ƒƒ There are defined processes for registration of vital events, but the records cannot be properly linked unless they have common elements. ƒƒ In addition to name and birth date, one such element, or attribute, is a UIN, which is preferably issued at birth. CRS —P rocess Flow 7 3. UIN STRUCTURES—AN OVERVIEW OF EXISTING EXPERIENCES This section provides an overview of UIN structures from various countries, including an assessment of the pros and cons of different UIN designs. Having a UIN is beneficial for individuals as a means to be recognized for who they are and access ascribed benefits and rights, including education, voting, opening a bank account, buying or inheriting property, paying taxes, enrolling in a health insurance plan, and qualifying for a cash transfer. It is also an important tool for governments to ensure that the right person has access to an ascribed benefit or right. Norway and Sweden began assigning UINs in the early 1960s; now approximately 70 countries assign a UIN (different from a social security or health service number) at some stage in the life of a citizen or resident. The details of UINs vary from country to country. The length generally varies from 7 (e.g., Venezuela, Hong Kong, Macau, Greece) to 18 (People’s Republic of China, Mexico) digits, although San Marino, a small principality with only approximately 33,000 inhabitants, uses only 5 digits. In nearly 90 percent of the cases studied for this report, the length of personal identifiers was between 9 and 13 digits, and with a few exceptions, they consisted entirely of numerals. A UIN most commonly includes numerals that indicate date of birth, place of registration, administrative division, status of nationality or citizenship, and sex. In a few cases (Italy, Switzerland, New Zealand), abbreviated name and surname are also part of the personal identifier. Almost without exception, part of the UIN is a unique serial number, which is constructed in three different ways, of which two are random and one is sequential. The serial number embodies attributes such as issuing location and sex and in some cases century of birth. These are incorporated for a variety of reasons, some of which are somewhat less relevant today than a few decades ago, when the numbering schemes were conceived. When a UIN is issued without connection to the central registry, incorporating issuing location is a practical necessity so that individual enrollment and registration locations can construct and issue numbers instantaneously. If the UIN incorporates date of birth, the most common format to do so is YYMMDD, so as to optimize the number of numerals. Temporal problems can arise in this case because a national database could have persons born U IN St ru ct u r es —A n ov e rv i e w of e x ist i n g e xpe rie nces 9 in 1910 and 2010. Both would have YY represented as 10, and thus the century of birth would need to be reflected in some other way, so countries came up with ad hoc formulations such as persons born in the previous century having their serial numbers begin with 1 and the others with 2 or more. UINs that incorporate information on sex do it in the MM field (e.g., males would have MM range 1–12 and females 21–32) or in a series (beginning with 0–4 for male and 5–9 for female, as in South Africa). Some countries have a single-digit solution, such as even serial numbers for males and odd for females (or vice versa). A few countries originally included an indicator of race and religion (South Africa, France) but currently lave this blank, constant, or unused. In some countries (e.g., Mexico, Slovakia) individuals have multiple personal identification numbers because there are multiple registration systems (e.g., birth, voter, health) given the lack of a designated primary UIN. Austria has a unique UIN system that is a unified but complex formulation of multiple identifiers for a single individual in various systems as a sophisticated way of ensuring privacy. Almost without exception, the last digit (or in some cases, last two digits, e.g., France, Turkey) is a checksum. A description of more than 70 countries’ UIN systems is provided in Appendix A. STRUCTURED VERSUS RANDOM UINS Widespread deployment of UINs provides a convenient constancy, sequence, and organization to the millions of records that a CRS or CIS may hold, as well as a tool to link the two systems. The structures of record management have evolved as computational environments advance—from flat files to indexed files and finally to normalization techniques and database structures. Some countries issue multiple official personal identifying numbers. Depending on the legislation, a person can have a birth registration number (BRN) and the folio number for the record in the civil register attached to their identity, as well as a UIN created when a national identity card is issued and a voter registration number. Although a UIN should remain the same throughout a person’s life and beyond (for reasons of succession), the number of the identity credentials may change. UINs fulfill two essential roles: to be commonly recognizable and easy to recall and write and to be a computational device that establishes uniqueness and through that provide a bridge between various systems, each consisting of millions of records but capable of isolating information on the same individual. There is rising awareness of how intelligent UINs can be used for profiling and the role they play in identity abuse and theft. This has lead to an ongoing global debate on whether personal details should be included in the UIN. One of the cases that triggered this debate was the 2014 data breach in South Korea when its CIS was compromised. The country is likely to spend millions of dollars over the next decade to overhaul its national CIS. In the meantime, since 2016, citizens can request an immediate change of their UIN by providing a court order. Another aspect of this debate was the case of South Africa. One digit was reserved to indicate race (7 types were specified). Since 1994, this digit has been a static 8 or 9. In the case of the French Institut National de la Statistique et des Études Économiques code, the digit for religion or ethnic group is now used to indicate sex. Several countries are also debating whether sex should continue to be part of a UIN. 10 I NTEGRATING U NI Q U E I DEN T I F I CATI O N N U MBERS IN C IV IL R EGIST R AT ION Practical challenges can affect the efficient use of UINs. In manual systems, spelling errors occur, and records are not always legible. A commonly encountered problem in including date of birth in countries with weak institutions and low birth registration rates is that an individual’s actual date of birth may be unknown. In these cases, it is common to assign 0101YY as the birth date, although practical difficulties may arise from this. Similarly, if the personal identifier includes location-specific codes (e.g., registration office, province, district, town), a problem arises if an individual moves to another part of the country. With increasing mobility and migration worldwide, this element may be problematic and could, for example, affect a person’s ability to vote in local and national elections. Approximately 20 percent of UINs worldwide incorporate location- related codes. Appendix A provides the details of the number structure for 71 countries. Most numbers include information about the individual such as date of birth or location and are therefore longer than would be required if a random number had been used. Only 7 of these countries (China, India, Indonesia, Japan, Mexico, Nigeria, and Pakistan) have populations larger than 100 million. For the vast majority of countries, this means that a random number and check sum digit does not need to be any longer than 10 digits and many countries could restrict it to 8 or 9. The average for the 71 countries included in Appendix 1 is 11 digits (figure 2). Figure 2. Unique Identification Numbers: Average Number of Digits 16 14 12 Number of Countries 10 8 6 4 2 0 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 Unique Identity Number (UIN)—number of digits One of the most elaborate UINs in use is in the People’s Republic of China, which contains 18 digits and includes the full date of birth (YYYYMMDD) and six digits for province and location. To some extent, such over-coding can be justified because of the large population and decentralized organization. A randomly assigned UIN provides independence from the shortcomings described above, especially those related to date of birth and location. Random numbers can be made more compact than structured UINs. For date of birth, for example, MM uses only 1 to 12, leaving 88 positions unused, and similarly for DD, the maximum use is 1 to 31, leaving 69 positions unused. U IN St ru ct u r es —A n ov e rv i e w of e x ist i n g e xpe rie nces 11 Table 1. Unique Identification Number (UIN) Elements Characteristic Advantages Disadvantages Cannot be accurately determined if date 1 Date of birth Separate serial number can be assigned daily of birth is not known Separate serial number can be assigned per 2 Location Problematic if individual changes location location Serializes births Difficult to preassign without linking to 3 Serial number Provides a control when combined with 1 or 2 location Can be pregenerated Must be generated centrally and cannot 4 Random number Can be assigned offline be generated offline Preserves privacy 5 Checksum Checks correctness of other UIN digits Increases UIN length by one or two digits 6 Sex Optimizes search Can violate privacy Other traits (religion, Violates privacy and adds to risk of 7 Optimizes search ethnicity, race) profiling of groups Random numbers are preferable as a means of enhancing data security and privacy and make systemic profiling and identity theft based on specific characteristics (say females born after 1985) extremely difficult. India has been able to settle on a 12-digit personal identifier. Of this, the middle 10 digits (capable of representing 1 billion) are purely random. In the first digit, 2 numerals are reserved, leaving 8 to be randomly used. Thus, even if the population size were to reach 2 billion (it was 1.3 billion in 2017), only approximately 20 percent of the numbers would be used, providing a limited set from which to select well- spaced out random numbers. The last (twelfth) digit is a checksum, which is especially important when random numbers are used. Random numbers need to be generated centrally using tested, trusted random number–generating algorithms and tools. In the case of the Indian system (called Aadhaar), a person’s name, gender, date of birth, address, (optionally) mobile number and email, and biometrics (10 fingerprints, two iris scans, and a photo) are recorded locally, and each record is communicated automatically to a central repository. After uniqueness is checked for using biometrics, the unique 12-digit Aadhaar number is generated and sent to the address of the registering individual, although random numbers can also be pregenerated and assigned. With the evolution of CISs, some countries have developed fairly sophisticated authentication systems when the identity credential is used. For example, Austria’s CIS entails electronic keys, which are different for each application for the same individual. This facilitates more complete separation of information, ensuring greater data security and privacy. CHECKSUM MODELS The checksum is an important element of a UIN, whether it is structured (intelligent) or random. When a UIN is typed, there are many chances for errors (e.g., juxtaposition, misreading, typing errors). Checksums apply a mathematical calculation to the digits and arrive at a single digit that would have changed if such an error was made. Thus, the error will become apparent when the checksum is typed. The Luhn system for checksums, also known as the modulus 10 or mod 10 algorithm, has been in wide use for credit cards for many years. IBM scientist Hans Peter Luhn created and patented it in 1960. It is 12 I NTEGRATING U NI Q U E I DEN T I F I CATI O N N U MBERS IN C IV IL R EGIST R AT ION specified in International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC) standard 7812–1. It is not intended to be a cryptographically secure hash function,2 being designed to protect against accidental errors and not malicious attacks. Most credit cards and many government identification numbers use this algorithm as a simple method of distinguishing valid numbers from mistyped or otherwise incorrect ones. Two other checksum models are also in use: the Verhoeff algorithm (1969) and the Damm algorithm (2004). The Verhoeff algorithm was the first decimal check digit algorithm and detects all single-digit errors and all transposition errors involving two adjacent digits. The Damm algorithm is a check digit algorithm that detects all single-digit errors and all adjacent transposition errors and improves upon the Verhoeff algorithm. INTERNATIONAL STANDARDS At the time of this publication, there was no specific international standard that regulated or contained recommendations for assignment of UINs. Several international standards apply to the role and use of UINs as an authentication tool, but these assume the existence of an electronic identity card and digital platform for this purpose, such as credit cards or bank cards in the financial sector. The ISO has a special working group under ISO/IEC Joint Technical Committee 1 SC17 (identification and cards) that regulates the issuance of cards and security devices for personal identifiers. With a proliferation in recent years of cards that allow for some degree of authentication of a person’s identity, the schema has been significantly expanded, with details provided under ISO standard 7812–1. Challenges remain to be resolved that could make it possible to combine payment cards with national identification cards issued through CISs. Other international standards options are Open ID Exchange (for password sign-on) and the Electronic Identification and Trust Services Regulation of the European Union (for interoperability). IN SUMMARY ƒƒ There are three models for generating UINs • Structured—starting with YYMMDD, could be followed by 3 or 4 unique digits that are serialized or random. These can only be generated centrally for the country. • Office or location based—starting with XXXXXX—province + district + center code, followed by 2 or 3 unique digits that are serialized or random. These can be generated locally at each center. • Random—to be generated centrally. These are considered good for privacy because they do not reveal age, location, sex, and other personal characteristics. Random numbers are generated using a computer system. It is possible to pregenerate and distribute them to a registration center only if the number does not contain any identifying characteristic such as date of birth. ƒƒ Structured and random number schemes are used, but current trends and research favor random number–based UINs. 2 A hash function is any function that can be used to map data of arbitrary size to data of fixed size. The values that a hash function returns are called hash values, hash codes, digests, or simply hashes. One use of a hash function is a data structure called a hash table, widely used in computer software for rapid data lookup. U IN St ru ct u r es —A n ov e rv i e w of e x ist i n g e xpe rie nces 13 4. UINS—USE CASES This section reviews practices of assigning UINs and when and how they can be assigned. If a UIN is issued at the time of birth registration, all birth registration centers must have the capacity to issue UINs online and offline. Specific guidance is provided to countries that might face different constraints, especially related to computer connectivity that might hinder UIN generation, availability, and assignment. UINs are crucial for individuals, the state, and organizations that provide services that depend on them for efficient distribution of services and benefits. Two challenges that most countries share are determining when such a number should be assigned and what form it should have. In addition to a person’s biographical data, the importance of a UIN cannot be overstated when it comes to linking CRSs and CISs. The age when a person’s data are enrolled in a CIS varies from country to country, and it is common practice to issue an identity card at the same time. Biometric information is also generally captured at enrollment. In cases in which a BRN and UIN are both issued, one must take precedence because having multiple numbers is cumbersome for the individual and inefficient for the state. A law or decree should define how and when this happens. Having a UIN from birth enhances the credibility of the CIS records and facilitates the de-duplication process i.e. ensuring one record and one UIN per person. HOW TO LINK BRNS AND UINS3 There are four options for linking a BRN in the CRS to UIN into the CIS: ƒƒ If the UIN is generated by the CRS, the BRN becomes the UIN, and the CRS sends it to the CIS, which creates a record with other relevant CRS details for subsequent use. The CIS might also require UIN generation 3 The following discussion assumes that the UIN will be digital and maintained in an electronic database, which presupposes that the CR and CI processes are digital. This is often not the case for CR in particular (https:// openknowledge.worldbank.org/handle/10986/28310). U IN S —US E Cases 15 for records that do not originate from the CRS (e.g., for permanent residents or naturalized persons). All such numbers should be generated using the same logic used to generate UINs for the CRS. ƒƒ If the UIN is generated by the CIS, a BRN can be generated in the CRS along with the child’s biographic information. The CRS will send a request to the CIS, which generates and issues a UIN that is then recorded in the CRS. It is recommended that the CRS inform the authority that issues the BRN, so that one system may reference the other. This operation requires online connectivity, or information will tend to get lost. ƒƒ Generate a separate encrypted token (CRS or CIS can do), which can be followed by step 2 above, the difference being that the CRS and CIS records for the same individual can be connected under extremely controlled conditions and authorization. Records in either system will refer to the encrypted token. Only upon decryption can the reference can be made available to another system for authentication purposes. ƒƒ If biometric information about the individual is not available at birth, work-arounds are often suggested (special use of infant biometric information or link to mother’s biometric information), which requires higher-resolution systems (expensive) or additional processes (complex). RECOMMENDED UIN STRUCTURE AND POINT OF ISSUANCE To minimize unnecessary complexities, it is preferable to keep the UIN short and unambiguous and to adhere to privacy requirements. It is also recommended that a stand-alone random number with checksum be used for the UIN. Whether the CRS should generate the UIN and pass it on to the CIS or the CRS should inform the CIS of the birth and the CIS generate the number and send it to the CRS for incorporation in the child’s record must be determined. In ideal circumstances, near-universal institutional birth rates and full connectivity would allow for online issuance of the UIN that can be assigned at birth and electronically recorded before the infant leaves the medical facility (IADB 2011b). With good connectivity, a mobile registrar could also do this. Such arrangements exist but are rare. One example is a process in the Aadhaar that links it to birth registration that has been implemented successfully in the state of Haryana. Figure 3 shows the steps involved (Aardhaar 2014). In low-income countries, there is a need for off-line options. There are at least two options. Both assume that UINs are centrally generated: Option 1 ƒƒ The central office issues blocks of random UINs that the local registrar can assign to individuals upon registration. ƒƒ The local office registers births, assigns UINs, and issues birth certificates with the UIN; these could be issued in the form of machine-readable stickers to be appended to the certificate and scanned at the local office. ƒƒ The local office documents and periodically transmits information about the birth registration and UIN details assigned to Lavrentieva and Palacios (2018) lay out the individuals to the central office through steps required to move from paper to digital secure networks or by physically transferring CR. See also, Harbitz and Gregson (2016). electronic files (e.g., USB drive). 16 I NTEGRATING U NI Q U E I DEN T I F I CATI O N N U MBERS IN C IV IL R EGIST R AT ION Option 2 ƒƒ Births are registered at the local office, and the application is transmitted to the central office. ƒƒ The central office issues birth certificates with UINs printed on the certificate and sends them back to the local office in batches. ƒƒ The local office notifies the parents to come and collect the birth certificates. In both cases, back-end administrative processes (housekeeping) and protocols will be required to keep track of stickers used and UINs deployed. Figure 3. Aadhaar Linking to Birth Registration U IN S —US E Cases 17 Figure 4. Unique Identification Number (UIN) Structure with Pregenerated UIN Stickers • Long • Reveals identity • Generated post-registration Y Y M M D D L O C N G S S S S C UIN structured or random N R R R R R R R R R R C • Short • Maintains privacy • Can be pre-generated Unique identification number (UIN) A challenge to an off-line system is the possibility that a birth will be registered multiple times. Although duplication can eventually be eliminated using a CI biometric deduplication process, until that time, multiple identities can be inadvertently or deliberately created. To avoid this, biographic matching algorithms can be applied, but this will not completely resolve the problem. An additional check is to use the UIN of the mother or guardian. Unless the biometrics of the parent are captured during the off-line birth registration, the system will have to rely on the security of the credential and the local registrar.4 The advantage of the first option is that the individual need not make two trips or be contacted twice during the registration process, as is the case in the second option, but if problem is discovered during the application process (e.g., a duplicate registration), the individual will have to be contacted to make the necessary corrections or just to be informed that the UIN that had been assigned was not valid. Many people may not be easy to contact and may think that the UIN that the child carries is valid and active. Most systems will continue to be hybrid—using off-line and on-line registration. One practical solution is to have UINs pregenerated at a central office and distribute stickers with numbers and barcodes (figure 4). Independent of who issues the UIN, the system must be capable of generating additional UINs, for example, for permanent residents or naturalized citizens who might not be in the CRS or CIS. With a few exceptions, this strategy for generating UINs should work in every location, including remote unconnected ones, with minimum intervention, although it will require all civil registry locations to have adequate stocks of pregenerated UIN stickers, which can be estimated using vital statistics or population projections. 4 An offline biometric reader could verify that the credential belongs to the parent if it held the biometrics on a chip or a barcode on the card. 18 I NTEGRATING U NI Q U E I DEN T I F I CATI O N N U MBERS IN C IV IL R EGIST R AT ION IN SUMMARY ƒƒ UINs based on random numbers and a checksum digit are preferred over structured UINs. They can be shorter and afford greater privacy and data security. ƒƒ Random number–based UINs can be pregenerated (on stickers) and assigned even at remote, unconnected birth registration locations and can thus be universally assigned at birth. This way, the CRS and CIS can share the UIN. ƒƒ This process may be tested and, if found feasible and cost-effective, considered for country implementations. U IN S —US E Cases 19 5. SUMMARY OF DIGITAL PRACTICES FOR LINKING CRS AND CIS This section provides a description of the common digital practices for linking CRS and CIS, and the architecture that needs to be in place to link and synchronize verification processes between CRS and CIS. Once the CRS and a CIS have been harmonized, the framework can be used by functional systems for authentication and verification. Any architecture will need to take into consideration that there may be existing systems that will need to be brought together. Privacy and protection of personal data must be taken into consideration. Refer to Appendix B for the architecture diagrams. Every country has existing systems for a CRS (manual or ICT based) and in many cases also a CIS, which is more likely to be ICT based. Their respective existing architectures are a good starting point to best understand how they can be built upon and any changes incorporated in reasonable time and at a reasonable cost. A country looking to upgrade systems could refer to the table below for a rapid assessment of the system situation, depending on how each shaded cell is filled with ‘yes’ or ‘no’. To determine whether the existing CRS and CIS of a country are adequate, the first step is to determine whether the systems meet the country’s objectives based on the national legal and regulatory framework. When changes and upgrades are planned, it is important to have a formal understanding of the underlying architecture of the existing systems and processes and to know the age of the software—whether it was recently implemented or is at the end of its life. In a broad sense, software architecture tends to fall into one of three categories: ƒƒ Highly interconnected (or interlinked), designed in the 1990s (spaghetti oriented) ƒƒ Highly layered monolith, designed in the 2000s (lasagna oriented) ƒƒ Parceled, small, sharable modules called microservices, designed in the 2010s (ravioli oriented)5 5 The Italian food analogy for software architecture is credited to Dr. Ruben Verborgh of ID Lab Research, Massachusetts Institute of Technology and has commonly been used in the technical description of architectures since 2015. S u mma ry of Digi ta l P r act i c es for Lin k i n g CRS and CI S 21 Table 2. Existing Country Identification System Components Component Characteristics CRS CIS Commercial over-the- Software product with added customization Yes / No Yes / No counter system Software Bespoke software development based on specific Tailor-made system Yes / No Yes / No system study Integrated system Various modules of the system work together Yes / No Yes / No Characteristics Interoperable External linkage possible with other systems Yes / No Yes / No Harmonized CRS and CIS work together and are coupled Yes / No Manual data Data can be scanned or entered and stored Yes / No Yes / No Data can be converted to current data Legacy data Yes / No Yes / No Data structures No enhancement is required to existing data Current data Yes / No Yes / No structures Note: CRS, civil registration system; CIS, civil identification system. Once the underlying architecture has been defined, the following questions must be answered. ƒƒ If the existing identification software is inadequate, what changes are required to have the CRS and CIS running in a harmonized manner? ƒƒ How shall the changes be implemented in the CRS and CIS, respectively and jointly, to ensure that the two systems are harmonized? ƒƒ How can a long-term, robust approach be taken to ensure that a continuous framework is available for such changes in the future? The microservice approach to designing software applications consists of developing services that are independently deployable and much more scalable given the modular approach. Each service runs in its own process, is built around business capabilities, and is independently deployable using fully automated deployment machinery. Every service can be written in different programming languages and use different data storage technologies so that different teams or departments can also manage them. Hence there are many advantages to using this type of architecture: ƒƒ Each microservice is small, and it is therefore easier for the user to describe and the developer to understand. ƒƒ Each microservice can be deployed independently, so it is easier to deploy new versions of services on a regular basis. ƒƒ It is much more scalable, and each microservice’s management can be assigned to a different team and can be worked on at different times and independently, which means that joint teams of developers and users can work more effectively together. ƒƒ Microservices can gradually replace older versions of the functionalities of monolithic software, eliminating the need to discard an older system and switch to a newer one all at once, which is risky. ƒƒ Microservices might be more appropriate to government organizational structures and the hierarchy of offices that are typically involved in CRS and CIS. 22 I NTEGRATING U NI Q U E I DEN T I F I CATI O N N U MBERS IN C IV IL R EGIST R AT ION ƒƒ In the case of CIS, it is common to consolidate the operation at the central level of the organization. Capture and matching of biometrics need to be considered separately. ƒƒ Microservices are the most appropriate way to envisage applications running on the web over a variety of devices such as mobile phones. An important aspect of such an architecture is that microservices are connected to one another or grouped together using an application program interface. An example of this approach is the Aadhaar system, which has further incorporated an hourglass architecture that separates confidential identity-related elements from applications in the public domain. The Aadhaar system architecture document is provided as a reference for additional details (2014). PROPOSED ARCHITECTURE MINIMUM LAYER In general, the overview of a country’s identification systems can be depicted as shown in figure 5. Figure 5 shows that the country identification ecosystem should consist of two centers and a node for functional registers, shown here as the CRS, CIS, and functional systems. As can be seen in the architecture diagrams, each center, or node, will have an interface that can be web based and implemented on mobile phones, tablets, or desktops. These are then connected to an application program interface gateway, with each authorized user having an access token that is authenticated at an authorization server that issues internal web tokens that provide an authorized interface with the microservices (discussed in detail below). The CRS itself will have additional capabilities (e.g., death registration, marriage registration) not discussed here. Similarly, the CIS would have capabilities that have been covered only in summary in this section. There could be many functional systems (or registers), each being a comprehensive application with requisite capabilities, but of importance here is the functionality of referring to the CRS or CIS for authentication and verification. Although this is technologically feasible, it needs to address complex requirements of data security and individual privacy. This in turn would depend on the legal framework in each country, although an acceptable scenario consists of a functional system sending identity data (biometric and biographic) for verification and the CIS or CRS returning a YES or NO in response. Any data exchange is temporary. The entity sending the request and the one responding would be identified using public key infrastructure, for example, and all data exchange would be fully encrypted. Such a system of data validation, transmission, and verification of the exchanging entities is currently implemented for checking passports and visas at borders, and the 191 member states of the International Civil Aviation Organization (ICAO) have agreed to its standardization. This is further discussed in the next section on standards. MICROSERVICES CRITICAL TO A CRS CRSs should have the following essential set of minimum microservices features to be comprehensive. Birth Registration—This report provides a generic description of birth registration, but each country needs to implement it in accordance with its own rules and regulations, based on the country’s laws. In general, birth registration will need to be recorded under three different scenarios: ƒƒ Within the time limit ƒƒ Late ƒƒ Exceptionally late (delayed) S u mma ry of Digi ta l P r act i c es for Lin k i n g CRS and CI S 23 Vital Events—In general, vital events are birth, death, fetal death, adoption, marriage, divorce, recognition, legitimation, annulment of marriage, and judicial separation of marriage. UIN Generation and Assignment—As discussed in an earlier section, a randomly based UIN is preferable for security and privacy protection reasons. This microservice would consist of at least two important features: • Generation of UIN—generating a random number, computing a checksum digit, and optionally, sending a batch of such pregenerated numbers to individual birth registration centers. • Assignment of UIN—assigning a UIN to a birth registration, reporting it back, and recording it in the CRS at birth. This approach requires ICT facilities and connectivity and would require protocols for addressing registrations outside of offices that are not connected. Digital Verification and Issuance of Birth Certificate—Birth registration requires that an authorized person print a birth certificate upon receipt of an authentic request, although a fully digital process of receiving a request, checking a birth record, and digitally returning details as printed on a birth certificate or sending a YES or NO response is also required. Figure 5. Overview of a Country’s Identification System • Voters roll CRS • Land registry • Passport Civil Registration • Vehicle registry System Verification Common UIN • Education Uniqueness • Health Legal identity check • Benefits • Police • Judiciary ID documents Physical identity • Banking transactions biometrics CIS • Payments Functional Civil Identification • Taxes systems System • Utilities • Others Authentication Identification systems and their relationship UIN, unique identification number. Biographic Matching and Adjudication—This is also described in an earlier section and addresses a situation in which the CRS and CIS (and functional registers) are not harmonized and a search might have to be performed to select likely identity matches. The matching might then need to be adjudicated manually to ensure an exact match. Legal Identity Search Taxonomy—This is envisaged as an advanced matching technique that countries are likely to find extremely useful. In simplified terms, the process would consist of creating taxonomies of a country’s citizenship or nationality rules. The vital events of an individual could then be compared with such taxonomies to support decision-making, which the administration or the judiciary could perform. The process needs to be accompanied by a minimum set of supporting back-end microservices, which could consist of the following. 24 I NTEGRATING U NI Q U E I DEN T I F I CATI O N N U MBERS IN C IV IL R EGIST R AT ION Anonymization—To maintain individual privacy, CR data need to be anonymized under full authorization and as part of data security safeguards before being entered into the vital statistics system. Data Dictionary Management—The data structures underlying the CRS and CIS need to be flexible, and it must be possible to modify them. Examples were given in earlier sections. Identity Lifecycle Management—There are properties that might be associated with or dissociated from an identity, such as having a UIN assigned at the time of birth and having it activated or having a record added in the CIS and having it coupled with the CRS. At the time of death, the UIN might need to be de-activated. Refer to Card Lifecycle Management below for a description of properties. Vital Event Process Configuration—This has also been described in an earlier section and consists of the steps that are needed to complete the recording of a vital event and define the entities involved with each step and the processes of authorization. CRS Master Configuration—Also described in an earlier section, this consists of important aspects that make the CRS flexible and appropriate to a country’s situation and provide a better recording and reporting environment. Housekeeping—This consists of activities such as back-up, restoring, and archiving. These would best be defined by the system administration of the individual systems and subsystems. This is not intended to be an exhaustive list of features of a CRS. Such a list can be made only after a country-specific study and specific recommendations that will help link the CRS and CIS. MICROSERVICES ASSOCIATED WITH A CIS Biometrics and its application to CI is a specialized and vast subject, and although it is not intended to be part of this report, it is worth mentioning at least a few microservices associated with a CIS because many countries might already have a CIS in place that is ICT based. Creating identification and linking to CRS—Creating an identification by importing one from the CRS might be a typical new feature for an existing CIS. This will need to be implemented in lieu of an existing module or microservice that involves creating a new identification in the CIS. This will be critical for harmonizing the CRS and CIS, although the CIS might still require creation of fresh identifications (e.g., resident foreign nationals), which have no corresponding record in a CRS. The processes need to be defined to ensure the system is consistent and does not leave room for loopholes. Biometrics—CISs typically have well-defined capabilities that capture and import biometrics and, if required, adjudication. For CI, the most commonly deployed biometric modes include fingerprints and facial and iris recognition. Multi-biometrics is usually recommended today, because it increases reliability, provides flexibility, and is no longer prohibitively expensive. Biometric One-to-Many Identification—This is the process by which physical uniqueness can be established using biometrics and involves checking one person’s records against all other records. This is usually a one- time (or periodic) exercise and helps de-duplicate. For performing one-to-many identification, vendors provide an automatic biometric identification system, although in the case of multimodal biometrics (in which more than one kind of biometrics is used, e.g., fingerprints and iris recognition), additional structures for authentication are required. An important feature is the ability to deploy multiple algorithms from multiple vendors, providing the best technical results and a degree of vendor independence. Biometric One-to-One Verification—This is usually a simple one-step process used for identity authentication. S u mma ry of Digi ta l P r act i c es for Lin k i n g CRS and CI S 25 PROTECTION OF PERSONAL DATA AND PRIVACY CONSIDERATIONS More than 80 countries in Europe, Latin America and the Caribbean, Asia, and Africa have adopted comprehensive data protection laws that prohibit disclosure or misuse of information about private individuals. The United States does not have a baseline law for protection of personal data. ƒƒ There should be a stated purpose for all data collected. ƒƒ Information collected cannot be disclosed to other organizations or individuals unless specifically authorized by law or consent of the individual. ƒƒ Records kept on an individual should be accurate and up to date. ƒƒ There should be mechanisms for individuals to review data about them, to ensure accuracy. This may include periodic reporting. ƒƒ Data, other than for the purpose of CR and CI, should be deleted when it is no longer needed for the stated purpose. ƒƒ Transmission of personal information to locations where “equivalent” personal data protection cannot be ensured is prohibited. ƒƒ Some data are too sensitive to be collected except under extreme circumstances (e.g., sexual orientation, religion). IN SUMMARY ƒƒ Every country has an existing CRS, which is the starting point for introducing features proposed in this study, and many have a CIS. ƒƒ System architecture has evolved, and the current paradigm includes diverse web-based microservices grouped together using application program interfaces. ƒƒ The most efficient way to link CRSs and CISs can be to disaggregate services into microservices, bring them under an architectural umbrella, and add new microservices to provide the desired features in a coherent manner. ƒƒ The overall proposed architecture consists of three interconnected centers: CRS, CIS, and functional registers. ƒƒ Information privacy and data security are of paramount importance for identification systems, so a framework for related standards must be taken into consideration at the design phase when linking CRS and CIS. ƒƒ Refer to Appendix B for the architecture diagrams. 26 I NTEGRATING U NI Q U E I DEN T I F I CATI O N N U MBERS IN C IV IL R EGIST R AT ION REFERENCES References Aadhaar Technology and Architecture. 2014. “Principles, Design, Best Practices and Key Lessons.” UIDAI Technology Center. https://www.scribd.com/document/355985352/AadhaarTechnologyArchitecture-March2014-pdf. Harbitz, Mia and Kendra Gregson, eds. 2015. “Toward Universal Birth Registration.” Inter-American Development Bank. https://publications.iadb.org/bitstream/handle/11319/7165/Toward-Universal-Birth-Registration-A-Systemic- Approach-to-the-Application-of-ICT.pdf?sequence=4&isAllowed=y. IADB (Inter-American Development Bank). 2011a. “Civil Registration and Identity Management.” http://www.iadb.org/ en/topics/government/civil-registration-and-identity,4032.html. ———. 2011b. “Uruguay Strengthens Civil Registry.” http://www.iadb.org/en/news/webstories/2011–09–19/uruguay- strengthens-civil-registry,9539.html ———. 2013. “Dictionary for Civil Registration and Identification.” https://publications.iadb.org/handle/11319/3679. Lavrentieva and Palacios 2018. How can low income countries move to universal, digital birth registration linked to a foundational ID? (forthcoming) UNICEF (UN Children’s Fund). 2013. “A Passport to Protection: A Guide to Birth Registration Programming.” New York: UNICEF. http://www.unicef.org/protection/files/UNICEF_Birth_Registration_Handbook(1).pdf. UN Statistics Division. 2014. “Principles and Recommendations for a Vital Statistics System, rev. 3.” http://unstats. un.org/unsd/Demographic/standmeth/principles/M19Rev3en.pdf. Zelenkovski, Mihajlo. 2017. “The Financial Impact of Interoperability.” International Electrotechnical Commission, International Organization for Standardization, International Telecommunication Union. https://www. worldstandardscooperation.org/2017/05/24/the-financial-impact-of-interoperability/. Re fe re nces 27 ANNEXES Appendix A: Description of Unique Identification Numbers (UINs) of More Than 70 Countries Unique Identity Numbers (UIN) – Country Schemas Digit Characteristics Country Name Digits 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 Last 1 Albania NID/CIN 10 Y Y M M D D GS S S > > > > > > > > C Date Of Birth Serial Check 2 Argentina DNI 11 Nc G S S S S S S S S > > > > > > > C Nat Gender Serial Check 3 Australia TFN 9 P P P X X S S S S > > > > > > > > Place (Random) Group Serial CCR + 4 Austria 12 R R R R R R R R R R R > > > > > > C ssPIN Random Check 5 Bahrain 9 Y Y M M R R R R > > > > > > > > > C Month Of Birth Random Check 6 Belgium NRM 11 Y Y M M D D S S S > > > > > > > C C Date Of Birth Serial Check Check Bosnia & 7 UMCN 13 D D M M Y Y Y P P S S S > > > > > C Herzegovina Date Of Birth Place Serial Check 8 Bulgaria UCN 10 Y Y M M D D Gc S S > > > > > > > > C Date Of Birth Serial Check 9 Chile RUN 9 S S S S S S S S > > > > > > > > > C Serial Check 10 China 18 P P P P P P Y Y Y Y M M D D S S S C Place Date Of Birth Serial Check 11 Columbia NUIP 10 1 R R R R R R R R > > > > > > > > C Fixed Random Check 12 Croatia OIB 12 R R R R R R R R R R R > > > > > > C Random Check Czech Rep & 13 RC 10 Y Y M M D D S S S > > > > > > > > C Slovakia Date Of Birth (Gender In Mm) Serial Check 14 Denmark CPR 10 D D M M Y Y S S S > > > > > > > > C Date Of Birth (Gender & Century In Mm) Serial Check 15 Estonia IK 11 Gc Y Y M M D D S S S > > > > > > > C Gender Date Of Birth Serial Check 16 Finland PIC 11 D D M M Y Y Gc S S S > > > > > > > C Anne x es 29 30 Unique Identity Numbers (UIN) – Country Schemas Digit Characteristics Country Name Digits 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 Last Date Of Birth Gender Serial Check 17 France INSEE 15 G Y Y M M P P P P P S S S > > > C C Gender Month Of Birth Place Serial Check 18 Gambia NIN 11 D D M M Y Y P Nc S S > > > > > > > C Date Of Birth Place Nat Serial Check 19 Guatemala CUI 13 P P S S S S S S S S S S > > > > > C Place Serial Check Steur 20 Germany 11 R R R R R R R R R R > > > > > > > C IdNr Random Check 21 Greece New ID 8 P P S S S S S > > > > > > > > > > C Place Serial Check 22 Hong Kong HKID 8 NC S S S S S S > > > > > > > > > > C Nat Serial Check 23 Hungary PIN 11 GC Y Y M M D D S S S > > > > > > > C Gender Date Of Birth Serial Check 24 Iceland Kennitala 10 D D M M Y Y R R Gc > > > > > > > > C Date Of Birth Random Gender Check 25 India Aadhaar 12 R R R R R R R R R R R > > > > > > C 2–9 Random Check I NTEGRATING U NI Q U E I DEN T I F I CATI O N N U MBERS IN C IV IL R EGIST R AT ION 26 Indonesia 16 P P P P P P D D M M Y Y R R R > > C Place Date Of Birth Random Random Check 27 Iran 10 S S S Y Y M M D D > > > > > > > > C Serial Date Of Birth Check 28 Ireland PPS-No. 9 R R R R R R R P P > > > > > > > > > Random Place Mispar 29 Israel 9 P R R R R R R R > > > > > > > > > C Zehut Place Random Check Unique Identity Numbers (UIN) – Country Schemas Digit Characteristics Country Name Digits 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 Last Codice Y Y M D D 30 Italy 16 N N N N N N P P P P > > C fiscale Name Consonents Date Of Birth Place Place Check My 31 Japan 12 R R R R R R R R R R R > > > > > > C Number Random Check PHH/ Y Y M M D D 32 Kazakhstan 12 S S S S S > > > > > > C RNN Date Of Birth Serial Check 33 Kenya NIN 9 S S S S S S S S S Serial 34 Kuwait 12 P Y Y M M D D S S S S > > > > > > C Place Date Of Birth Serial Check Personas D D M M Y Y 35 Latvia 11 Gc S S S > > > > > > > C Kods Date Of Birth Gender Serial Check Asmens Y Y M M D D 36 Lithuania 11 Gc S S S > > > > > > > C Kodas Gender Date Of Birth Serial Check BIRP/ 37 Macau 8 Nc S S S S S S > > > > > > > > > > C BIRNP Nat Serial Check 38 Macedonia UMCN 13 D D M M Y Y Y P P Gc S S > > > > > C Date Of Birth Place Gender Serial Check NRIC- Y Y M M D D 39 Malaysia 12 P P R R R > > > > > > C MyKAd Date Of Birth Place Random Check 40 Mauritius UIN 13 D D M M Y Y S S S S S S > > > > > C Date Of Birth Serial Check 41 Mexico CURP 18 X X X X Y Y M M D D Gc P P X X X S/X S Surname Etc. Date Of Birth Gender Place Surname Etc. Serial/Letter 42 Moldova IDNP 13 D D M M Y Y Y P P S S S > > > > > C Date Of Birth Place Gender Serial Check 43 Montenegro JMBG 13 D D M M Y Y Y P P S S S > > > > > C Date Of Birth Place Gender Serial Check Anne x es 31 32 Unique Identity Numbers (UIN) – Country Schemas Digit Characteristics Country Name Digits 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 Last 44 Netherlands BSN 9 R R R R R R R R > > > > > > > > > C Random Check New 45 NHI 7 X X X S S S > > > > > > > > > > > C Zealand Letters Serial Check 46 Nigeria NIN 11 R R R R R R R R R R > > > > > > > C Random Check 47 Norway Birth No. 11 D D M M Y Y S S S > > > > > > > C C Date Of Birth Serial Check 48 Pakistan NIC 13 P P P P P S S S S S S S > > > > > C Place Serial Check 49 Poland PESEL 11 Y Y M M D D S S S Gc > > > > > > > C Date Of Birth Serial Gender Check 50 Romania CNP 13 Gc Y Y M M D D P P S S S > > > > > C Gender Date Of Birth Place Serial Check Codice 51 San Marino 5 S S S S S ISS Serial 52 Scotland CHI 10 D D M M Y Y Gc S S > > > > > > > > C Date Of Birth Serial Check I NTEGRATING U NI Q U E I DEN T I F I CATI O N N U MBERS IN C IV IL R EGIST R AT ION 53 Serbia JMBG 13 D D M M Y Y Y P P S S S > > > > > C Date Of Birth Place Gender Serial Check 54 Singapore NRIC 9 Nc Y Y S S S S S > > > > > > > > > C Nat Year Of Birth Serial Check 55 Slovakia Birth No. 10 Y Y M M D D S S S > > > > > > > > C Date Of Birth Serial Check 56 Slovenia UMCN 13 D D M M Y Y Y P P GC S S > > > > > C Date Of Birth Place Gender Serial Check South Y Y M M D D 57 ID 13 S S S S X Nc > > > > > C Africa Date Of Birth Serial Fixed Nat Check Unique Identity Numbers (UIN) – Country Schemas Digit Characteristics Country Name Digits 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 Last South Y Y M M D D 58 RIN 13 Gc S S S S Nc > > > > > C Korea Date Of Birth Serial Nat Check 59 Spain DNI 9 R R R R R R R R > > > > > > > > > C Random Check 60 Sri Lanka 10 Y Y S S S S S S S Nc > > > > > > > C Year Of Birth Serial Nat Check 61 Sweden PN 10 Y Y M M D D S S Gc > > > > > > > > C Date Of Birth Serial Gender Check AHV/ Y Y D D D 62 Switzerland 11 N N N Gc Nc > > > > > > > C AVS Name Date Of Birth Gender Nat Check 63 Taiwan 10 P S S S S S S S S > > > > > > > > C Place Serial Check 64 Thailand PIC 13 Nc P P P P S S S S S X X > > > > > C Nat Place Serial Other Check TC 65 Turkey 11 R R R R R R R R R > > > > > > > C C kimlik Random Check 66 Ukraine IIN 10 D D D D D Gc S S S > > > > > > > > C Date Of Birth Serial Check United Arab 67 15 F F F Y Y Y Y R R R R R R R > > > C Emirates Fixed Year Of Birth Random Check United 68 NINO 9 X X S S S S S S X Kingdom Group Serial Folio United 69 States of SSN* 9 P P P X X S S S S > > > > > > > > > America Place (Random) Group Serial 70 Venezuela NUI 9 S S S S S S S S > > > > > > > > > C Serial Check 71 Vietnam CMND 9 P P P S S S S S > > > > > > > > > C Place Serial Check Anne x es 33 Appendix B: Architecture Diagrams of a Minimum Layer for Civil Registration and Civil Identification Systems REST API at each microservice • In time Birth registration • delayed • exceptionally delayed Other vital events UIN generation and assignment Authorization server Birth certificate & digital query access token Biographic matching & adjudication JWT Legal identity search taxonomy Client API gateway JWT access token UI Anonymization – Send to vital statistics Data structure management Identity lifecycle management Civil registration system (CRS) overview – typical microservices Vital event process configuration API – Application programming interface CRS master configuration REST – API – Representational state transfer API JWT – JSON web token (open standard RFC 7519) Housekeeping JSON – JavaScript object notation UI – User interface JWT processing at each microservice 34 I NTEGRATING U NI Q U E I DEN T I F I CATI O N N U MBERS IN C IV IL R EGIST R AT ION REST API at each microservice Import ID from CRS Create ID in CIS (only if not in CRS) Capture/import biometrics Biometric adjudication Authorization server Multi-biometric verification access token Biometric one – to – one verification JWT Client Biometric one – to – many identification JWT API gateway Monolithic systems – to be disaggregated access token UI Card personalization Card issuance Card lifecycle management Civil registration system (CRS) overview – typical microservices Card secure transport & storage API – Application programming interface REST – API – Representational state transfer API Housekeeping JWT – JSON web token (open standard RFC 7519) JSON – JavaScript object notation UI – User interface JWT processing at each microservice Anne x es 35 • Voters roll • Land registry • Passport • Vehicle registry • Education Authorization • Health server • Benefits • Police access token • Judiciary JWT • Banking • Payments Client • Taxes • Utilities API gateway access token • Others UI JWT REST API at each microservice Digital verification of identity – CIS Civil registration system (CRS) overview – typical microservices Digital verification of vital event – CRS API – Application programming interface REST – API – Representational state transfer API Housekeeping JWT – JSON web token (open standard RFC 7519) JSON – JavaScript object notation JWT processing UI – User interface at each microservice 36 I NTEGRATING U NI Q U E I DEN T I F I CATI O N N U MBERS IN C IV IL R EGIST R AT ION Appendix C: Outline of System Architecture Report OVERVIEW ISO/IEC/IEEE 42010:2011 defines requirements on the description of system, software and enterprise architectures. It aims to standardize the practice of architecture description by defining standard terms, presenting a conceptual foundation for expressing, communicating and reviewing architectures and specifying requirements that apply to architecture descriptions, architecture frameworks and architecture description languages. The description of ISO/IEC/IEEE 42010 is based upon the standard published in 2011. TERMINOLOGY ISO/IEC 42010 defines the following terms: ƒƒ Architecting – process of conceiving, defining, expressing, documenting, communicating, certifying proper implementation of, maintaining and improving an architecture throughout a system’s life cycle (also referred as “designing”) ƒƒ Architecture – fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution ƒƒ architecture description (AD) – work product used to express an architecture ƒƒ architecture description language (ADL) – any form of expression for use in architecture descriptions ƒƒ architecture framework – conventions, principles and practices for the description of architectures established within a specific domain of application and/or community of stakeholders ƒƒ architecture viewpoint – work product establishing the conventions for the construction, interpretation and use of architecture views to frame specific system concerns ƒƒ architecture view – work product expressing the architecture of a system from the perspective of specific system concerns ƒƒ concern – interest in a system relevant to one or more of its stakeholders. A concern pertains to any influence on a system in its environment, including developmental, technological, business, operational, organizational, political, economic, legal, regulatory, ecological and social influences. ƒƒ model kind – conventions for a type of modeling. An architecture view consists of multiple models, each following one model kind. ƒƒ Stakeholder – individual, team, organization, or classes thereof, having an interest in a system Anne x es 37 Conceptual Model – Architecture Description In the ISO/IEC/IEEE 42010 conceptual model, an architecture description: ƒƒ expresses an architecture ƒƒ identifies a system of interest ƒƒ identifies 1 or more stakeholders ƒƒ identifies 1 or more concerns (about the system of interest) ƒƒ includes 1 or more architecture viewpoints and 1 or more architecture views ƒƒ includes 0 or more correspondence(s) ƒƒ includes 0 or more correspondence rules ƒƒ includes 1 or more architecture rationales The conceptual model states that an architecture description must have a stakeholder, system of interest, identified concern(s), architecture viewpoint(s), architecture view(s) and architecture rationale(s). It states that an architecture description may have correspondences and correspondence rules. Conceptual Model – Architecture View In the ISO/IEC/IEEE 42010 conceptual model, an architecture view: ƒƒ is part of an architecture description ƒƒ is governed by exactly 1 architecture viewpoint ƒƒ addresses one or more concerns held by the stakeholder(s) ƒƒ is composed of 1 or more architecture models ƒƒ Conceptual Model – Architecture Viewpoint [edit] ƒƒ In the ISO/IEC/IEEE 42010 conceptual model, an architecture viewpoint: ƒƒ is part of an architecture description ƒƒ frames 1 or more stakeholder concerns (about the system of interest) ƒƒ governs exactly 1 architecture view ƒƒ is composed of 1 or more model kinds An architecture viewpoint is in effect a specification for an architecture view—the architecture view must to conform to its architecture viewpoint. Conceptual Model – Concern In the ISO/IEC/IEEE 42010 conceptual model, a concern: ƒƒ is held by 1 or more stakeholder(s) in the system of interest; ƒƒ is addressed by an architecture view; ƒƒ is identified by an architecture description; ƒƒ is framed by an architecture viewpoint; 38 I NTEGRATING U NI Q U E I DEN T I F I CATI O N N U MBERS IN C IV IL R EGIST R AT ION Conformance to ISO/IEC/IEEE 42010 ƒƒ ISO/IEC/IEEE 42010 defines four cases of conformance to the standard: ƒƒ architecture description (AD) ƒƒ architecture viewpoint ƒƒ architecture framework ƒƒ architecture description language (ADL) Architecture Description An architecture description is an artifact describing the architecture for some system of interest. In ISO/ IEC/IEEE 42010, system refers to man-made and natural systems, including software products and services and software-intensive systems. Architecture descriptions have a variety of uses. Per ISO/IEC/IEEE 42010, an architecture description conforming to the standard is expected to include: ƒƒ identification and overview information of the architecture being expressed; ƒƒ identification of the system stakeholders and their concerns; ƒƒ definitions for each architecture viewpoint used in the architecture description and a mapping of all concerns to those viewpoints; ƒƒ an architecture view and its architecture models for each architecture viewpoint used; ƒƒ correspondence rules and correspondences and a record of known inconsistencies among the architecture description’s required contents; ƒƒ architecture rationale (explanation, justification, reasoning for decisions made about the architecture being described). ISO/IEC/IEEE 42010 organizes an architecture description into multiple architecture views. An architecture view addresses one or more concerns held by stakeholders of the system being described. An architecture view describes the architecture of the system of interest in accordance with the rules and conventions defined in its architecture viewpoint. Each architecture view must have an architecture viewpoint. Architecture Viewpoint A viewpoint formalizes the idea that there are different ways of looking at the same system. Viewpoints have a long history in software and systems engineering, dating back at least to the 1970s in Ross’ Structured Analysis. In ISO/IEC/IEEE 42010, viewpoints play an integral part of architecture descriptions, architecture frameworks and ADLs, and may also be separately specified. In ISO/IEC/IEEE 42010 an architecture viewpoint is expected to: ƒƒ frame one or more concerns held by the stakeholders about the system of interest ƒƒ establish the conventions for one kind of architecture view. Viewpoint conventions include modeling languages, notations, model kinds, design rules, and/or modelling methods, analysis techniques and other operations on views. Viewpoints establish the rules of conformance for views (such as well-formedness, completeness, interpretability). In framing the stakeholder concerns, a viewpoint defines the means by which architecture views of that type address these concerns. Anne x es 39 ISO/IEC/IEEE 42010 requires an architecture viewpoint to include: ƒƒ identified stakeholder concerns that are framed by the viewpoint (to be addressed by views of that type) ƒƒ an identified set of stakeholders holding these concerns ƒƒ the model kinds used (means of representing the relationships/information e.g. N-squared) ƒƒ languages, notations, conventions, modelling techniques, operations used on these model kinds An architecture viewpoint should include: ƒƒ techniques used to create, interpret and analyse ƒƒ correspondence rules and means of checking consistency ƒƒ heuristics, metrics, patterns, examples Architecture Framework An architecture framework establishes a common practice for using, creating, interpreting, and analyzing architecture descriptions within a particular domain of application or stakeholder community. ISO/IEC/ IEEE 42010 formalizes a framework as a set of predefined, interconnected viewpoints. An architecture framework conforming to the standard includes: ƒƒ identification of the relevant stakeholders in the domain; ƒƒ the concerns arising in that domain; ƒƒ architecture viewpoints framing those concerns and ƒƒ correspondence rules integrating those viewpoints. Frameworks conforming to the standard often include processes, methods, tools and other practices beyond those specified above. Architecture Description Language ISO/IEC 42010 requires an architecture description language (ADL) conforming to the standard to specify: ƒƒ the concerns framed by the ADL ƒƒ the typical stakeholders who hold these concerns ƒƒ the model kinds implemented by the ADL that frame these concerns ƒƒ any correspondence rules linking those model kinds An architecture description language may specify one or more architecture viewpoints, but need not have any either. The concerns framed by an ADL are not necessarily aligned with those addressed by an architecture framework. The suitability of the ADL for use with an architecture framework will depend on how well it frames the concerns in the framework and its viewpoints. 40 I NTEGRATING U NI Q U E I DEN T I F I CATI O N N U MBERS IN C IV IL R EGIST R AT ION Examples of architecture frameworks: Zachman’s information systems architecture framework, UK Ministry of Defence Architecture Framework (MODAF), The Open Group’s Architecture Framework (TOGAF), Kruchten’s 4+1 view model, Siemens’ 4 views method, Reference Model for Open Distributed Processing (RM-ODP) and Generalized Enterprise Reference Architecture and Methodology (GERAM). ISO/ IEC JTC1/SC7 WG42 has developed a working catalog and classification of architecture frameworks. Examples of architecture description languages: Architecture Analysis & Design Language, Acme, ArchiMate, BPMN, Rapide, SBC Architecture, SysML, UML, Wright, and the five viewpoint languages of RM-ODP. Anne x es 41 worldbank.org/id4d