The documentation is licensed under a Creative Commons Attribution 4.0 International License.

What is a Foundational Identity?

A Foundational Identity System provides individuals with a unique identifier issued by the government, enabling identity assertion and verification across multiple services. Unlike functional IDs, which are designed for specific use cases such as healthcare, finance, and social services, foundational IDs serve as a universal framework that various sectors can leverage.

MOSIP empowers governments to build secure, interoperable, and inclusive foundational ID systems. With robust privacy protections and modular architecture, MOSIP ensures individuals have control over their personal information while enabling seamless access to public and private services.

Below is a diagram illustrating the relationship between Foundational IDs and Functional IDs.

• Foundational ID systems provide individuals with a unique, government-recognized identifier for identity verification. They help de-duplicate records, authenticate individuals, and verify identity attributes.

• Functional IDs are sector-specific and designed for specific use cases such as healthcare, finance, social protection, education, and voting. These IDs can leverage the foundational ID system to ensure accuracy, efficiency, and seamless service access.

This structure helps create a secure and interoperable identity ecosystem for both public and private services.

What is MOSIP?

The below image illustrates MOSIP as a modular, open-source identity platform designed for secure and scalable digital identity systems. It highlights key features such as interoperability, open standards, security, and privacy, ensuring seamless integration without vendor lock-in.

Additionally, it showcases MOSIP’s core functionalities, including ID issuance, identity verification, and lifecycle management, making it a flexible solution for national ID implementations.

Privacy and Security

The image below highlights MOSIP’s security and privacy principles, emphasizing its "Security by Design" and "Privacy by Intent" approach.

These principles align with MOSIP’s Privacy and Security framework.

MOSIP Modules

The image below illustrates the various MOSIP Modules:

• Pre-Registration – Enables users to provide basic demographic data and book appointments for registration.

• Registration – Facilitates registration of an individual, for availing a Unique Identification Number (UIN) by providing demographic and biometric data (fingerprint, iris, and face photograph) in online/offline mode.

• Registration Processor – Generates a Unique Identification Number (UIN) post a regulated process and enriches data.

• ID Authentication – Provides demographic and biometric authentication services, including Yes/No and E-KYC services, enabling access to a myriad of rights and services.

• Resident Services – Allows residents to update and monitor usage of their IDs, giving individuals control over their own identity.

• Partner Management – For onboarding, managing, and integrating external partners (relying parties) within the MOSIP ecosystem.

MOSIP Ecosystem

MOSIP collaborates with ecosystem partners to develop tailored identity solutions for each country.

The diagram below illustrates the MOSIP Ecosystem, highlighting how various components integrate with the MOSIP Platform to deliver a comprehensive ID solution.

MOSIP's Offerings

The diagram illustrates MOSIP’s Key Offerings in ID Lifecycle Management and ID Authentication, highlighting two main processes:

1. ID Registration Process

• Step 1: Online Pre-Registration – A resident submits demographic details online.

• Step 2: Biometric Enrollment – The resident visits a registration center for biometric data collection.

• Step 3: ID Issuance – After successful validations and processing, the resident receives a Unique Identification Number (UIN).

2. ID Authentication Process

• An ID holder requests authentication to access services.

• Authentication is performed via an authentication partner equipped with biometric or digital verification tools.

• The MOSIP Authentication System validates the identity, providing eKYC or token-based responses for service access.

These offerings enable secure, scalable, and modular identity management and authentication solutions.

Building a National ID System Using MOSIP

Countries can leverage MOSIP as the base identity platform and configure, customize, and extend it to build systems just the way needed.

The image below depicts how MOSIP provides the base layer to build a national ID platform.

MOSIP is designed, developed, and implemented based on core principles that drive its effectiveness and adaptability. These principles ensure that MOSIP remains open, secure, interoperable, scalable, and inclusive, allowing it to meet the needs of diverse users and support the creation of accessible, digital identity systems globally.

• Modular: Identity systems that serve unique needs with mutually exclusive technology bundles. Rather than a stand-alone solution offered to every adopting nation, MOSIP technology allows user countries to build custom workflows. Each functionality is built with independent microservices to provide flexibility and control.

• Open Source: Trusted & transparent technology, adhering to global standards. An open-source code repository, available on GitHub, encourages contributions from user communities and offers governments control over their ID systems. MOSIP also works with the Institute of Electrical and Electronics Engineers (IEEE), governments, and a commercial ecosystem to arrive at common Open Standards and Protocols. This makes MOSIP easy to integrate, interoperable, cost- and time-efficient.

• Vendor-Neutral: Offering the ability to integrate with a wide range of compliant technologies. In the setting up of a foundational digital ID system, it is critical that the platform, biometric devices, and system integrators, are able to integrate and function smoothly. Vendor-neutrality, maintained through the MOSIP Partner Programme and the establishment of the MOSIP Marketplace offers countries the ability to choose and change their technology solutions at any time and save precious time and financial resources.

• Private and Secure: Ensuring every individual is in control of their data. MOSIP is designed to keep data security and privacy in mind, ensuring that data is protected in flight and rest. Cryptographic encryption and zero knowledge architecture ensure that no sensitive data is stored on the MOSIP system. Governments of adopting nations have sovereign control over their ID systems, and data sharing only happens with the individual’s consent.

• Scalable: Designed to accommodate growth and changing needs. The platform is designed to be scalable, accommodating the growth of users and services. It can cater to large populations, support various regions, and integrate with multiple systems securely, without compromising performance. Its modular architecture allows it to easily expand and adapt to new requirements, making it suitable for both small-scale deployments and national level rollouts. This scalability ensures that MOSIP can serve diverse countries and populations with varying technological and infrastructural capabilities.

• Human-Centric: Technology for all. We aim to develop technology that can cater to diverse and varying requirements around the world, yet being human-centric. The team at MOSIP constantly strives to learn from on-ground experiences in adopting nations, to understand their context-specific requirements and provide adaptable solutions.

Welcome !🌍

What is MOSIP?

MOSIP’s modular and adaptable architecture gives adopting countries full ownership and flexibility to customize the system to their needs. As a transparent and human-centric initiative, MOSIP encourages global collaboration, welcoming contributions from developers, technology partners, and research institutions worldwide.

Our global team of experts and advisors supports countries throughout the adoption and implementation of their digital ID systems, ensuring that they function as a common governance infrastructure for inclusive and secure digital transformation.

Our Mission & Objectives

At MOSIP, our mission is to empower governments worldwide to build and own secure, inclusive, and scalable digital identity systems. As an open-source, modular platform, MOSIP provides a strong foundation for nations to establish their digital public infrastructure, ensuring privacy, security, and interoperability.

Our key objectives include:

• Enabling countries to develop secure, citizen-centric ID systems by providing a robust and fully functional framework.

• Offering flexibility and customization so that nations can tailor the platform to their specific needs.

• Ensuring privacy, security, and confidentiality of individuals’ data, following global best practices.

• Upholding transparency, security, and human-centric technology to foster trust and reliability.

• Supporting global collaboration through open-source contributions, partnerships, and an ecosystem of technology providers, researchers, and developers.

• Providing a scalable and accessible solution that serves populations from a few thousand to several hundred million.

By fostering an open and collaborative ecosystem of technology partners, researchers, and developers, MOSIP enables nations to build robust, adaptable, and future-ready identity solutions tailored to their unique needs.

Why MOSIP?

1. Modular

MOSIP’s mutually exclusive technology bundles allow adopting nations to build custom workflows instead of relying on a fixed system. Each functionality is designed as an independent microservice, ensuring flexibility and control over digital ID implementation.

2. Open Source

3. Vendor-Neutral

4. Secure and Private Design

5. Cost-Effective

MOSIP provides a zero-cost platform for adoption and licensing, enabling governments and organizations to build a foundational digital ID system under Mozilla’s Public License 2.0. The automation of processes within MOSIP minimizes implementation costs, allowing countries to test and establish effective digital infrastructure efficiently.

6. Human-Centric

We aim to develop technology that can cater to diverse and varying requirements around the world. The expert team at MOSIP constantly strives to learn from on-ground experiences in adopting nations, to understand their context-specific requirements and provide unique and adaptable solutions.

7. Inclusive

MOSIP is committed to inclusivity, ensuring technology remains accessible to all, regardless of gender, race, or economic status. Our ongoing collaborations with universities, research institutions, and field teams help refine our technology for unrestricted accessibility. Innovations like Inji, a digital wallet mobile app, empower residents to access their digital identities even in remote, low-connectivity areas.

Explore Key Areas

MOSIP Security Practices

This document provides a comprehensive analysis of security implementations across multiple levels. Additionally, it clearly delineates the boundaries of responsibility between MOSIP and the countries implementing the system.

Within this document, we have categorized security practices into 'Internal Practices' and 'Operational Protection'.

Internal security practices are integrated into the MOSIP development lifecycle to build security within the system from the ground up. These include rigorous threat modeling, secure coding practices, comprehensive code reviews, and continuous vulnerability assessments to ensure that potential risks are identified and mitigated early. By embedding these security measures during development MOSIP fosters a proactive security culture that not only minimizes vulnerabilities but also supports a robust defense strategy throughout the system's lifecycle.

On the other hand, operational security practices include firewall rules, intrusion detection systems, continuous monitoring, and incident response strategies. These measures focus on maintaining the security and integrity of the system during its operational phase, addressing runtime threats and ensuring compliance with best practices. Operational practices are outside of MOSIP development stage and to be taken up by the implementing countries.

Internal Practices

Internal security practices encompass measures such as security requirement elicitation, design, adherence to the MOSIP Principles, Platform development, static and dynamic code analysis, dependency scanning, code signing, and vulnerability management. These practices ensure that potential threats are identified and mitigated early in the development lifecycle.

Platform Design

MOSIP's fundamental architecture and design incorporate high levels of privacy and security.

(Table to be updated soon)

Development and Release Practices

This section details the measures taken during the development, testing, and release phases to ensure maximum security. Multiple checks are enforced at each stage through the use of various tools, tests, and scans. Key practices include:

Static Application Security Testing (SAST)

Static Application Security Testing (SAST) is a cornerstone of our security strategy. Tools like SonarCloud are used to perform in-depth code analysis during the development phase, identifying vulnerabilities such as SQL injection, cross-site scripting (XSS), and insecure coding practices. SAST provides developers with real-time feedback, enabling them to address security flaws early, thereby reducing the cost and effort of remediation later in the software lifecycle. These tools integrate seamlessly into our CI/CD pipelines, ensuring that security is addressed continuously and early. Dependency scanning tools like Dependabot, CodeQL, and others further enhance this layer of protection by monitoring and updating vulnerable dependencies.

• Sonar Cloud - Development Phase - SonarCloud is integrated with Github actions, offering developers actionable insights directly within the workflow. By highlighting security hotspots and technical debt, it enables teams to prioritize and address critical issues efficiently.

• CodeQL (Java and Python) - Development Phase - CodeQL performs semantic code analysis, enabling the detection of complex vulnerabilities

• Github Dependabot (Vulnerability assessment and Version upgrade suggestions) - Development Phase - Dependabot simplifies the process of updating dependencies by creating pull requests with the necessary upgrades reducing manual effort and ensuring the codebase remains secure against known vulnerabilities. Its integration into GitHub workflows ensures timely updates and fosters a proactive approach to dependency management.

• Open source compliance scanning - Ensures that all open-source components in use comply with licensing requirements and security best practices. This scanning helps in identifying potential legal or security risks associated with third-party libraries. Automated tools are used to track, analyze, and flag issues related to incompatible or outdated licenses, ensuring smooth and compliant project operations.

• Github scan - Provides robust scanning capabilities integrated directly into GitHub repositories. It includes features such as secret scanning, dependency graph analysis, and vulnerability alerts, helping developers proactively detect and fix security issues within their workflows.

• Data Breach Detector - It is a prodcution grade tool/script which goes through the DB and utilizes Deduce library to find out anomalies in various places such as names, address or numbers in plaintext etc.

Dynamic Application Security Testing (DAST)

DAST focuses on identifying security vulnerabilities in a running application by simulating real-world attack scenarios. Unlike SAST, which examines static code, DAST tests live applications, analyzing responses to detect flaws such as authentication issues, session management vulnerabilities, and exposure of sensitive data. Tools like Burp Suite Professional and ZED Attack Proxy (ZAP) are leveraged to conduct automated and manual penetration tests. These tools allow testers to evaluate application behavior under various conditions, ensuring robust protection against runtime threats. By integrating DAST into the release process, vulnerabilities can be identified and mitigated before applications are deployed into production.

• Burp Suite Professional : This tool is used for automated and manual penetration testing . It provides features such as intercepting proxy, web vulnerability scanner, and advanced debugging capabilities. Burp Suite enables testers to identify vulnerabilities like SQL injection, cross-site scripting (XSS), and insecure session management. It also supports extensions for customized scanning and integrates seamlessly into security workflows.

• ZED Attack Proxy: This tool is used for finding vulnerabilities in web applications during the development and testing phases.

Release Practices

Release practices are essential for ensuring the security, authenticity, and traceability of software releases. Here is an overview of the components used in MOSIP releases.

• Image Signing: ASC (ASCII-armored PGP) signing is typically used to ensure the authenticity and integrity of software artifacts, including Docker images, by attaching a digital signature. When signing software images, MOSIP uses the private key to sign the image, and users can verify the signature using the corresponding public key.

• JAR (Java Archive) Signing is the practice of signing Java archive files to ensure that the contents of the JAR haven't been tampered with and to provide a way to verify the source of the file. This is currently not implemented in MOSIP.

Operational Practices

These recommendations provide a robust framework to ensure the security and integrity of production systems for MOSIP implementing countries, helping to mitigate risks and enhance overall cybersecurity posture.

• SBI Compliant Devices: Ensure that all devices used in the production environment are compliant with the latest Secure Biometric Interface (SBI) standards to ensure a highest level of security.

• Trusted Platform Module: A Trusted Platform Module (TPM) is a specialized chip on a local machines that stores cryptographic keys specific to the host system for hardware authentication. The private key is maintained inside the chip and can't be extracted out. By leveraging this security feature every individual machine would be uniquely registered and identified by the MOSIP server component with it's TPM public key.

• Compliance Tool Kit: MOSIP Provides Compliance Tool Kit (CTK) to help the device vendors to check if their products comply with SBI specifications.

• Access and Audit Logs: Enables detailed access and audit logging for all critical systems and services in the production environment.

• Patch Management (Host/Machines): Implement a robust patch management policy to ensure that all production systems are up-to-date with the latest security patches.

• Safe Data Centers: Ensure that data centers housing production systems are designed and operated with a focus on security, availability and operational safety.

• International standards: Stay compliant on international standards such as ISO/IEC 27001, NIST Cybersecurity Framework, and relevant national regulations. Better to validate the compliance using third party assessments.

• Ensuring Data Protection: Enforce robust data protection measures to safeguard sensitive information at rest and in transit.

• Consent-Based Data Handling: Ensure that data is only collected, processed, and stored with the explicit consent of the individuals it pertains to, in accordance with privacy laws and regulations.

• Regular Security Audits: Perform regular security audits to assess the effectiveness of security measures and identify potential vulnerabilities in production systems.

• Principle of Least Privilege: Ensure that users and systems are granted only the minimum level of access necessary to perform their tasks, reducing the risk of accidental or malicious misuse.

• Rate Limiting: Implement rate limiting to protect services from abuse, such as brute force attacks or denial-of-service (DoS) attempts.

MOSIP's fundamental architecture and design incorporate the highest levels of privacy and security.

Security by design

Key security features:

• Integration with trusted applications only.

• Fraud avoidance - association of authentication only with specific transactions.

• Misuse prevention - user can lock or unlock their authentication.

• Virtual ID and Tokens to prevent identity theft.

• All data sent out of MOSIP will be digitally signed.

• All incoming data will be signed by the respective entity.

• Any data sent to a relying party will be encrypted.

• Protection against internal attacks with every record in DB protected with integrity.

• Centralized key management.

• All API's are protected with OAUTH 2.0.

Privacy by intent

Key privacy features:

• Minimal data with selective disclosure on a need-to-know basis.

• Sensitive data protected (not stored or logged in clear form).

• Consent support – the user decides who can receive what credentials & what attributes.

• No search on the database (You can find a record only if you know the ID).

• Clear segregation of Biometric & Demographic data.

• De-centralised ID usage and data (cannot profile based on usage).

• Users are not limited to one permenant ID - Virtual ID.

• All relying party gets a privacy enabled tokens to prevent profiling across transactions. Permenant ID is never shared.

• Supports Wallet based decentralized ID issuance and usage.

• Face data is not sent to ABIS for deduplication.

With the mission of empowering lives all over the world, MOSIP continues to take steps towards being an inclusive platform. Ongoing collaborations with global universities, research organizations, and strong on-ground teams have sharpened our focus on developing technology that is unrestricted by gender, race, and economic status. Additionally, technology features allow individuals to access services with digital identities through multiple channels, and even in remote areas with low connectivity, ensuring no one is left behind.

Some mechanisms through which the MOSIP platform supports inclusivity is illustrated below:

• Introducer Support For The Undocumented

  • The Introducer concept in MOSIP allows individuals without formal identity documents to be enrolled into the digital identity system. A trusted and verified Introducer, such as a community leader or an authorized individual, vouches for the person’s identity. This ensures that marginalized populations, including refugees, nomadic groups, and those lacking paperwork, can still obtain a digital identity. By enabling inclusion through trust-based verification, the Introducer mechanism helps governments provide identity access to all, promoting social and financial inclusion.

• Multi-Language Support for Linguistically Diverse Communities

  • Multi-language support in MOSIP enhances inclusivity by ensuring individuals can interact with digital identity systems in their native or preferred languages. This helps bridge linguistic barriers, making identity services accessible to diverse populations, including those with limited literacy in dominant languages. By supporting localization, MOSIP enables governments to customize the platform to suit national needs, fostering greater adoption, trust, and usability. This approach aligns with the goal of creating inclusive and equitable digital identity ecosystems worldwide.

• Biometric Exception Handling for Individuals with Difficult-to-Capture Biometrics

  • MOSIP’s biometric exception handling ensures that individuals with difficult-to-capture biometrics, such as worn fingerprints or missing biometrics like finger or eyes, are not excluded from digital identity systems. When biometrics cannot be collected, MOSIP provides alternative methods, such as marking the biometric modality as an exception and capturing a photograph as evidence, thereby allowing inclusive identity registration for all. This approach ensures that elderly individuals, manual laborers, and persons with disabilities can still obtain a secure and verifiable identity, reinforcing inclusivity and accessibility in digital identity.

• Enabling In-Home registration with Android Registration Client
• Ensuring Gender Inclusivity with MOSIP's GenderMag Collaboration
• Multi-Modal Verification with Inji and eSignet

Through its inclusive mechanisms, MOSIP continues to push boundaries in providing accessible and equitable digital identity solutions. By focusing on universal access and adaptability, MOSIP ensures that everyone—regardless of their background, location, or physical limitations—can benefit from the services enabled by the platform. These efforts reflect MOSIP's commitment to creating a more inclusive and sustainable digital future for all.

MOSIP is designed with the following architectural principles. These architecture principles are core to the development of the system's features and have a great influence on how and why specific software design patterns are used within.

• Data Privacy

• No Vendor Lock-in

• Open Standards

• Async/ Offline First

• Commodity Computing

• Fault tolerant

• Manageable

• Secure By Default

Architecture Overview

The diagram below provides an architectural overview, visually representing the components of the MOSIP Identity framework and its associated technology stack.

High Level Functional Architecture

The High Level Reference Functional Architecture serves as a blueprint outlining the system's high-level functioning and interactions, providing a structured framework.

Please find below the two sandbox environments available for your use.

Collab

Collab is our development integration environment that has QA-tested dockers deployed. Our partners and contributors can use this to build on the platform or integrate with the QA-certified version of the latest platform code.

Regular nightly builds from engineering are deployed here and this environment is used for continuous development.

Synergy

Synergy is our stable environment where the latest released version of the MOSIP platform and applications are deployed for partners to integrate and test.

At MOSIP (Modular Open Source Identity Platform), we are committed to building a secure, interoperable, and privacy-centric identity system for nations worldwide. MOSIP adheres to internationally recognized standards in biometric authentication, security, cryptography, privacy, and interoperability to ensure the highest levels of security, efficiency, and compliance.

1. Why Standards Matters?

By following these global standards, MOSIP ensures that our identity platform is: ✅ Secure – Protecting citizens’ data from cyber threats. ✅ Privacy-First – Upholding the highest standards of data protection. ✅ Scalable & Future-Ready – Enabling nations to build robust digital identity programs. ✅ Interoperable – Seamlessly integrating with digital identity solutions worldwide.

2. Our Adherence to Global Standards

1. Biometric Standards for Secure Identity Verification

To ensure seamless biometric interoperability and security, MOSIP follows:

• ISO/IEC 19794 – Standardized biometric data formats for fingerprints, iris, and facial recognition.

• IEEE P3167 (DRAFT) – Strengthening the trustworthiness of biometric devices and their captured data while ensuring overall data security.

2. Security & Cryptography Standards for Data Protection

To guarantee robust data security and encryption, MOSIP aligns with:

• NIST Cybersecurity Framework – Provides guidelines for IT security evaluation and risk management.

• RSA, EC, JSE – Implements industry-standard cryptographic algorithms for secure encryption and data integrity.

3. Open Standards for Seamless Interoperability

To enable effortless integration with national and global identity ecosystems, MOSIP adopts:

• OAuth 2.0 / OpenID Connect – Providing secure and scalable authentication mechanisms.

• REST, OpenAPI Standards – Ensuring standardized communication across different platforms.

• JMS (Java Message Service) & WebSub – Facilitating real-time messaging and event-driven architecture.

4. MOSIP Standards

Technologies and Tools Used

This page lists all the technologies used in building MOSIP. Free and open-source software with clear long-term support availability has been chosen. For a deployment, certain choices can be replaced with other free or commercial options.

This reference blueprint provides a comprehensive vision for designing and implementing a Digital ID-led DPI infrastructure. It outlines how foundational identity systems can be leveraged alongside key DPI components, enabling various use cases across both the public and private sectors. The blueprint is structured in layers of technology, governance, and service delivery, ensuring scalability, inclusivity, and compliance with legal frameworks.

Below is an explanation of its core components and their roles within the ecosystem.

1. Unique Digital Identity

At the core of the system is the Unique Digital Identity, which establishes a singular, definitive identity for every individual. This digital identity forms the backbone of all operations, ensuring secure identification and verification across diverse domains.

2. ID Project Custodian

The ID Project Custodian, whether a designated authority, ministry, or department, oversees this infrastructure. This custodian is crucial for maintaining governance, regulatory compliance, and operational efficiency, ensuring that all identity services align with national policies and frameworks.

3. Infrastructure Layer

Supporting the ecosystem is a robust Infrastructure Layer, consisting of cloud infrastructure and connectivity. The cloud ensures scalability, resilience, and the ability to manage large volumes of identity data. The connectivity layer ensures the system's accessibility, making it functional in both urban and remote areas.

4. Foundational ID Platform

At the heart of the blueprint is the Foundational ID Platform, a centralized framework for issuing and managing foundational IDs. This platform underpins all identity-related services, ensuring secure identity handling and enabling core functions like registration, lifecycle management, verification, authentication, and e-KYC (Electronic Know Your Customer). These services are essential for building trusted interactions across all sectors.

5. Core & Augmented Services

Now that we have established the core layers to anchor trust, we can expand functionality through augmented services, such as eSignature capabilities. These enable secure digital transactions and help governments transition from traditional in-person signatures. These added features enhance the system's utility, which is especially crucial for enabling paperless workflows.

6. Accessibility and Inclusivity

To ensure widespread adoption and accessibility, the system features a Multi-Channel Access Layer that enables interaction through web, mobile (Apps, USSD), and physical interfaces(QR). This design ensures inclusivity by accommodating individuals with diverse backgrounds and varying levels of technological proficiency, to interact with the system effortlessly.

7. Consent Management, Data Exchange and Payments

In addition to its core and augmented services, consent management and data exchange capabilities are crucial for advancing digitization and digital development. These capabilities facilitate the regulated sharing of information across both public and private platforms. Moreover, the integration of payment systems adds significant value to Government-to-People (G2P) use cases. Additionally, data exchange can be further enhanced through the use of Verifiable Credentials.

8. Use Cases and Benefits Delivery

This blueprint is designed to act as a catalyst for seamless service delivery and impactful use cases across both the private and public sectors. It is essential to involve the private sector in the digitization process, as it plays a key role in enabling services such as banking, e-commerce, and telecommunications, thereby streamlining operations. In the public sector, this blueprint enhances service delivery in areas like social welfare, healthcare, taxation, and education, contributing to better governance and increased citizen engagement. By adopting an overall ID-led approach, it not only accelerates the adoption of digital identity but also ensures improved governance, streamlined operations, and enhanced citizen participation.

9. Legal and Regulatory Framework

Finally, the framework operates within a robust legal and regulatory environment, complying with key legislation such as the Data Protection Act, the Cybersecurity Act, and the Electronic Transactions Act. These laws safeguard data privacy and security, ensuring that the system operates transparently, trustworthy, and in full legal compliance.

Overview

The right to privacy is a fundamental right in many contexts. Privacy protection or preservation can be ensured in an application by adopting a privacy friendly design stance.

What is privacy and privacy protection?

Privacy takes many forms. From an identity system perspective, the confidentiality of identity information and anonymity when using the identity offers privacy.

Privacy design elements

MOSIP addresses privacy design at four levels.

1. Functional privacy

   • Selective disclosure

   • Anonymization

   • Need to know

   • Encryption

   • Tokenization

2. Security

   • Trusted applications

   • Access control

3. User centricity

   • User control

   • Consent

   • Usability

   • Inclusion

4. Transparency

   • Openness

   • Verifiability

   • Governance

The security of user data is given the highest priority in MOSIP. Data is protected in flight and rest using strong cryptographic techniques. All operations on decrypted data are done in memory.

Registration data flow

The below diagram represents a registration data flow system for biometric authentication and identity management.

1. Biometric Capture:

   • A biometric device captures and signs biometric data before sending it to the Registration Client (PK2). Then registration client verifies the signature

2. Registration & Encryption:

   • The Registration Client, running on the operator’s system, receives biometric data and securely encrypts it into packets.

   • The client always refers to Keycloak for authentication, ensuring that only authorized operators can access the system.
3. Data Processing & Storage:

   • The encrypted packets are transmitted to the Registration Processor, which processes and signs the data.

   • The processed data is then stored in the Object Store and ID Repository for further use.

4. Secure Storage of Biometric Data:
5. Hashed UIN Storage:

   • The UINs are hashed, encrypted, and stored in uin the table of mosip_idrepo DB. (K7.4)

6. Data Sharing & Policy Enforcement:

   • When encrypted biometric data needs to be shared, it is sent to ABIS for authentication.

   • The system consults the Partner/Policy Management System to verify partner details and enforce data-sharing policies.

   • Only partners who have registered and authenticated via Keycloak can access the Partner Management System, where they must subscribe to specific policies to receive data.

7. Demographic Data Storage:

   • Encrypted demographic data is stored in the Registration Processor Database. (K11)

8. Credential Issuance:

   • Encrypted resident data is shared with credential requestors and printers based on the subscribed policies. (K12)

9. Operator Authentication:

   • The Registration Client checks Keycloak to ensure that only authenticated operators can perform registrations.

10. Policy Validation for Data Transfer:

• Before transferring encrypted data to ABIS, partners, or credential requestors, the system refers to the Partner/Policy Management System to validate policies.

11. Partner & Policy Control:

• The Partner Management System is controlled by Keycloak, ensuring that only registered partners with valid credentials can subscribe to and enforce policies for data access. (11,12,13)

Datashare

Data shared with all partners like ABIS, Print, Adjudication, IDA, etc. is encrypted using partners' public key. Note that IDA is also a partner, however, a special partner in the sense that data is additionally zero-knowledge encrypted before sending to IDA (see the section below).

Zero-knowledge encryption

Encryption and sharing by Credential Service

1. Generate master symmetric encryption key K9.

2. Generate a 10,000 symmetric keys pool (ZKn). Encrypt each ZKn with K9 and store it in DB. (K12)

3. Randomly select one key from ZKn, and decrypt using K9.

4. Derive new key ZKn' = ZKn + UIN/VID/APPID.

5. Encrypt biometric templates and demographics.

   • BIO = encrypt(bio/demo with ZKn').

6. Encrypt ZKn (this is done to share ZKn with IDA).

   • ZKn-IDA = encrypt(ZKn with K22)

7. Share the following with IDA:

   1. ZKn-IDA

   2. BIO

   3. Random index (0 - 9999)

   4. SHA-256 hash of UIN/VID/APPID

Decryption by IDA

1. Generate master symmetric encryption key K18.

2. Decrypt data in Step 8 above using PK8.

3. Decrypt ZKn-IDA with K22 to get ZKn.

4. Encrypt ZKn with K18 and store it at a random index.

5. Bio-data is stored as is.

ID authentication flow

2. The authentication client further encrypts the auth request with the IDA-PARTNER public key.

CBOR Identity Data in QR Code

Tag: 169 (identity-data)

Data Item: JSON Object

Semantics: Identity Data of a Person in QR-Code

Version: 1.0.0

1. Introduction

This document specifies a generic data structure and encoding mechanism for storing the Identity Data of a registered person using any ID platform. It also provides a transport encoding mechanism in a machine-readable optical format (QR).

2. Rationale

Once a person is registered in an identity system, their data serves as the foundation for identification, granting them access to social benefits and government services. The level of assurance in this identification process varies depending on the authentication methods employed. Low assurance is achieved through basic identifiers like ID numbers, demographic data, passwords, or PINs. Conversely, higher assurance levels are attained through one-time passwords (OTP) and biometrics.

Among these methods, biometric-based authentication, such as facial authentication, offers the highest level of assurance as it assures the presence of the individual. While this is effective for online systems & personal phones where verification is conducted on a server or a personal device; offline authentication presents challenges in maintaining a similarly high level of assurance. The offline authentication mechanism should work for people with no phone.

For instance, in a cross-border scenario, remote areas often face significant internet connectivity issues. Even when internet access is available, server reliability may be inconsistent. In such circumstances, scanning a standard QR code containing the person's facial photograph and identity information, alongside assurance that the data is country-signed, provides an additional layer of security and affirmation for the countries involved.

Please note: The trust layers required to sync the country's key are beyond the scope of this document. We assume the app scanning the QR code already has the country's key to verify.

To tackle the aforementioned challenge, we propose a standard CBOR-based QR Code that involves embedding a low-resolution image of the person with a minimal demographic dataset within the QR code. This QR code would be digitally signed by the ID authorities (Issuer) and then printed on a physical card. Subsequently, the signed data within the QR code can be utilized for facial authentication. This approach also helps enhance interoperability. Note: It is essential to recognize that QR codes have limitations regarding size. We suggest leveraging CBOR Web Token (CWT) with ED25519/ECC keys to generate a smaller signature and more condensed data.

3. Semantics

Claim 169 represents a JSON Object that includes the following ID attributes, as outlined in the table. You can find an illustration of the ID structure contained within Claim 169, as stated below:

3.1 CBOR Map Structure Overview

Note: All the fields here are optional.

3.2 CBOR Map Structure Example

{
   "1":"COUN",
   "6":1665980929,
   "8":{
      "3":"dfd1aa976d8d4575a0fe34b96de2bfad"
   },
   "169":{
        "1": "11110000324013",
        "2": "1.0",
        "3": "EN",
        "4": "Peter M Jhon",
        "5": "Peter",
        "6": "M",
        "7": "Jhon",
        "8": "19880102",
        "9": 1,
        "10": "New City, METRO LINE, PA",
        "11": "peter@example.com",
        "12": "+1 234-567",
        "13": "US",
        "14": 2,
        "15": "Jhon Honai",
        "16": "03CBABDF83D068ACB5DE65B3CDF25E0036F2C546CB90378C587A076E7A759DFD27CA7872B6CDFF339AEAACA61A6023FD1D305A9B4F33CAA248CEDE38B67D7C915C59A51BB4E77D10077A625258873183F82D65F4C482503A5A01F41DEE612C3542E5370987815E592B8EA2020FD3BDDC747897DB10237EAD179E55B441BC6D8BAD07CE535129CF8D559445CC3A29D746FBF1174DE2E7C0F3439BE7DBEA4520CF88825AAE6B1F291A746AB8177C65B2A459DD19BD32C0C3070004B85C1D63034707CC690AB0BA023350C8337FC6894061EB8A714A8F22FE2365E7A904C72DEC9746ABEA1A3296ECACD1A40450794EDCD2B34844E7C19EB7FB1A4AF3B05C3B374BD2941603F72D3F9A62EAB9A2FDAEEEEC8EE6E350F8A1863C0A0AB1B4058D154559A1CD5133EFCF682ABC339960819C9427889D60380B635A7D21D017974BBA57798490F668ADD86DA58125D9C4C1202CA1308F7734E43E8F77CEB0AF968A8F8B88849F9B98B26620399470ED057E7931DED82876DCA896A30D0031A8CBD7B9EDFDF16C15C6853F4F8D9EEC09317C84EDAE4B349FE54D23D8EC7DC9BB9F69FD7B7B23383B64F22E25F",
        "17": 2,
        "18": [1,2],
}

4. IANA Considerations

4.1 Registry Contents

Claim Name: identity-data

Claim Description: Registering the claim for storing identity data of a person, which could be personally identifiable data (PII) mostly used in Foundational/National ID for cross-border interoperability.

Claim Key: 169

Claim Value Type(s): map

Change Controller: MOSIP

5. References

6. Author(s)

About Inji

In today's fast-paced, interconnected world, ensuring seamless access to essential services—such as healthcare, financial inclusion, global mobility, and social support has never been more critical. The need for trusted identity authentication and secure data exchange is at the heart of accessing these services.

To address this, Inji offers a transformative solution – enabling the secure issuance, digitalization, storage, exchange, and seamless verification of trusted data as verifiable credentials, through a comprehensive set of tools.

Inji, meaning "knowing" or "recognizance" in Korean, is evolving into a comprehensive digital credential stack with a strong focus on user empowerment. Inji simplifies the management and verification of credentials by providing secure solutions that work across multiple interfaces. It aims to streamline creating, sharing, and verifying all types of digital and physical credentials.

Overview

Identity Lifecycle Management refers to issuing and managing user identities in a given system. An individual can visit a registration centre to get a new ID or update their ID details. A registration officer would typically capture the individual’s demographic (name, date of birth, gender, etc.) and biometric (face, iris, and fingerprint image) details.

The lifecycle of an identity involves multiple events, categorized into different stages, each managed within specific system modules. The following sections outline these key lifecycle events, detailing their roles and functions categorized under relevant modules. Browse the cards below to explore the various applications and services that support Identity Lifecycle Management.

CBOR Identity Data in QR Code

Tag: 169 (identity-data)

Data Item: JSON Object

Semantics: Identity Data of a Person in QR-Code

Version: 1.1.0

1. Introduction

This document specifies an updated version of the generic data structure and encoding mechanism for storing the Identity Data of a registered person using any ID platform. It also provides a transport encoding mechanism in a machine-readable optical format (QR).

2. Rationale

Once a person is registered in an identity system, their data serves as the foundation for identification, granting them access to social benefits and government services. The level of assurance in this identification process varies depending on the authentication methods employed. Low assurance is achieved through basic identifiers like ID numbers, demographic data, passwords, or PINs. Conversely, higher assurance levels are attained through one-time passwords (OTP) and biometrics.

Among these methods, biometric-based authentication, such as facial authentication, offers the highest level of assurance as it assures the presence of the individual. While this is effective for online systems & personal phones where verification is conducted on a server or a personal device; offline authentication presents challenges in maintaining a similarly high level of assurance. The offline authentication mechanism should work for people with no phone.

For instance, in a cross-border scenario remote areas often face significant internet connectivity issues. Even when internet access is available, server reliability may be inconsistent. In such circumstances, scanning a QR code containing the person's facial photograph and identity information, alongside assurance that the data is country-signed, provides an additional layer of security and affirmation for the countries involved.

Please note: The trust layers required to sync the country's key are beyond the scope of this document. We assume the app scanning the QR code already has the country's key to verify.

To tackle the challenge above, we propose a standard CBOR-based QR Code that involves embedding a low-resolution image of the person with a minimal demographic dataset within the QR code. This QR code would be digitally signed by the ID authorities (Issuer) and then printed on a physical card. Subsequently, the signed data within the QR code can be utilized for facial authentication. However, it's essential to recognize that QR codes have limitations regarding size. We suggest leveraging CBOR Web Token (CWT) with ED25519/ECC keys to generate a smaller signature and more condensed data.

Claim 169 represents a JSON Object that includes the below table as ID attributes. You can find an illustration of the ID structure contained within Claim 169, where:

3. Semantics

3.1 CBOR Map Structure Overview

All the fields here are OPTIONAL.

Biometrics

Data formats

Data sub formats

Image

Template

Sound

3.2 CBOR Map Structure Example

1: COUN # iss
6: 1665980929 # iat
8: # cnf
  3: dfd1aa976d8d4575a0fe34b96de2bfad # kid
169: # identity-data
  1: "11110000324013" # ID
  2: "1.0" # Version
  3: EN # Language
  4: Peter M Jhon # Full name
  5: Peter # First name
  6: M # Middle name
  7: Jhon # Last name
  8: "19880102" # Date of birth
  9: 1 # Gender: Male
  10: New City, METRO LINE, PA # Address
  11: peter@example.com # Email ID
  12: "+1 234-567" # Phone number
  13: US # Nationality
  14: 2 # Marital status: Married
  15: Jhon Honai # Guardian
  16: 03CBABDF83D068ACB5DE65B3CDF25E0036F2C54(...)E54D23D8EC7DC9BB9F69FD7B7B23383B64F22E25F # Binary image
  17: 2 # Binary image format: JPEG
  18: [1, 2] # Best quality fingers
  50: # Right Thumb Biometrics
    # Right Thumb image
    - 0: 03CBA(...)0378C58 # Data
      1: 0 # Image
      2: 1 # JPEG
    # Right Thumb template
    - 0: 03CBA(...)0378C58 # Data
      1: 1 # Template
      2: 100 # Vendor specific
      3: VendorA # Biometric data issuer
  51: # Right Pointer Finger Biometrics
    # Right Pointer Finger image
    - 0: 36F2C546(...)CB90378C58 # Data
      1: 1 # Image
      2: 6 # WSQ
      3: VendorA # Biometric data issuer
    # Right Pointer Finger template
    - 0: 36F2C546(...)CB90378C58 # Data
      1: 1 # Template
      2: 1 # Fingerprint Template ISO 19794-2
      3: VendorA # Biometric data issuer
  58: # Left Ring Finger Biometrics
    # Left Ring Finger image
    - 0: 36F2C546(...)CB90378C58 # Data
      1: 1 # Image
      2: 6 # WSQ
      3: VendorA # Biometric data issuer   
    # Left Ring Finger template
    - 0: 36F2C546(...)CB90378C58 # Data
      1: 1 # Template
      2: 1 # Fingerprint Template ISO 19794-2
      3: VendorA # Biometric data issuer
   60: # Right Iris Biometrics
    # Right Iris image
    - 0: 36F2C546(...)CB90378C58 # Data
      1: 1 # Image
      2: 6 # WSQ
      3: VendorX # Biometric data issuer
    # Right Iris image 
    - 0: 36F2C546(...)CB90378C58 # Data
      1: 1 # Image
      2: 6 # WSQ
      3: VendorY # Biometric data issuer
   61: # Left Iris Biometrics
    # Left Iris template
    - 0: 36F2C546(...)CB90378C58 # Data
      1: 1 # Template
      2: 100 # Vendor specific
      3: VendorX # Biometric data issuer
    # Left Iris image
    - 0: 36F2C546(...)CB90378C58 # Data
      1: 1 # Template
      2: 100 # Vendor specific
      3: VendorY # Biometric data issuer
   65: # Voice Biometrics   
    # Voice sound
    - 0: 03CBA(...)0378C58 # Data
      1: 2 # Sound
      2: 1 # MP3
    # Voice template
    - 0: 03CBA(...)0378C58 # Data
      1: 1 # Template
      2: 100 # Vendor specific
      3: VendorZ # Biometric data issuer

4. Security Considerations

TODO:

1. Current map structure is in plain text and its not the recommended way to handle privacy. Adoption of SD-JWT or equivalent can be considered.

The security of the CWT relies upon on the protections offered by COSE. Unless the claims in a CWT are protected, an adversary can modify, add, or remove claims.

Since the claims conveyed in a CWT is used to make identity claim decisions, it is not only important to protect the CWT but also to ensure that the recipient can authenticate the party that assembled the claims and created the CWT. Without trust of the recipient in the party that created the CWT, no sensible identity verification can be made. Furthermore, the creator of the CWT needs to carefully evaluate each claim value prior to including it in the CWT so that the recipient can be assured of the validity of the information provided.

Syntactically, the signing and encryption operations for Nested CWTs may be applied in any order; however, if encryption is necessary, producers normally should sign the message and then encrypt the result (thus encrypting the signature). This prevents attacks in which the signature is stripped, leaving just an encrypted message, as well as providing privacy for the signer. Furthermore, signatures over encrypted text are not considered valid in many jurisdictions.

5. IANA Considerations:

5.1 Registry Content

6. Acknowledgments

This work is the result of the dedicated efforts of contributors who recognize the critical importance of interoperability and a consistent QR code specification. The revised version has been shaped significantly by the input of our working group committee, comprising members from the following organizations: GetGroup, PWC and Tech 5.

We extend our gratitude to the committee members for their invaluable time and insights throughout the evaluation phase.

6.1 Working Group Committee Members:

GetGroup: Aiman Tarek

PWC: Chaitanya Giri

Tech 5: Bejoy Ak, Nelson Branco, Rahul Parthe

MOSIP: Harini Sampathkumar, Janardhan BS, Mahammed Taheer, Ramesh Narayanan, Resham Chugani, Reeba Thomas, Sanchi Singh, Sasikumar Ganesan, Sreenadh S, Swati Goel, Vishwanath V

7. Authors

In today’s digital-first world, most services are transitioning online, making a secure and trusted digital identity more important than ever. A secure and trusted digital identity is crucial to facilitate personalized access to these online services.

eSignet strives to provide a user-friendly and effective method for individuals to authenticate themselves and utilize online services while also having the option to share their profile information. Moreover, eSignet supports multiple modes of identity verification to ensure inclusivity and broaden access, thereby reducing potential digital barriers.

Additionally, eSignet offers a seamless and straightforward solution for incorporating an existing trusted identity database into the digital realm. By enabling digital identities and providing identity verification and service access, eSignet delivers a sophisticated and user-friendly experience.

Overview

UI specs of Pre-Registration module are used to configure the form fields in the Demographic Details and Document Upload functionality. UI specs are saved as a JSON file with a list of fields. Each field has a set of attributes/ properties that can be configured which affects the look and feel along with the functionality of the field. Below is the list of all the properties available for each field in the UI specs:

Overview

This guide helps in understanding the pre-registration sample UI implementation. The pre-registration portal can be used in self-service as well as in assisted mode.

Self-service mode

In this mode, residents can pre-register themselves by accessing the pre-registration portal. They can login with their email address or phone number and fill up the demographic form, upload relevant documents to book an appointment for themselves and their family/friends. Finally, they would receive an acknowledgment along with a pre-registration ID that can be used at the registration center.

Assisted mode

When used in an assisted mode, the operator could be handling the portal helping other residents fill up the details, and creating an application on their behalf. The languages that the operator and the resident understand, may or may not be the same. If we consider a country with linguistic diversity, the possibilities increase. In such cases, the operator might log in with a language that they are familiar with, and also select a language (data capture language) familiar to the resident for filling up the demographic form and other details.

Pre-registration process

The key steps in this process are:

• Login/create a user account

• Create an application

• Book an appointment

• Receive appointment acknowledgement

To create an application, the resident/operator can follow the steps below:

Login/create a user account

1. Open the browser and visit the pre-registration portal.

2. Select the language of your preference from the dropdown.

3. Enter your valid email address or phone number in the text box.

4. Select the Captcha field.

5. Click Send OTP to receive a One Time Password (OTP) on your provided email address or mobile number.

6. Enter the OTP and click Verify.

Create an application

Step 1: Select the language for providing data

1. Once the OTP is verified, you will see a pop-up for selecting the languages for data entry.

2. Select the languages and click Submit.

Step 2: Provide consent

1. On the Demographic details page, read the Terms and Conditions and select the check box to agree. This agreement is to provide consent for the storage and processing of your personal information.

2. Click Accept and proceed.

Step 3: Enter Demographic details

1. Enter your demographic details, which include Name, Age/DOB, Gender, Residential Status, Address, Mobile Number, Email ID, etc.

2. You can also change or verify your demographic details in the other selected language.

3. After you have filled in and verified your demographic details, click Continue.

Step 4: Upload documents

1. Select the document (e.g. Passport, Reference Identity Number, etc.) from the document drop-down list.

2. Click Browse to locate the scanned document on your machine.

3. Select the file that you want to upload.

4. When the file is uploaded successfully, the document will appear on the right side. Verify that you have uploaded the correct document.

5. Repeat the steps above to upload the document(s) for each applicable document category.

6. When adding an applicant, if a newly added applicant’s Proof of Address (POA) document is the same as that of the existing user’s POA, which has been already uploaded, click the Same As option and select the name of the applicant.

7. Click Continue to preview your application.

Step 5: Preview data

1. To change the demographic details (Name, Age, etc.), click modify at the top-right corner adjacent to the Demographic details section.

2. To modify the uploaded documents, click modify at the bottom-right corner adjacent to the Documents Uploaded section and make changes.

3. To add a new applicant, click Add Applicant. On clicking the Add Applicant option, you will be navigated to the Demographic details page to provide Consent and proceed with providing the required demographic data and uploading documents.

4. Click Continue.

Add new application

On Your Applications page, click Create New Application to generate a new application.

Viewing applications

Once the application is created, there could be multiple statuses depending on the data filled by the user/resident or the actions performed by them. The user can view all the pre-registration applications created by them in the Dashboard. The different statuses with a brief explanation are mentioned below:

• The applications are sorted and displayed by the order of creation of the application. The last application created appears first in the list.

• If the user visits the registration center and consumes the appointment, then the application will be removed from the list.

• If the appointment date has passed, the status changes to "Expired" and is retained on the dashboard for further rebooking/modification as required.

Book an appointment

Choose a registration center

• The recommended registration centers are automatically displayed based on your demographic details (Postal Code)

• On the Book Appointment page, you can find a registration center through the three options as follows:

  • Click Nearby centers to view the registration centers based on your geographical location.

  • Use the search box to find the registration center based on your search criteria.

  • Click Recommended Centers to view registration centers based on your demographic details. (Postal Code)

• Click Continue.

Note: The default display of registration centers will be based on the Postal Code of the user. To modify this setting, please update the location hierarchy in the pre-registration-default.properties file using the property: preregistration.recommended.centers.locCode.

Select an appointment time slot

• Select your preferred date from the list of available calendar days and the number of available bookings.

• The list of available time slots for your selected date is categorized between Morning and Afternoon.

• Select your preferred time slot from the list.

• Select the particular applicant's name to book an appointment (click + to add the applicant). Note: On clicking the Add Applicant option, you will be navigated to the Demographic Details page to provide Consent and proceed with providing the required demographic data/documents.

• Verify the time slot(s) as selected against the applicant's name(s).

• Click Continue.

• On the confirmation pop-up, click Confirm.

• Click OK.

Receive appointment acknowledgement

• After successful completion of the Pre-registration application, you will receive an acknowledgment on the registered phone number (SMS) or email address as per details provided in the demographic form.

• The acknowledgment contains the following information: name, pre-registration ID, age/DOB, mobile number, email ID and registration center details, appointment date, and appointment time)

• A QR code containing the pre-registration ID is generated. This QR code can be scanned at the registration center to fetch the details to be used during the registration process.

• You can print, download, email, or SMS your acknowledgment.

  • To print your acknowledgment, click Print.

  • To download your acknowledgement, click Download PDF.

• To add the additional recipient(s) to receive the acknowledgment of your application, follow these steps:

  • Click Send Email/SMS.

  • Enter the mobile number and/or enter the email ID.

  • Click Send to receive the acknowledgment on your provided e-mail address or mobile number.

Re-book appointment

1. On Your Applications page, select the check box for the applicable applicant.

2. Click Book/Modify Appointment to re-book an appointment (on the top right corner)..

3. The user can select any appointment date available and the appointment slot available

4. A user cannot re-book the appointment if the appointment booking is less than 48 hours (configurable) from the time of booking

Discard application

1. On the Your Applications page, click on the delete icon against the pre-registration application of an applicant, and a pop-up window appears on the screen.

2. Select the Discard entire application option in the pop-up window.

3. Click SUBMIT to discard your application.

Cancel appointment

1. On Your Applications page, click on the delete icon against the pre-registration application of an applicant, and a pop-up window appears on the screen.

2. Select Cancel appointment and save the details option in the pop-up window.

3. Click SUBMIT to cancel an appointment.

Following a successful appointment cancellation, the system unlocks the time slot of the registration center to ensure that someone else can book it.

Overview

The Pre-registration module within MOSIP is designed keeping residents in mind, offering a user-friendly pre-registration process. This module boasts of a wide range of functionalities, starting with the collection of demographic data along with easy uploading of essential supporting documents, such as proof of address and birth certificates, besides facilitating appointment booking, modifications, and notification alerts to mention a few.

With this Pre-registration Client Demo Setup, you're one step closer to showcasing the power of MOSIP's pre-registration capabilities.

So let's get started!

Pre-requisites

• Accessing the Pre-registration portal in the Collab environment does not require any complex setup.

• All you need is a 10-digit Mobile Number or a valid email ID and you are good to go!

Step-by-Step Process

Step 1 - Access the Pre-registration Portal:

Step 2 - Login:

Login to the portal with a mobile number or valid email ID. Refer to below for details.

1. Mobile Number:

• If you choose to login using your mobile number, you will be required to enter any 10-digit mobile number, for example - “1234567890”.

• Click on the captcha tick box to proceed to the next step.

1. Email ID:

• Alternatively, you can choose to log in with your email ID.

• For the Collab environment, real email ID OTP verification is performed.

• Enter a valid email ID and an OTP will be sent to your email address. You can then enter the OTP received on the provided email ID to verify yourself and log in to the portal.

Step 3: Explore the features on the Pre-registration Portal:

Note: Please use 111111 as the OTP, for any OTP-based feature in the Collab environment.

Additional Resources

By following these instructions, you will be equipped to seamlessly set up the pre-registration portal and effectively use all the features and book an appointment.

Get in Touch

If you require any assistance or encounter any issues during the testing and integration process, kindly reach out to us through the support mechanism provided below.

• Provide a detailed description of the support you require or provide detailed information about the issue you have encountered, including steps to reproduce, error messages, logs, and any other relevant details.

Thank you. We wish you a pleasant experience!

Introduction

Pre-registration module enables a resident to:

• enter demographic data and upload supporting documents,

• book an appointment for one or many users for registration by choosing a suitable registration center and a convenient time slot,

• receive appointment notifications,

• reschedule and cancel appointments.

Once the resident completes the above process, their data is downloaded at the respective registration centers before their appointment, thus, saving enrollment time. The module supports multiple languages.

Pre-registration process

Create an application

• User provides consent

• The user provides demographic information

• User uploads supporting documents (Proof of Address, Birth certificate, etc.)

Note: The AID was formerly called PRID in the pre-registration context.

Book an appointment

• The user selects a registration center based on postal code, geo-location, etc.

• The available slots are displayed

• An option to cancel and re-book the appointment is made available

Receiving acknowledgement notifications

• An acknowledgment is sent via email/SMS

• The user can print the acknowledgment containing AID and QR code.

• This QR code can be scanned at the in-person registration centers.

Download of pre-registration data at registration centers

• The user provides the AID/ QR code at the registration center.

• The registration form gets pre-filled with the pre-registration data.

Pre-registration module

The relationship of the pre-registration module with other services is explained here.

2. Fetch a new OTP for the user on the login page.

3. Log all events.

5. The database used by pre-reg.

6. Generate a new AID for the application.

7. Send OTP in the email/SMS to the user.

8. Registration Processor uses reverse sync to mark the pre-reg application as consumed.

10. Request data from the MasterData service to get data for dropdowns, locations, consent forms etc.

Services

Pre-registration module consists of the following services:

Pre-registration portal

Build and deploy

Configurations

Developer Guide

API

Source code

Overview

Software setup

Below are the list of tools required in Pre-registration

1. JDK 11

2. Any IDE (Eclipse, IntelliJ IDEA)

3. Apache Maven (zip folder)

4. pgAdmin

5. Postman

6. Git

8. MOSIP Pre-registration specific JARs: The version will depend on which Pre Registration branch you have cloned. If it is "release-1.2.0.1" then you can download 1.2.0.1.B1 or 1.2.0.1.B2 version of below jars whichever is available.
10. Notepad++ (optional)

Follow the steps below to setup Pre-registration on your local system

2. Clone the forked repository into your local machine.

   • git clone https://github.com/${urgithubaccname}/pre-registration.git

   • git remote add upstream https://github.com/mosip/pre-registration.git

   • git remote set-url --push upstream no_push

   • git remote -v

   • git checkout -b my-release-1.2.0.1

   • git fetch upstream

   • git rebase upstream/release-1.2.0.1

3. Inside settings.xml change local repository directory to your directory name where .m2 folder is located. E.g.: <localRepository>C:/Users/username/.m2/repository</localRepository>

4. Add settings.xml inside .m2 folder (Maven Folder). E.g.: C:\Users\username\.m2

5. Import the project in Eclipse IDE and it starts updating Maven projects configuration, refreshing workspaces, project starts building (downloading sources, javadoc).

6. Add downloaded lombok.jar to project, click on downloaded JAR and install specifying Eclipse IDE(eclipse.exe) location.

1. Configure the JDK (Standard VM) with your Eclipse by traversing through Preferences → Java → Installed JREs.

1. • Adding JARs to Build Path: Right click on service -> Build Path -> Configure Build Path -> click on Classpath -> Add External JARs -> Add required JARs -> Apply and close.

1. Add auth-adapter, transliteration, ref-idobjectvalidator, virusscanner, lombok JARs to pre-registration-application-service, pre-registration-datasync-service classpath.

2. Add auth-adapter, lombok JARs to pre-registration-core, pre-registration-batchjob, pre-registration-captcha-service, pre-registration-booking-service classpath.

3. Run mvn clean install -Dgpg.skip=true command to build locally and to execute test cases.

4. Update Maven dependencies: Maven syncs the Eclipse project settings with that of the pom. It downloads dependencies required for the project.

5. Build and run the Project.

6. To run the pre-registration-application-service locally without config server, update values in application.properties and bootstrap.properties:

• spring.cloud.config.uri=https://localhost:8080

• spring.cloud.config.label=develop

• spring.cloud.config.name=pre-registration

• spring.application.name=pre-registration-application-service

• spring.profiles.active=default Point below urls to a valid env which has MOSIP setup:

• mosip.base.url=https://yourenvurl

• auth-token-generator.rest.issuerUrl:https://iam.yourenvurl/auth/realms/mosip

• javax.persistence.jdbc.password: XXXXXX

• javax.persistence.jdbc.url=jdbc:postgresql://yourenvurl:5432/mosip_prereg

• mosip.batch.token.authmanager.password: XXXXXX

• mosip.iam.adapter.appid=prereg

• mosip.iam.adapter.clientsecret=XXXXXX

• auth.server.admin.issuer.uri=https://iam.yourenvurl/auth/realms/

Developer setup for MOSIP Pre-registration UI

2. Clone the forked repository into your local machine.

• git clone https://github.com/${urgithubaccname}/pre-registration-ui.git

• git remote add upstream https://github.com/mosip/pre-registration-ui.git

• git remote set-url --push upstream no_push

• git remote -v

• git checkout -b my-release-1.2.0.1

• git fetch upstream

• git rebase upstream/release-1.2.0.1

1. Install all dependencies with npm install.

2. Install Angular JS npm install -g @angular/cli.

3. Start the Angular JS server ng serve.

4. Open http://localhost:4200 to access the application.

5. You will face CORS issue since API Services are hosted on https://{env}.

Using the Angular CLI proxy solution to get around CORS issue

1. Update the API services BASE_URL in config.json:

   • config.json is found inside assets directory.

   • E.g.: C:\MOSIP\pre-registration-ui\pre-registration-ui\src\assets\config.json

   Copy

   {
   "BASE_URL": "https://localhost:4200/proxyapi/",
   "PRE_REG_URL": "preregistration/v1/"
   }

2. Create a new file named proxy.conf.json:

   Location should be in C:\MOSIP\pre-registration-ui\pre-registration-ui\proxy.conf.json project folder.

   Copy

   {
    "/proxyapi": {
     "target": "https://{env}/",
     "secure": true,
     "changeOrigin": true,
     "pathRewrite": {
       "^/proxyapi": ""
         }
       }
     }

3. Start the server by executing ng serve --proxy-config proxy.conf.json --ssl true.

4. Open the browser, load the app with https://localhost:4200.

Pre-registration API

2. The APIs can be tested with the help of Swagger-UI and Postman.

3. Swagger is an interface description language for describing restful APIs expressed using JSON. You can access Swagger-UI of pre-registration here:

   • Pre-registration Application service : https://{env}/preregistration/v1/application-service/swagger-ui.html

   • Pre-registration Datasync Service : https://{env}/preregistration/v1/sync/datasync-service/swagger-ui.html

   • Pre-registration Captcha service : https://{env}/preregistration/v1/captcha/swagger-ui.html

   • Pre-registration Booking service : https://{env}/preregistration/v1/appointment/booking-service/swagger-ui.html

Overview

The documentation here will guide you through the prerequisites required for the developer' setup.

Software setup

Below are a list of tools required in Registration Client:

1. JDK 11

2. Any IDE (like Eclipse, IntelliJ IDEA)

3. Apache Maven (zip folder)

4. Git

Follow the steps below to set up Registration Client on your local system:

Code setup

Importing and building of a project

1. Open the project folder where pom.xml is present.

2. Open command prompt from the same folder.

3. Run the command mvn clean install -Dgpg.skip=true -DskipTests=true to build the project and wait for the build to complete successfully.

4. After building of a project, open Eclipse and select Import Projects → Maven → Existing Maven Projects → Next → Browse to project directory → Finish.

5. After successful importing of project, update the project by right-click on Project → Maven → Update Project.

Environment setup

2. Registration Client UI is developed using JavaFX and the UI pages are fxml files which can be opened using a tool called Scene Builder. The JavaFX integration with the Eclipse IDE is provided with the e(fx)clipse tool. Go to Help → Install New Software → Work with → Add. Give Name and Location as mentioned in below image.

Once the software is installed, you will be prompted to restart your IDE.

4. We can change the application environment in the file registration-services\src\main\resources\props\mosip-application.properties by modifying the property mosip.hostname

Below are the configurations to be done in Eclipse:

1. Open Eclipse and run the project for one time as Java application, so that it creates a Java application which you can see in debug configurations.

2. Open the arguments and pass this --module-path C:\Users\<USER_NAME>\Downloads\openjfx-11.0.2_windows-x64_bin-sdk\javafx-sdk-11.0.2\lib --add-modules=javafx.controls,javafx.fxml,javafx.base,javafx.web,javafx.swing,javafx.graphics --add-exports javafx.graphics/com.sun.javafx.application=ALL-UNNAMED in VM arguments.

3. Click Apply and then debug it (starts running). You can see a popup which shows informative messages of what is happening in background while Registration Client UI is loading and the application will be launched.

Running the Registration Client Downloader Docker image

• The concept here is to run nginx in the docker container from which registration-client.zip is hosted and also registration-client on the field will connect to this nginx to check for new updates or changes.

Note: We refer this nginx server as registration-client download and upgrade server.

While running the registration-client docker container we need to pass below environment variables:

Required

client_version_env : pom version of the registration client build

client_upgrade_server_env : public URL of this nginx server

reg_client_sdk_url_env : URL to download sdk zip. Make sure to have SDK jar and its dependent jars in the zip.

artifactory_url_env : artifactory URL to download below mentioned runtime dependencies

“${artifactory_url}/artifactory/libs-release-local/icu4j/icu4j.jar”

“${artifactory_url}/artifactory/libs-release-local/icu4j/kernel-transliteration-icu4j.jar”

“${artifactory_url}/artifactory/libs-release-local/clamav/clamav.jar”

“${artifactory_url}/artifactory/libs-release-local/clamav/kernel-virusscanner-clamav.jar”

keystore_secret_env : password of the keystore.p12 file

host_name_env : syncdata-service public domain name

signer_timestamp_url_env : URL of timestamp server to timestamp registration-client jar files.

Need to mount a volume to “/home/mosip/build_files” with below files

• logback.xml

• Client.crt : Signer certificate to be added in the registration-client build for jar sign verification.

• keystore.p12 : Store private key used to sign the registation-client and registration-services jar files with “CodeSigning” alias.

• maven.metadata.xml : Holds the current version of registration-client hosted in the upgrade server.

Optional

reg_client_custom_impls_url_env : URL to download scanner custom implementation jars(runtime dependency).

Finally, you can download the registration client zip from below URL. {registratiionclient download server domain name/ip}/registration-client/{client_version}/reg-client.zip}

References

Run (https://github.com/mosip/mosip-infra/blob/develop/deployment/v3/mosip/regclient/create-signing-certs.sh) to generate Client.crt and keystore.p12.

To get the content of maven-metadata.xml and logback.xml check (https://github.com/mosip/mosip-helm/blob/develop/charts/regclient/templates/configmap.yaml)

The Registration Client is a thick Java-based client where the resident's demographic and biometric details are captured along with the supporting documents in online or offline mode. Data is captured in the form of registration packets and is cryptographically secured to ensure that there is no tampering. The captured information is packaged and sent to the server for further processing.

Multiple language support

• Registration Client is featured to allow an operator to choose the operation language. The option to select their preferred language is provided on the login screen.

• Data collection during registration client supports more than one language at a time.

• Before starting any registration process, the operator can choose the languages amongst the configured ones.

Who operates the Registration Client?

The Registration Client can be operated by an operator who can be either a Supervisor or an Officer. They can login to the client application and perform various activities. The Supervisor and the Officer can perform tasks like Onboarding, Synchronize Data, Upgrade software, Export packets, Upload packets, View Re-registration packets, Correction process, Exception authentication, etc. In addition to this, the Supervisor has exclusive authority to Approve/reject registrations.

Registration Client entity diagram

The relationship of the Registration Client with other services is explained here. NOTE: The numbers do not signify a sequence of operations or control flow.

1. Registration Client connects to the Upgrade Server to check on upgrades and patch downloads.

2. All the masterdata and configurations are downloaded from SyncData-service.

3. Registration Client always connects to external biometric devices through SBI.

4. Registration Client scans the document proofs from any document scanner.

5. Acknowledgment receipt print request is raised to any connected printers.

6. Packets ready to be uploaded meta-info are synced to the Sync Status service. Also, the status of already uploaded packets is synced back to the registration Client.

7. All the synced packets are uploaded to the Packet Receiver service one by one.

The image below shows the setup of the Registration Client Host machine.

1. Registration Client comprises JavaFX UI, Registration-services libraries, and any third-party biometric-SDK.

2. SBI is allowed to run on loopback IP and should listen on any port within the 4501-4600 range. More than one SBI can run on the host machine. Registration Client scans the allowed port range to identify the available SBI.

3. Registration Client connects to the local Derby database. This is used to store all the data synced.

4. All the completed registration packets are stored under the packetstore directory.

5. .mosipkeys directory is used to store sensitive files. db.conf under this directory stores encrypted DB passwords. This is created at the start of the registration client for the first time.

6. TPM - is the hardware security module used to get machine identifier, secure DB password, and prove the client authenticity on auth requests and packets created in the host machine.

Data protection

• The registration packets and synced data are stored in the client machine.

• Most of the synced data are stored in the Derby DB. Derby DB is encrypted with the bootpassword.

• Derby DB boot password is encrypted with the machine TPM key and stored under .mosipkeys/db.conf.

• Synced UI-SPEC/script files are saved in plain text under the registration client working directory. During sync, SPEC/script file hash is stored in derby and then the files are saved in the current working directory. Every time the file is accessed by the client performs the hash check.

• Synced pre-registration packets are encrypted with a TPM key and stored under the configured directory.

• The directory to store the registration packets and related registration acknowledgments is configurable.

• The registration packet is a signed and encrypted ZIP.

• Registration acknowledgment is also signed and encrypted with a TPM key.

Background Tasks

The Registration Client runs background tasks to keep data synchronized with the Registration Processor. It continuously updates the server with newly created packets and syncs additional metadata to improve packet recovery in case of a client failure.

Another background task handles packet uploads. If supervisor approval is required ('y'), approved packets are uploaded in batches. If approval is not required ('n'), packets are uploaded during the next scheduled job. With this feature, the registration client has fully capable auto upload.

Configurations

UI Specifications for Registration Tasks

• The blueprint of registration forms to be displayed in the registration client is created as json called UI-SPEC.

• Every process ( NEW / LOST / UPDATE UIN / CORRECTION ) has its own UI-SPEC json.

• Kernel-masterdata-service exposes APIs to create and publish UI-SPEC.

• Published UI-SPEC json are versioned.

• Only published UI-SPEC is synced into registration-client.

• UI-SPEC json files are tamper proof, the client checks the stored file hash every time it tries to load the registration UI.

• UI-SPEC json will fail to load if tampered.

Developer Guide

The Registration Client setup guide for the MOSIP Collab environment offers a detailed and user-friendly walk-through to assist you in configuring and accessing the Registration Client module. This module is specifically designed to provide Operators/Supervisors with a wide range of functionalities, including onboarding, data synchronization, packet management, and more.

The primary goal of this guide is to ensure that you can efficiently set up the Registration Client in the MOSIP Collab environment with minimal effort. Whether you are new to the module and just starting to explore its features or an experienced operator seeking a streamlined setup process, this document will guide you through the essential steps to ensure that you have all the necessary tools available at your disposal.

With the implementation of this Registration Client Demo Setup, you are now on track to demonstrate the remarkable capabilities of MOSIP's Registration system. Let us proceed with the next steps to commence the process.

Pre-requisites

1. Hardware

• Workstation

• Windows 10/11 laptop or desktop

• Minimum 16 GB RAM

• 50 GB of free space on the hard disk

• Wireguard access