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.\

• Inclusive: Technology that leaves no one behind. With the mission of empowering lives all over the world, MOSIP continues to take steps toward 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 residents to access their digital identities even in remote areas with low connectivity. Please refer here for more details.

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

All MOSIP's core repositories are licensed under the terms of Mozilla Public License 2.0.

All trademarks are the property of their respective holders. Other products and company names mentioned herein may be trademarks and/or service marks of their respective owners..

Welcome !🌍

What is MOSIP?

Modular Open-Source Identity Platform (MOSIP) is an open-source, open standards-based designed to help countries build and manage their national ID systems. Anchored at the , MOSIP enables governments to conceive, develop, implement, and own secure and scalable digital identity solutions.

Built with an API-first approach, MOSIP provides features, covering , , and . The platform is designed to foster global Digital Public Goods (DPGs) in digital identification and governance. By leveraging open-source technologies, MOSIP ensures scalability, security, and privacy, adhering to best industry practices.

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

We are committed to developing trusted and transparent technology while contributing to global standards. Our open-source code repository is available entirely on , encouraging contributions from user communities and providing governments with full control over their ID systems. MOSIP actively collaborates with IEEE, governments, and industry partners to establish common Open Standards and Protocols, making MOSIP easy to integrate, interoperable, cost-effective, and time-efficient.

3. Vendor-Neutral

We offer governments the ability to integrate with a wide range of compliant technology partners. A foundational digital ID system requires smooth integration of platforms, biometric devices, and system integrators. MOSIP ensures vendor neutrality through the MOSIP Partner Programme and , allowing countries to choose and update their technology solutions freely, saving both time and financial resources.

4. Secure and Private Design

We believe every individual should be in control of their own data. MOSIP ensures data security and privacy, with cryptographic encryption and zero-knowledge architecture safeguarding information both in transit and at rest. Governments retain sovereign control over their ID systems, and data sharing occurs only with the individual’s consent. Learn more about our security and privacy principles .

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.

To know more, click .

Explore Key Areas

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?

is a secure, scalable, and open-source framework designed to help governments and organizations build foundational identity systems. It offers a flexible and configurable approach, allowing countries to tailor their national ID systems to meet specific requirements while ensuring privacy, security, and interoperability.

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.

For more details, please refer to section. To learn more about MOSIP’s Principles, .

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.

To learn more about the MOSIP modules, please refer .

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.

To learn more about the MOSIP Ecosystem, please refer .

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.

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

  • The (ARC) enhances inclusivity by enabling in-home registration for individuals who are unable to visit physical registration centers. This portable solution ensures that residents, especially in remote locations, can access identity registration services at their convenience. By providing mobility for registration agents and allowing remote registrations, ARC significantly expands coverage and accessibility, ensuring that even those in underserved or hard-to-reach areas are included in national identity systems.

• Ensuring Gender Inclusivity with MOSIP's GenderMag Collaboration

  • MOSIP’s collaboration with ensures inclusivity by integrating gender-sensitive design principles into the User Interface (UI) and Design. This approach helps identify and address barriers that may disproportionately affect users based on gender, ensuring that the digital identity platform is accessible and effective for all users, regardless of gender. This approach emphasizes on creating interfaces that are intuitive and equitable, thus ensuring an inclusive user experience for diverse populations.

• Multi-Modal Verification with Inji and eSignet

  • MOSIP ensures inclusivity by offering multiple verification modalities through and . These solutions provide secure and convenient citizen verification across various channels, including online/offline, self-service/assisted modes, and accessible even with smartphones, feature phones, or no phones. This flexibility allows individuals from diverse backgrounds, including those with limited access to technology or support, to easily access and benefit from the services.

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's fundamental architecture and design incorporate the highest levels of privacy and security.

Security by design

Key security features:

• Encryption of data in-flight or rest. (See )

• 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.

The ID Issuance component in MOSIP encompasses the set of modules responsible for the creation and assignment of unique identities to individuals. It orchestrates the end-to-end process, starting from the collection of demographic and biometric data, through validation and processing, to the final generation of a unique identity number (UIN). The sub-modules under ID Issuance include:

• Pre-registration: Enables individuals to submit demographic details online in advance, expediting the in-person registration process.

• Registration Client: Facilitates the collection of demographic and biometric data at registration centers, providing an intuitive interface for operators.

• Android Registration Client: A mobile application version of the Registration Client, allowing for data collection in remote or field locations using Android devices.

• Registration Processor: Validates and processes registration data, ensuring its integrity before moving to the next stage.

• id-repository: Manages the storage and retrieval of identity data, ensuring secure and efficient access to demographic and biometric information.

Together, these modules ensure a secure, efficient, and streamlined approach to issuing unique identities within MOSIP. For more details on each module, refer to their respective overview pages.

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.

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.

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.

MOSIP Sonar cloud Link : https://sonarcloud.io/organizations/mosip/projects

• 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.

Overview

The Android Registration Client is a tablet application that serves as a portable version of the existing desktop Registration Client. It has been developed to support accessibility on all Android devices. The creation of the Android Registration Client was driven by the need to meet the mobility requirements of countries adopting MOSIP.

The primary objective of the tablet version is to facilitate the registration process for residents, especially those who are unable to physically visit registration centers. It also serves remote locations where setting up registration centers is not feasible. To address this challenge, the Android Registration Client was created, enabling operators and supervisors to easily reach remote areas and maximize resident registrations across the country.

Configuration Guide

To read through the comprehensive list of configurable properties for the Android Registration Client, refer Android Registration Client Configuration Guide.

UI Specifications

For more details on UI specifications for the Android Registration Client, refer here.

Compatibility

The Android Registration Client is compatible with the following MOSIP platform versions:

1. 1.1.5.x

2. LTS 1.2.0 and above

Are you interested in integrating with MOSIP as a partner? We invite you to connect with us by completing the form. This will assist us in facilitating a seamless integration with our designated sandbox environments.

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.

The link to access the Collab environment is available here.

Looking to collaborate with us? Click here to get started with the Collab environment!

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.

The link to access the Synergy environment is available here.

Identity Verification

The Identity Verification category in MOSIP encompasses modules responsible for authenticating and verifying the identity of individuals using various mechanisms. Below are the modules under this category, each with a brief description and a link to their respective overview pages:

• ID Authentication Services: Provides APIs for authenticating individuals based on their identity data, including demographic and biometric information.

• ID Authentication (IDA): IDA module in MOSIP is an independent service that enables seamless identity verification using data from any system. Multiple IDA modules can run from a single issuer, providing services like authentication, OTP generation, and internal processes.

Build and deploy

Refer to repo.

Configurations

Refer to Configuration Guide.

Identity Management refers to the processes and technologies used to create, maintain, and manage digital identities. In MOSIP, it ensures secure and efficient handling of individual identity data throughout its lifecycle.

• Resident Services: Provides APIs for managing resident data, including creation, updates, and retrieval of demographic and biometric information.

• Resident Portal: A reference UI for residents to easily access and manage their identity data.

• ID Schema: Defines the structure and format of identity data, ensuring consistency and interoperability across the system.

• Identifiers: Manages the generation, assignment, and lifecycle of unique identifiers for individuals within the MOSIP ecosystem.

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.

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.

• (Common Biometric Exchange Formats Framework) – Facilitates interoperability and efficient biometric data exchange.

• 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

• Claim 169 – A globally registered specification under the , developed by It allows demographic and biometric data (like a low-res face image) to be embedded in a digitally signed QR code, enabling reliable offline identity verification. to know more.

MOSIP is built on a modular, microservices-based architecture. Its modularity enables seamless adoption even in complex scenarios. Most are designed as robust foundational infrastructure components, making them suitable for integration into various projects.

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.

To know how MOSIP can be deployed, refer to . The different installation models are detailed in the section.

The table below outlines the frameworks, tools, and technologies employed by the Android Registration Client.

Android SDK Versions :

Target SDK Version : 31

Compile SDK Version : 31

Overview

Welcome to the Pre-registration Collab Guide! This guide will equip you to seamlessly access the Pre-registration demo application, explore, integrate, and effectively demonstrate its capabilities.

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:

Visit the following URL to access the Pre-registration portal in the Collab environment: 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:

To access all the features of the Pre-registration portal and explore the pre-registration process in MOSIP, refer to our end user guide.

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

Additional Resources

Watch this informative video here for a visual walkthrough of the features.

For more information about Pre-registration, click here.

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.

• Navigate to Community.

• 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!

Following are the metrics that are collected in the client application using the micrometer library:

• JVM Memory Metrics

• JVM Thread Metrics

• JVM GC Metrics

• JVM Heap Pressure Metrics

• Processor Metrics

• Class Loader Metrics

• Disk Metrics

• Packet Metrics based on client and server status

All the metrics collected are appended to metrics.log file. Rolling policy of the metrics.log is defined in registration-services logback.xml.

Below are the challenges faced in exporting the collected metrics from client application to the server for further analysis:

1. Unreliable network conditions on field.

2. Metrics files are mostly large files, and cannot afford retries on failed attempts.

3. Required HTTP based metrics export.

To overcome the above challenges, Registration Client is built with tus-java-client (version: 0.4.3) . Tusd server URL and the upload chunk-size are made configurable in the client application.

mosip.registration.tus.server.url: This is the server URL config which specifies to which URL the metrics files are to be uploaded.

mosip.registration.tus.server.upload.chunksize: This config defines the chunk size, which means, how much size of the file is to be uploaded at once. By default, this is given as 1024, which means 1KB

Note:

• The Tus protocol is designed to enable resumable uploads of large files over HTTP, which can be useful for web applications that need to handle file uploads in unreliable network conditions or with large files that might take a long time to upload. For more information on TUS, refer here.

• Tusd is a popular implementation of the Tus protocol that can be used as a standalone server. It is a part of the MOSIP deployment.

Each metric json logged into metrics.log file is tagged with machine name. Refer the below log lines with the machine names.

{"@timestamp":"2023-03-12T15:00:10.654+05:30","@version":"1","message":"{\"@timestamp\":\"2023-03-12T09:30:10.654Z\",\"name\":\"jvm.threads.states\",\"type\":\"gauge\",\"machine\":\"c1ml54597\",\"state\":\"waiting\",\"value\":8,\"unit\":\"threads\"}","logger_name":"io.mosip.registration.config.LoggingJsonMeterRegistry","thread_name":"logging-metrics-publisher","level":"INFO","level_value":20000}


{"@timestamp":"2023-03-12T15:00:10.654+05:30","@version":"1","message":"{\"@timestamp\":\"2023-03-12T09:30:10.654Z\",\"name\":\"jvm.threads.states\",\"type\":\"gauge\",\"machine\":\c1ml54597\",\"state\":\"timed-waiting\",\"value\":20,\"unit\":\"threads\"}","logger_name":"io.mosip.registration.config.LoggingJsonMeterRegistry","thread_name":"logging-metrics-publisher","level":"INFO","level_value":20000}


{"@timestamp":"2023-03-12T15:00:10.654+05:30","@version":"1","message":"{\"@timestamp\":\"2023-03-12T09:30:10.654Z\",\"name\":\"jvm.threads.states\",\"type\":\"gauge\",\"machine\":\"c1ml54597\",\"state\":\"blocked\",\"value\":0,\"unit\":\"threads\"}","logger_name":"io.mosip.registration.config.LoggingJsonMeterRegistry","thread_name":"logging-metrics-publisher","level":"INFO","level_value":20000}


{"@timestamp":"2023-03-12T15:00:10.654+05:30","@version":"1","message":"{\"@timestamp\":\"2023-03-12T09:30:10.654Z\",\"name\":\"jvm.threads.states\",\"type\":\"gauge\",\"machine\":\"c1ml54597\",\"state\":\"terminated\",\"value\":0,\"unit\":\"threads\"}","logger_name":"io.mosip.registration.config.LoggingJsonMeterRegistry","thread_name":"logging-metrics-publisher","level":"INFO","level_value":20000}


{"@timestamp":"2023-03-12T15:00:10.654+05:30","@version":"1","message":"{\"@timestamp\":\"2023-03-12T09:30:10.654Z\",\"name\":\"jvm.threads.states\",\"type\":\"gauge\",\"machine\":\"c1ml54597\",\"state\":\"new\",\"value\":0,\"unit\":\"threads\"}","logger_name":"io.mosip.registration.config.LoggingJsonMeterRegistry","thread_name":"logging-metrics-publisher","level":"INFO","level_value":20000}

• A job is scheduled to upload collected metrics to server from the client application.

• Job runs with a fixed delay of 15 minutes.

• Resumable file URLs are stored under .metrics folder of registration client. Once the complete file is uploaded to server, the metrics file is deleted locally.

Android Registration Client (ARC) is a tablet application that serves as portable version of the existing desktop Registration Client. It can be accessed through Android devices and also meets mobility requirements of countries adopting MOSIP Identity.

The primary objective of the tablet version is to facilitate the registration process for residents who are not able to physically visit Registration centers and also serve remote locations where setting up Registration centers is not feasible. To address this challenge, the ARC was developed enabling Operators / Supervisors to easily access the remote areas and maximize resident registrations across the country.

This guide serves as a tool to demonstrate the impressive capabilities of MOSIP's system. Additionally, the primary user of this guide will be the Operator / Supervisor trying to register individuals for generating UIN.

Let's embark on this journey together to explore the potential of ARC.

Pre-requisites

• Reliable and consistent Internet connectivity

• Tablets running Android version 10 to 13

• Tablets with a minimum of 4 GB RAM

• The tablets should be capable of capturing fingerprints, IRIS, and face (photo) biometrics. Additionally, they should also have the ability to scan documents. However, if the tablets do not support these capabilities, MOCK SBI can be used as an alternative.

• The following details are required to access ARC in the Collab environment:

  • UIN or a VID

  • Machine details

• To obtain your UIN credentials for the Collab environment follow the below steps:

  • The provision of a Unique Identification Number (UIN) as a demonstration credential will enable you to have a firsthand experience of the ARC's capabilities and explore its various features.

  • Please fill out the form with the correct details and submit the form. Upon receiving the form, we will generate a demo credential for you. We will also register you as an Operator on Keycloak and map your device to the center to which your credential is required to be mapped.

Step-by-Step Process

Mentioned below are the steps to download, install, and use ARC.

Step 1: Download and install the APK on an Android tablet. Visit the Android Registration Client to access ARC in the Collab environment.

Step 2: Install ARC and launch it.

Step 3: Login as an Operator with the credentials received and wait for synchronization to complete.

Step 4: Refer to our comprehensive User Guide document to learn how to register and use ARC.

Note: Please be advised that if the Android Registration Client is uninstalled and then re-installed, the aforementioned steps will need to be repeated from the start.

Additional Resources

• To know more about features of the Android Registration Client, click here.

• To learn more about the ARC configurations, click here.

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 provided below.

• Navigate to Community.

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

Thank you. Wishing you a pleasant experience!

Overview

In the context of MOSIP, identifiers are alphanumeric digital handles for identities in the system. While a person's identity is represented as a collection of biographic and biometric attributes that can uniquely identify the person, the identity is referred to using identifiers.

UIN

Unique Identification Number (UIN), as the name suggests, is a unique number assigned to a resident. UIN never changes and is non-revocable. UIN is randomized such that one should not be able to derive any Personal Identifiable Information (PII) from the number itself.

The rules that govern generation of a UIN are listed here.

VID

The VID / Virtual ID is an alias identifier that can be used for authentication transactions. The key characteristic of such an identifier is that it expires. This allows for free disclosure and usage of this identifier in various contexts. It is privacy friendly in a way such that it can be revoked, configured for one time usage and is not linkable. Since these are used for authentication transactions, such identifiers are to be known to the user only or generated with their participation.

RID / AID

The Application ID (AID) refers to the unique identifier given to a resident during any ID lifecycle event, such as ID Issuance, ID Update, or Lost ID retrieval, at the registration center. It serves as a distinguishing factor for each specific event and can later be utilized by the resident to check the progress or status of the event. Previously, in MOSIP, the Application ID was referred to as the RID (Registration ID) and/or PRID (Pre-registration ID).

PRID

The PRID is a specialized RID used in the pre-registration system.

Token ID (PSUT - Partner Specific User Token)

The Token identifier/PSUT is a system provided customer reference number for relying parties to uniquely identify the users in their system. The token identifier is an alias meant for the partner/relying party typically unique (Configured through PMS policy, in case uniqueness is not the need then partner policy can be set to provide random number) to them. This identifier is included in the response of the authentication transactions. One key differentiator is that the PSUT is not accepted as an identifier for authentication transactions. This ensures that the partner who has the PSUT can not reauthneticate.

This guide contains all the information required for successful deployment and running of Resident Portal. It includes information about the Database and template scripts, seed data, roles, OIDC client setup, etc.

DB scripts

Resident Service DB Scripts to be run: DB scripts

Master-data Template Scripts

The master-data templates required for the Resident portal are added to the template and template type DML excel files in mosip/mosip-data repository. These scripts need to be applied to the corresponding table.

Keycloak Roles

mosip-resident-client needs to have below roles in keycloak:

• RESIDENT

• SUBSCRIBE_AUTH_TYPE_STATUS_UPDATE_ACK_GENERAL

• SUBSCRIBE_AUTHENTICATION_TRANSACTION_STATUS_GENERAL

• SUBSCRIBE_CREDENTIAL_STATUS_UPDATE_GENERAL

• SUBSCRIBE_REGISTRATION_PROCESSOR_WORKFLOW_COMPLETED_EVENT_GENERAL

• CREDENTIAL_REQUEST

Resident OIDC Client setup

Here is the document which explains how resident-oidc partner is onboarded through partner-onboarder after deployment.

For more details on how to configure the Resident OIDC client, refer here.

What is a handle?

UIN / VID are system-generated unique identifiers provided to Residents. Residents are allowed to authenticate themselves using either UIN / VID.

What if residents are given the flexibility to create their handle (username) and use their unique handle to authenticate?

• Handles can include resident's phone number, e-mail ID, or any linked functional ID / sectoral ID.

• The handle can also be a custom username created through the resident portal.

Note: A recyclable ID, such as a mobile number, cannot be used as a handle. Handles must be unique and persistent to ensure reliable identification and authentication. Since mobile numbers and similar IDs can be reassigned or changed over time, they do not meet the criteria for a secure handle. Instead, handles should be chosen from identifiers that remain constant for the user, minimizing the risk of identity conflicts or unauthorized access.

Overview

Countries that have an established user base can now register users onto a relying portal using their distinctive identifiers referred to as handles. These handles are tailored to meet the specific requirements of each country, enabling users to easily access digital services and receive prompt benefits from both the government and private sector. This approach eliminates the need for users to remember a new or system generated IDs.

How does it work?

The implementation of custom handles involves below steps:

1. Mark the fields that can be used as user handles. A new attribute is introduced in identity schema, handle which accepts boolean value. More than one field in the identity schema can be marked as handle.

   With phone as an example:

   {"fieldCategory": "phone number", "format": "none", "type": "string", "fieldType": "default", "requiredOn" : "", **"handle" : true**},

2. When the user registers, collected user data should contain selectedHandles, as more than one field can be marked as handle, user can choose amongst the handle fields to use. User can also choose all of them. Client UI’s collecting user data during registration can decide to provide this option to the user or it can also set selected handles to default values as decided by the country. selectedHandles is also a field in schema, identity.

   "selectedHandles" : {"fieldCategory": "none","format": "none","type": "array","items" : { "type" : "string" },"fieldType": "default" }

3. When the collected identity object is sent to the ID repository, it validates the data and accepts the handle provided it is unique amongst the registered handles.

   Note: If duplicated, a request to register the user is rejected.

4. Once identity is successfully processed and stored in an ID-repository, identity credentials are issued to IDA to store user credentials for each ID (UIN & VID) as well for each selected handle.

5. ID-repository can be configured to disable issuance of user credential to IDA for both UIN or VID using below properties.

   mosip.idrepo.identity.disable-uin-based-credential-request=true

What is handles collision? How handles collision can be avoided?

If the system is configured to use more than one functional ID as a handle and if two different functional ID systems followed the same format /pattern to generate an ID, handles collision may occur.

Collision between two different functional IDs will result in denying the creation / updating of a handle for a resident.

Solution: Every handle stored is postfixed with handle type and the handle type is chosen based on the handle field ID in the identity schema. On every authenticate request, IDA will expect handle postfixed with handle_type as input.

Property mentioned below is introduced in ID repository to postfix handle type on every creation of identity.

mosip.identity.fieldid.handle-postfix.mapping={'phone':'@phone'}

Property mentioned below is introduced in Id-authentication-default.properties file to validate the handle value based on the postfix provided in the inidivdualId input.

mosip.ida.handle-types.regex={ '@phone' : '^\\+91[1-9][0-9]{7,9}@phone$' }

Conclusion

Implementing custom handles provides a user-friendly approach to user authentication without burdening end users with the need to remember additional or system generated complex IDs.

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.

Various flows with encryption are illustrated below. Refer to Keys for all references of the type 'Kx' and 'KPx'.

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.

   • Registration Client signs the packet using the TPM key of the machine (K10) and encrypts the packet using MOSIP public key specific to (the registration centre, machine id) combination (K11).

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:

   • ID Repository encrypts biometrics, demographics, and documents and stores them in the Object Store. (K7.1,K7.2,K7.3)

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

The ID Authentication module (IDA) is independent and may be hosted by several providers. IDA hosts all the biometric templates and demographic data. Unique additional protection is provided here to make sure that mass decryption of user data is very difficult to achieve. The data can only be decrypted if the user's UIN is provided. Here is the encryption scheme:

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

8. Share data in step 7 via standard Datashare encryption (which encrypts entire data with PK8).

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

1. L1 devices contain FTM to encrypt (DE1, K21) and sign (FK1) biometrics at the source and send them to the authentication client.

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

3. IDA decrypts zero-knowledge data as given in Step 4 and then performs a demographic and/or biometric authentication.

4. The match result is returned to the Auth client. In the case of KYC, the KYC attributes are encrypted with the Partner's public key (as in Datashare).

Overview

Resident services are self-service tools utilized by residents through an online portal. The is a web-based user interface application that offers services related to the residents' Unique Identification Number (UIN). Through this portal, residents can perform various operations related to their UIN or VID and can also raise any concerns they may have.

The relationship of Resident services with other services is listed below.

1. Audit Manager: Resident services sends all the audit logs to the Audit Manager.

2. Digital card service: Resident services use this service to download the PDF of the UIN card or VID card.

3. Credential Request Generator Service: This service is used to share credentials with various partners, such as print, authentication, and digital card partners.

4. ID Repository Identity Service: Resident services use this service to retrieve a credential's identity information and lock/unlock authentication types.

5. ID Repository VID service: This service is used to generate/revoke various types of VIDs.

6. ID Authentication: This service is used by Resident services to authenticate users.

7. MOSIP e-Signet: This is used to authenticate and authorize the users in the event of login using UIN/ VID.

8. Resident UI: This is the interface through which users can interact with the Resident Services.

9. WebSub: This is used to get asynchronous notifications from IDA for acknowledgment purposes.

10. Registration Processor: This is used to sync and upload packets for features about changes in identity data.

11. Packet Manager: Resident services use this service to create packets.

12. Partner Management Service: Resident services use this service to get information about various partners and policies.

13. Keycloak: Resident services use this to authenticate to access the MOSIP internal APIs. The Resident Services communicates with endpoints of other MOSIP modules via a token obtained from Keycloak.

14. Master data service: Resident services invoke the Master Data services to get various templates and machine details.

15. Notification service: Resident services use this service to send various notifications through email or SMS.

16. Key Manager: Resident services use Key Manager to encrypt or decrypt the data used across features.

Design Principles

The design of the Resident portal embodies the following principles:

• One-stop solution: The Resident portal is designed to have components that aim to solve all the queries, issues, or discrepancies of the residents and act as a one-stop solution for all the requirements.

• Self-Sovereign: Once the ID is issued by an authority, the user/resident/citizen chooses to control and manage their data in their choice of devices.

• Inclusive: The Resident portal aims to be available in all browsers while also catering to the needs of visually impaired, dyslexic, and color-blind folks.

• Presence assurance: This web-based UI application would put in all its efforts to ensure easy access to all the residents with high availability.

• Works Remote: The Resident portal should be able to share credentials when data needs to be shared remotely without physical presence.

• Trusted: The identity verification process on the device should be trusted so that it can be used in service delivery without any concerns.

• Grievance redressal: The Resident portal ensures that in case of any concerns or grievances, the issue is raised and resolved through the portal itself.

Documentation

The key features provided on the Resident portal are mentioned below.

1. Avail UIN services using UIN/ VID (through ):

• View My History: This feature enables the Resident to view the history of transactions associated with their UIN.

• Manage My VID: Residents can create, delete, and download VID cards based on requirements.

• Secure My ID: Residents can lock or unlock their authentication modalities such as fingerprint authentication, iris authentication, email OTP authentication, SMS OTP authentication, thumbprint authentication, and face authentication.

• Track My Requests: This feature enables the Residents to enter an Event ID associated with the logged-in user’s UIN to track the status of the event.

• Get Personalized Card: The residents can download a personalized card which essentially means that they can choose the attributes that they would want to be added to their cards.

• Share My Data: This feature enables Residents to choose the data that they want to share with a MOSIP-registered partner.

• Update My Data: This feature enables the Resident to update their identity data, address, email ID, phone number, and notification language preference.

• Logout: Once the Resident is done with the activities that he wanted to perform, he can end the active session by logging out from the portal.

2. Get Information

• About Registration Centers: Residents can get a list of Registration Centers near them or Registration Centers based on the location hierarchy.

• List of supporting documents: Residents can get the list of all the supporting documents as Proof of Identity, Proof of Address, Proof of Relationship, etc.

3. Get My UIN (using UIN/ VID/ AID)

Using this feature, the Resident can download their password-protected UIN card if the UIN card is ready or they can view the status of their Application ID (AID) if the UIN card is still in progress.

4. Verify Email ID and/ or phone number

Using this feature, the Resident can verify if the email ID/ Phone number given during registration is correct or not. This will be done by verifying the OTP sent over the registered email ID/ Phone number.

5. Book an appointment for new enrollment (via the pre-registration portal)

Using this feature, the Resident can book an appointment to visit the Registration center.

6. Ancillary features

• Multi-lingual support: Residents can view and use the Resident Portal in multiple languages including RTL languages.

• Get Notifications (email and bell notifications): Residents will be getting bell-icon notifications for the asynchronous events if they have an active session i.e. they have logged into the Resident Portal.

• View profile details of the logged-in user (name, photo, and last login details): The Resident will be able to view the name, and photo of the logged-in user. They will also be able to see the last login details of the Resident.

• Responsive UI support: Support for the application to work seamlessly on various resolutions.

Below is an image summarizing the features provided in the Resident portal.

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.

MOSIP provides a reference implementation of a Java-based Registration Client. The code, and build files for the Registration Client are available in the Registration Client repo.

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.

To know more about setting up the reference registration client, refer to the Registration Client Installation Guide.

To know more about the features present in the Registration Client, refer to the Registration Client User Guide.

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.

To know more about the onboarding process of an operator, refer to Operator onboarding.

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.

You can configure these settings in the Scheduled Jobs and Batch Configuration sections.

Configurations

Registration Client can be customized as per a country's requirements. For details related to Registration Client configurations, refer to Registration Client configuration.

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.

Default UI Specifications loaded with Sandbox installation is available here

Developer Guide

To know more about the developer setup, read the Registration Client Developers Guide.

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

This guide details the configuration updates required in MOSIP to enable CRVS-initiated birth and death registration requests. It covers ID schema changes to add key fields, updates to authentication policies, property files, and identity mapping, along with new Camel routes and workflow settings. These changes ensure the proper handling and processing of vital events within the MOSIP ecosystem.

ID Schema Update for Initiating Infant Birth Requests

Before initiating an infant birth registration request from the CRVS system, updating the ID schema in MOSIP to include the necessary fields required for capturing introducer information is essential.

The following fields should be added to support the processing of infant birth registration requests:

• introducerInfoToken (Optional)

  • Description: A user information token representing the individual reporting the infant's birth to CRVS.

ID Schema Update for Initiating Death Requests

Before initiating a death registration request from the CRVS system, updating the ID schema in MOSIP to include the necessary fields required for capturing information related to the deceased and informant is essential.

The following fields should be added to support the processing of death registration requests:

• deceasedDeclarationDate (Optional)

  • Description: The date on which the individual was declared deceased.

• declaredAsDeceased (Mandatory)

  • Description: A flag indicating that the individual has been officially declared deceased.

• typeOfDeath (Optional)

  • Description: Specifies the nature of the death, such as natural or jurisdictional.

• deceasedInformer (Optional)

  • Description: A user information token representing the individual reporting the death to CRVS.

Configuring mosip-auth-policy

After updating the ID schema with the necessary fields for birth/death registration, corresponding changes must be applied to the default authentication policy. This step ensures that the new fields are correctly reflected in the ID authentication module particularly required when the authentication process involves the national ID of a deceased individual.

To include the new attributes in the authentication policy:

1. Update the existing policy_file_id by appending the newly added fields.

2. Execute the upgrade script to apply the changes.

Below is a sample SQL script for updating default-authpolicy to include the field declaredAsDeceased:

UPDATE pms.auth_policy SET policy_group_id='mpolicygroup-default-auth', "name"='mpolicy-default-auth', descr='mpolicy-default-auth', policy_file_id='{"shareableAttributes":[{"attributeName":"fullName","source":[{"attribute":"fullName"}],"encrypted":true},{"attributeName":"dateOfBirth","source":[{"attribute":"dateOfBirth"}],"encrypted":true},{"attributeName":"gender","source":[{"attribute":"gender"}],"encrypted":true},{"attributeName":"phone","source":[{"attribute":"phone"}],"encrypted":true},{"attributeName":"email","source":[{"attribute":"email"}],"encrypted":true},{"attributeName":"addressLine1","source":[{"attribute":"addressLine1"}],"encrypted":true},{"attributeName":"addressLine2","source":[{"attribute":"addressLine2"}],"encrypted":true},{"attributeName":"addressLine3","source":[{"attribute":"addressLine3"}],"encrypted":true},{"attributeName":"region","source":[{"attribute":"region"}],"encrypted":true},{"attributeName":"province","source":[{"attribute":"province"}],"encrypted":true},{"attributeName":"city","source":[{"attribute":"city"}],"encrypted":true},{"attributeName":"postalCode","source":[{"attribute":"postalCode"}],"encrypted":true},{"attributeName":"zone","source":[{"attribute":"zone"}],"encrypted":true},{"attributeName":"preferredLang","source":[{"attribute":"preferredLang"}],"encrypted":false},{"attributeName":"individualBiometrics","group":"CBEFF","source":[{"attribute":"individualBiometrics"}],"encrypted":true,"format":"extraction"},{"attributeName":"declaredAsDeceased","source":[{"attribute":"declaredAsDeceased"}],"encrypted":true}],"dataSharePolicies":{"typeOfShare":"Data Share","validForInMinutes":"30","transactionsAllowed":"2","encryptionType":"Partner Based","shareDomain":"datashare.datashare","source":"ID Repository"}}' , policy_type='DataShare', "version"='1', policy_schema='https://schemas.mosip.io/v1/auth-policy', valid_from_date='2025-03-17 11:53:55.388', valid_to_date='2025-04-28 09:37:00.000', is_active=true, cr_by='admin', cr_dtimes='2025-03-17 11:53:55.388', upd_by='admin', upd_dtimes='now()', is_deleted=false, del_dtimes=NULL WHERE id='mpolicy-default-auth';

Properties Added

The following property files have been updated with the mentioned properties to support the new functionality:

application-default.properties:

• mosip.kernel.idobjectvalidator.mandatory-attributes.reg-processor.crvs_new Mandatory attributes for infant birth registration flow.

• mosip.kernel.idobjectvalidator.mandatory-attributes.reg-processor.crvs_death Mandatory attributes for death registration flow.

• provider.packetreader.crvs1 Packet reader for the source with the name CRVS1. This property should be updated if the source name is changed.

• provider.packetwriter.crvs1 Packet writer for the source with the name CRVS1. This property should be updated if the source name is changed.

Fields Added to identity-mapping JSON:

• deceasedDeclarationDate

• declaredAsDeceased

• typeOfDeath

New Camel Routes:

• registration-processor-camel-routes-crvs_death-default.xml New Camel route for death registration packet processing.

• registration-processor-camel-routes-infant-crvs_new-default.xml New Camel route for infant birth registration packet processing.

registration-processor-default.properties:

• registration.processor.additional-process.category-mapping Mapping of the additional process to the internal process.

• registration.processor.vid-support-for-update Enables VID support for updates.

• mosip.regproc.workflow-manager.instance.api-id Unique ID for the workflow instance API.

• mosip.regproc.workflow-manager.instance.version A version of the workflow instance API.

• registration.processor.notification.additional-process.category-mapping Mapping of the additional process to the internal process for notification.

For more details on ID schema and configurations please refer here.

Overview

What is ID Authentication?

IDA (ID Authentication) module in MOSIP is an independent service that enables seamless identity verification using data from any system. Multiple IDA modules can run from a single issuer, providing services like authentication, OTP generation, and internal processes.

MOSIP recommends using eSignet for authentication, which leverages the IDA module to ensure secure and unified identity verification. eSignet simplifies the process by streamlining authentication across services, ensuring compliance with MOSIP’s security protocols. This enables both governmental and private entities to securely authenticate residents without needing multiple solutions.

Read more about eSignet and its capabilities here. The typical authentication flow is illustrated below:

Authentication types

The following types of authentication are offered by MOSIP's ID Authentication (IDA) module and are utilized through eSignet for ID verification by external parties:

1. Yes/No Authentication

MOSIP offers a yes/no API that can be used for the verification of attributes supplied along with authentication factors. The API verifies the identifier and the provided demographic attributes and also validates other authentication factors such as the OTP or biometrics and responds with a yes or a no. Successful verification of the data results in a yes. This kind of API can be typically used to support the verification of a limited set of demographic data about the person or for simple presence verification when biometrics are used.

2. KYC Authentication

MOSIP additionally offers a KYC API, which can be used to get an authorized set of attributes for the resident in the response of the API. This API is intended for use by authorized relying parties to perform KYC requests. The authentication includes an identifier along with authentication factors such as OTP and biometrics. The information returned is governed by a policy. Different relying parties can be provided with different KYC data based on their needs. The policy helps implement selective disclosure as part of the KYC data. The data thus returned is digitally signed by the server and can be used by the relying party with confidence.

3. Multifactor authentication

The authentication APIs support multiple factors. These can be:

• Biometric: Finger, face, iris

• Demographic: Name, date of birth, age, gender, etc.

• OTP: One-Time Password Based on the level of assurance needed for the transaction, the relying party can decide which factors are sufficient for identity verification.

• Password-based authentication.

Biometric authentication is performed using third-party matcher SDK that performs 1:1 matches on a given modality. Each biometric modality is treated as an independent factor in authentication.

VID

All authentications in MOSIP operate on a 1:1 matching principle. This requires the authentication request to include an identifier for the individual, along with authentication factors to verify the identity. MOSIP supports multiple identifiers for each person, which enhances privacy and prevents profiling. The individual can be authenticated using their UIN or alternate identifiers like VIDs. When a VID is used, additional checks ensure it hasn't expired or been revoked. The expiration of a VID is governed by the policy set during its creation.

To understand VIDs and their characteristics, read more about VID.

Tokenization

In certain contexts, identity verification can be performed anonymously for one-time use. However, when identity verification is tied to transactions requiring identity assurance, it becomes necessary to link the user's identity to the transaction. This is done by providing relying parties with a "sticky" token identifier, which can serve as a reference ID for the individual in their system. When authentication is successful, the APIs return a token. Depending on the relying party’s policies, the token may be random or "sticky." The relying party is expected to store this token for future reference, customer identification, and audit or redressal purposes.

Learn more about the Token ID.

Relying parties and policies

Read more about parties and policies.

Consent

MOSIP has a provision for specifying the user consent associated with an authentication transaction. This can be stored for audit purposes and the authentication flow can be extended to verify the consent if needed.

Hotlisting

MOSIP has a provision to help protect against the misuse of identity. For any report of lost identity or detection of fraudulent activity by fraud, the module can require the temporary suspension of authentication activities on a user. This is enabled by the hotlisting feature. The authentication service checks if the identifier used is hotlisted and if so, the authentication process is aborted and fails. The hotlisting service can be used by helpdesk and fraud solutions to list and delist the identifiers that need to be blocked temporarily.

Demographic data normalization is the process of applying rules for formatting of the demographic data (such as the address) into a common format before demographic data matching is verified during the demographic authentication in IDA. For example, for address lines, the '1st Street' can be replaced with '1 st' and 'C/o' can be removed from both the input and database data before the match is verified. These rules will be different for different languages, and may be configured/implemented differently.

The ID-Authentication Demographic data normalization mentioned here is specific to the Demo-SDK reference implementation of the Kernel Demographic API. It takes the below configuration to apply the name and address normalization rules.

For any other custom implementation of the normalization, the Demo-SDK needs to be implemented accordingly.

Demographic name/address normalization using regular expressions and their replacement configurations

The below configuration is used to define the separator for normalizing regex (pattern) and the replacement word. The default is set to '='.

ida.norm.sep==

The format for configuring the name/address normalization rules for any language is given below:

ida.demo.<name/address/common>.normalization.regex.<languageCode/any>[<sequential index starting from 0>]=<reqular expression>${ida.norm.sep}<replacement string>

* name/address/common - type of normalization, common applies to both name and address

* languageCode - this is the code for languages like hin, eng, any('any' applies to any language)

If replacement string is not specified, the regular expression will be replaced with empty string.

Note: It is recommended that the sequence is not broken in the middle otherwise all normalization properties will not be read for the particular type.

Normalization rules for English language

ida.demo.address.normalization.regex.eng[0]=[CcSsDdWwHh]/[Oo]
ida.demo.address.normalization.regex.eng[1]=(M|m|D|d)(rs?)(.)
ida.demo.address.normalization.regex.eng[2]=(N|n)(O|o)(\\.)?
ida.demo.address.normalization.regex.eng[3]=[aA][pP][aA][rR][tT][mM][eE][nN][tT]${ida.norm.sep}apt 
ida.demo.address.normalization.regex.eng[4]=[sS][tT][rR][eE][eE][tT]${ida.norm.sep}st 
ida.demo.address.normalization.regex.eng[5]=[rR][oO][aA][dD]${ida.norm.sep}rd 
ida.demo.address.normalization.regex.eng[6]=[mM][aA][iI][nN]${ida.norm.sep}mn 
ida.demo.address.normalization.regex.eng[7]=[cC][rR][oO][sS][sS]${ida.norm.sep}crs 
ida.demo.address.normalization.regex.eng[8]=[oO][pP][pP][oO][sS][iI][tT][eE]${ida.norm.sep}opp 
ida.demo.address.normalization.regex.eng[9]=[mM][aA][rR][kK][eE][tT]${ida.norm.sep}mkt 
ida.demo.address.normalization.regex.eng[10]=1[sS][tT]${ida.norm.sep}1 
ida.demo.address.normalization.regex.eng[11]=1[tT][hH]${ida.norm.sep}1 
ida.demo.address.normalization.regex.eng[12]=2[nN][dD]${ida.norm.sep}2 
ida.demo.address.normalization.regex.eng[13]=2[tT][hH]${ida.norm.sep}2 
ida.demo.address.normalization.regex.eng[14]=3[rR][dD]${ida.norm.sep}3 
ida.demo.address.normalization.regex.eng[15]=3[tT][hH]${ida.norm.sep}3 
ida.demo.address.normalization.regex.eng[16]=4[tT][hH]${ida.norm.sep}4 
ida.demo.address.normalization.regex.eng[17]=5[tT][hH]${ida.norm.sep}5 
ida.demo.address.normalization.regex.eng[18]=6[tT][hH]${ida.norm.sep}6 
ida.demo.address.normalization.regex.eng[19]=7[tT][hH]${ida.norm.sep}7 
ida.demo.address.normalization.regex.eng[20]=8[tT][hH]${ida.norm.sep}8 
ida.demo.address.normalization.regex.eng[21]=9[tT][hH]${ida.norm.sep}9 
ida.demo.address.normalization.regex.eng[22]=0[tT][hH]${ida.norm.sep}0 
# Note: the common normalization attributes will be replaced at the end.
# Special characters are removed : . , - * ( ) [ ] ` ' / \ # "
# Replace special char with space. Trailing space is removed from property. As a workaround first replacing with " ." then removing the "."
ida.demo.common.normalization.regex.any[0]=[\\.|,|\\-|\\*|\\(|\\)|\\[|\\]|`|\\'|/|\\|#|\"]${ida.norm.sep} .
# Trailing space is removed from property. As a workaround first replacing with " ." then removing the "."
ida.demo.common.normalization.regex.any[1]=\\s+${ida.norm.sep} .
ida.demo.common.normalization.regex.any[2]=\\.${ida.norm.sep}

Normalization rules for Non-English language

For non-english languages, the non-english words needs to be converted into UTF-16 and then copied to the configuration. For example, convert the Unicode characters to UTF-16.

Before conversion: ida.demo.address.normalization.regex.hin[0]=पहली${ida.norm.sep}पहला

After conversion: ida.demo.address.normalization.regex.hin[0]=\u092a\u0939\u0932\u0940${ida.norm.sep}\u092a\u0939\u0932\u093e

This repository contains the UI code for the Resident portal. To know more about the features and functions present on the portal, refer here.

Build and Deployment

• Install node.js- To build the angular code using angular cli that runs on node, recommended Node: 14.17.3, Package Manager: npm 6.14.13

• Install angular cli – To install angular cli for building the code into deployable artifacts. Follow the following steps to install angular cli on your system.

  • npm install -g @angular/cli (to install angular cli)

  • ng --version (to verify angular is installed in the system) We recommend Angular CLI: 7.2.1

• Check out the source code from GIT – To download the source code from git, follow the steps below to download the source code on your local system.

  • git clone https://github.com/mosip/resident-ui.git (to clone the source code repository from git)

For Production build

• Build the code

  Follow the steps below to build the source code on your system.

  • Navigate to the resident-ui directory inside the cloned repository.

  • Run the command ng build "--prod" "--base-href" "." "--output-path=dist" in that directory to build the code.

• Build Docker image

  Follow the steps below to build the docker image on your system.

  • docker build -t name . (replace name with the name of the image you want, "." signifies the current directory from where the docker file has to be read.)

  • Example: docker build -t residentui .

• Run the Docker image

  Follow the steps to build a docker image on your system.

  • docker run –d –p 80:80 --name container-name image-name (to run the docker image created with the previous step,-d signifies to run the container in detached mode, -p signifies the port mapping left side of the":" is the external port that will be exposed to the outside world and the right side is the internal port of the container that is mapped with the external port. Replace container-name with the name of your choice for the container, replace image-name with the name of the image specified in the previous step)

  • Example: docker run -d -p 8080:8080 --name nginx residentui

• Now you can access the user interface over the internet via a browser.

  • Example: http://localhost:8080/#/dashboard

For Local build

• Build & deploy the code locally

  Follow the steps below to build the source code on your system.

  • Navigate to the resident-ui directory inside the cloned repository. Then, run the following command in that directory:

    • npm install

    • ng serve

• Now, you can access the user interface via the browser.

  • Example: http://localhost:4200

Overview

UI specs of resident module are used to configure the form fields across Resident Portal. 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 Resident Portal UI specs:

Introduction

Registration Processor (Regproc) is a backend processing engine to enable ID Lifecycle management. The diagram below shows the Registration Processor along with the other modules that contribute to issuing a Unique Identification Number(UIN) for an individual. Internally, Regproc follows the SEDA architecture where data flows via multiple stages till the UIN is issued.

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

1. Registration packets are uploaded by the Registration Client to the Packet Receiver.

2. After packet validation is done Regproc notifies the pre-registration application using the datasync service.

3. The quality of biometrics is checked using an external biometric SDK. This is done in Regproc's Quality Classifier stage.

4. Regproc shares biometric data with ABIS, Manual adjudication System, and Verification System. The policy for sharing this data is fetched from PMS.

5. The above data is shared by providing a URL that partners use to fetch data. This URL is obtained from the Datashare service.

6. Regproc's ABIS Middleware stage communicates with ABIS via Activemq. The ABIS performs deduplication and sends back the result to the Queue.

7. Regproc stores and updates applicant demographic and biometric information in the ID Repository. Also, activate or deactivate the applicant's UIN.

8. Regproc calls IDA Internal Authentication Service to authenticate Applicant(for update flow), introducer, operator, and supervisor(when bio auth mode is used to create packet).

9. After the UIN is processed the Printing Stage calls Credential Service to create credentials for print. This credential will be pushed to websub and the Printing systems will consume the same.

10. The Notification Service is used to send email/sms notifications to the applicant after the request processing is completed on the server.

11. Regproc connects to the external "Manual Adjudication System" via a queue. Regproc sends applicant information required for adjudication in the queue and the external adjudication system consumes it. The data is shared from mosip to an external adjudication system based on policy.

12. Regproc calls Key Manager for decrypting packets and encrypting information.

13. Regproc uses Masterdata Service to validate the center, machine, user, etc.

14. Regproc connects to Virus Scanner for scanning packets in the Packet Receiver Stage and Packet Uploader Stage

15. Each Stage in regproc calls Packet Manager to read information from the packet.

Stages and services

The Registration Processor contains several stages and services.

The registration packet flows through the various stages depending on the type of flow. See Registration Flows and Stage Sequence.

Note: The Print Stage has been renamed as the Credential Requestor Stage. For further information, please click here.

Build and deploy

Refer to repo.

Configurations

Refer to Configuration Guide.

Developer Guide

To know more about the developer setup, read the Registration Processor Developers Guide.

API

Refer to API Documentation.

Source code

Github repo.

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.

MOSIP provides backend APIs for this module along with a reference implementation of .

Pre-registration process

Create an application

• User provides consent

• The user provides demographic information

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

• A pre-registration request ID known as is generated and provided to the user.

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.

1. Fetch details with the help of Syncdata service.

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

3. Log all events.

4. Pre-Registration interacts with Keycloak via . The Pre-Reg module communicates with endpoints of other MOSIP modules. However, to access these endpoints, a token is required. This token is obtained from Keycloak.

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.

9. Registration clients use the to get the pre-reg application details for a given registration center, booking date, and AID.

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:

For more details, refer to the .

Pre-registration portal

MOSIP provides a reference implementation of the pre-registration portal that may be customized as per country needs. The sample implementation is available at the . For getting started with the pre-registration, refer to the

Build and deploy

To access the build and read through the deployment instructions, refer to the .

Configurations

For details related to Pre-registration configurations, refer to .

Developer Guide

To know more about the developer setup, read the .

API

Refer to .

Source code

.

What is .well-known folder?

The ".well-known" folder is a convention used in web development to provide a standardized location for certain files or resources that need to be publicly accessible and discoverable. It typically resides at the root level of a website or web server. The purpose of this folder is to make it easy for web clients (browsers, applications, or services) to find important files or resources related to web services and security.

Why should we use ".well-know" directory in MOSIP?

MOSIP can use the ".well-known" directory to serve the following purposes:

• Standardization: To provide a standardized location for specific public files and resources related to web services and security. It makes it easier for developers and web clients using MOSIP to know where to look for important information.

• Security: Security-related files and resources can be placed in the ".well-known" directory, such as the public certificate for encryption and signature verification can be placed here.

• Interoperability: By following the ".well-known" convention, web developers using MOSIP can ensure interoperability with various web standards and protocols. For example, MOISP shares the context file which contains the structure of its Verifiable Credentials.

• Ease of Configuration: Web servers can be configured to serve files from the ".well-known" directory without needing custom configurations for each specific resource. This simplifies the server setup and maintenance process.

• Transparency: For matters related to security policies and contact information, such as in the "security.txt" file, placing them in a well-known location makes it transparent and easily accessible to anyone interested in the website's security practices.

How is ".well-known" directory used in MOISP?

MOSIP's ".well-know" directory contains three files,

• controller.json

• mosip-context.json

• public-key.json

controller.json

The "controller.json" file is used in MOSIP to share the details of the public key using which a MOSIP-issued verifiable credential can be asserted.

mosip-context.json

The "mosip-context.json" file contains the schema of the subject in the MOSIP-issued verifiable credential.

public-key.json

The "public-key.json" file contains the public key using which the signature of the MOSIP-issued verifiable credential can be asserted.

The Resident Portal Guide for Collab Environment provides a comprehensive introduction to the services available on Resident Portal, as well as a guide on how to navigate its features.

Resident Portal is a user-friendly web-based platform designed to assist residents in accessing services related to their Unique Identification Number (UIN). This portal allows residents with a UIN to conveniently manage their UIN, protect their identity, track requests, and obtain personalized cards. For a more detailed overview of the features offered, please visit .

This Resident Portal Demo Setup guide serves as a tool to demonstrate the impressive capabilities of MOSIP's system. Let's embark on this journey together to explore the potential of Resident Portal.

Please note that for developers setting up Resident Portal locally, refer to the .

Pre-requisites

• Accessing Resident Portal in Collab environment does not require any complex setup.

• All you need is a UIN or a VID and you are good to go!

• To get your UIN credentials for Collab environment follow the below steps:

  • The provision of a UIN (Unique Identification Number) as a demo credential will enable you to have a firsthand experience of the Resident Portal's capabilities and explore its various features.

  • Now you can self generate your own UIN Credential using the .

    • Click on the Get UIN button located at the top-right corner of the page. This will open the , Alternatively, you can simply click on this to self register. You need to duly fill the self registration form.

    • On successful registration the UIN is sent to you over the email you used for registration, For more details you follow the .

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

Step-by-Step Process

Step 1: Access Resident Portal

Visit the following URL to access Resident Portal in Collab environment:

Step 2: Login

The recommended method for accessing the Resident Portal in the Collab environment is to use a valid UIN (Unique Identification Number), which can be obtained by completing the form provided. This is one of the options available for logging in and accessing UIN-related services on the Resident Portal.

There are multiple methods for logging in to access UIN services on the Resident Portal:

1. Login with Inji: To download and use the Inji application, click .

2. Login with Biometrics: To set up a biometrics device on your system, click .

3. Login with OTP (One-Time Password): Enter UIN/VID received from our end and use 111111 as OTP, for login to Resident Portal in Collab environment.

Step 3: Explore the features of Resident Portal

• To access registration related information, click .

• Go to Get Information section.

  • Click Registration Centers to get the list of Registration Centers near you or to look for Registration Centers based on location hierarchy.

  • Click Supporting Documents to get the list of documents that Resident Portal supports.

• To download the UIN card or to know the status of your AID, click .

  • Next, go to Get My UIN section.

• To book an appointment for a new enrolment, click .

  • Go to Book an Appointment section.

  • Explore the steps of Pre-registration Portal to book an appointment.

• To verify your email ID or phone number, click .

  • For Email verification- Use the OTP received on your email, as provided at the time of UIN creation.

  • For Phone number verification - Since our mobile services are temporarily unavailable, please use the email services.

• To access all the features of Resident portal in MOSIP, click to login.

• For more information, refer to our .

Additional Resources

To get more information about Resident Portal, click .

You will be able to explore and get a better understanding of Resident Portal configurations, UI, deployment, and OIDC client configuration to mention a few.

By adhering to these instructions, you will acquire the necessary knowledge to effortlessly configure the Resident Portal and proficiently utilize all of its functionalities.

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.

• Navigate to .

• Provide a detailed description about 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. Wishing you a pleasant experience!

Overview

Registration Processor(Regproc) is a backend processing engine to enable the ID Lifecycle management. It has several stages and services, registration packet flows through various stages depending on the type of flow.

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

Software setup

Below are a list of tools required in Registration Processor:

1. JDK 11

2. Any IDE (like Eclipse, IntelliJ IDEA)

3. Apache Maven (zip folder)

4. pgAdmin

5. Git

6. Notepad++ (optional)

7. lombok.jar (file)

8. settings.xml (document)

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

1. Download lombok.jar and settings.xml from here.

2. Unzip Apache Maven and move the unzipped folder in C:\Program Files and settings.xml to conf folder C:\Program Files\apache-maven-3.8.4\conf.

3. Install Eclipse, open the lombok.jar file and wait for some time until it completes the scan for Eclipse IDE and then click Install/Update.

4. Check the Eclipse installation folder C:\Users\userName\eclipse\jee-2021-12\eclipse to see if the lombok.jar is added. By doing this, you don't have to add the dependency of lombok in your pom.xml file separately as it is auto-configured by Eclipse.

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

Code setup

For the code setup, clone the registration repository from and follow the guidelines mentioned in the Code Contributions.

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

1. For the environment setup, you need an external JAR that is available here with different versions. (E.g.: You can download kernel-auth-adapter.jar and add to project Libraries → Classpath → Add External JARs → Select Downloaded JAR → Add → Apply and Close).

2. Clone mosip-config repository.

3. Create an empty folder inside the mosip-config with sandbox-local name and then copy and paste all the config files inside sandbox-local folder except .gitignore, README and LICENSE.

4. As Registration Processor is using two properties files, registration-processor-default and application-default, you will have to configure them according to your environment. The same files are available here for reference.

5. To run the server, two files are required- kernel-config-server.jar and config-server-start.bat.

6. Put both the files in the same folder and change the location attribute to sandbox-local folder in config-server-start.bat file and also check the version of kernel-config-server.jar towards the end of the command.

Example:

java -jar -Dspring.profiles.active=native -Dspring.cloud.config.server.native.search-locations=file:C:\Users\myDell\mosipProject\mosip-config\sandbox-local -Dspring.cloud.config.server.accept-empty=true -Dspring.cloud.config.server.git.force-pull=false -Dspring.cloud.config.server.git.cloneOnStart=false -Dspring.cloud.config.server.git.refreshRate=0 kernel-config-server-1.2.0-20201016.134941-57.jar.

7. Run the server by opening the config-server-start.bat file.

The server should now be up and running.

8. Before running any application of Registration Processor, replace the below properties in bootstrap.properties:

spring.cloud.config.uri=http://localhost:51000/config

spring.cloud.config.label=master

spring.profiles.active=default

spring.profiles.active can be dmz or mz(default)

9. An alternative approach to start the application is to place the dependency of application to be executed in the pom of MOSIP stage executor update maven and place above mentioned properties in the bootstrap.properties and then start MOSIP stage executor.

The documentation here will guide you through the pre-requisites and the other necessary details required for Android Registration Client developer setup.

The android-registration-client repository contains the Android Registration Client software for MOSIP. The feature-flutter branch focuses on integrating Flutter into the client.

Setup

To set up the Android Registration Client with Flutter and Android Studio, follow the steps below:

Prerequisites

• Flutter SDK (3.10.4): Install Flutter by following the official Flutter installation guide.

• Android Studio (or Any IDE of your choice): Download and install Android Studio from the official Android Studio website.

Step 1: Clone the Repository

The develop branch of android-reg-client is currently being actively developed. If you wish to access this branch, you can clone the repository by executing the following command in your terminal. Alternatively, you can download one of the releases available in the repository's release section.

git clone -b feature-flutter https://github.com/mosip/android-registration-client.git

Active Branches:

• release-1.0.x(developer release branch)

• develop(active development branch)

Step 2: Set up Flutter in Android Studio

1. To begin, launch Android Studio.

2. Next, select Open an existing Android Studio project and navigate to the cloned repository.

3. Open the android-registration-client directory as a project in Android Studio.

4. In order to integrate Flutter with Android Studio, install the Flutter plugin by accessing File > Settings > Plugins and searching for Flutter. Proceed to click on Install to install the plugin.

5. To ensure proper functionality, configure the Flutter SDK path by navigating to File > Settings > Languages & Frameworks > Flutter and specifying the Flutter SDK path as the location where you have installed Flutter.

6. Finally, save the changes by clicking on the "Apply" button.

Customizing the Registration Client

• Styling of the application can be configured by modifying these files lib/utils/app_style.dart, lib/utils/app_config.dart

• Application language bundles can be added to this path lib/l10n After adding the bundle run the below command to generate Localization data (Required for the first time).

flutter gen-l10n

• The label and application logo can be changed here android/app/src/main/AndroidManifest.xml

Step 3: Build and Run the Application

• The pigeon.sh file consists of the necessary commands for downloading dependencies and generating Flutter - Android native communication code. Please execute the pigeon.sh file or execute the commands within the file separately.

• Ensure you have connected an Android device or initiated an Android emulator.

• Open the terminal within Android Studio or use an external terminal.

• Navigate to the android-registration-client directory.

• Run the following command to build and execute the application:

flutter run

Step 4: Build, debug, and release APK

Execute the commands below to debug and release the APK

// Debug APK
flutter build apk --debug

// Release APK
flutter build apk --release

Set up Mock MDS for Biometric Scan

The Mock MDS tool can be utilized to simulate the functionalities of biometric devices. The Mock MDS application is compliant with CTK standards and can serve as a substitute for Android SBI modules during testing and validation.

1. Install the Mock MDS application.

2. Access the Settings menu.

3. Under Device Configuration, choose Registration from the dropdown menu.

4. In P12 Configuration:

   • Enter the necessary credentials for the Device Key and upload the Device P12 file.

   • Enter the required credentials for the FTM Key and upload the FTM P12 file.

   • Complete all fields in MOSIP IDA Configuration.

5. In Modality Configuration, specify the quality score for Face, Finger, and Iris scans(these values can also be adjusted during testing).

6. Click on the Save button.

7. Go back to the Home Page and select LOAD AND VALIDATE CERTIFICATES.

A toast message will be displayed indicating the success of the validation process.

Note: To view the released version of the Mock SBI APK, click here.

To download the Mock SBI APK, click on camera-mds.zip.

Contributions

If you would like to contribute to the Android Registration Client, please follow the guidelines outlined here.

License

The Android Registration Client is licensed under the MIT License.

Support

If you encounter any issues or have any questions, please open an issue on the GitHub repository.

Sources

• GitHub- mosip/android-registration-client: Reference Android Registration Client Software - WIP

• Flutter- Get started: Install

• Android Studio- Download

Overview

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.

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

For the code setup, clone the Registration Client repository and follow the guidelines mentioned in the Code Contributions.

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

1. For the environment setup, you need an external dependency that is available here with different versions. (E.g.: You can download mock-sdk.jar and add to registration-services project Libraries → Classpath → Add External JARs → Select Downloaded JAR → Add → Apply and Close).

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.

3. Download openjfx-11.0.2_windows-x64_bin-sdk.zip from here, unzip and place it in your local file system. This folder contains list of javafx related jars that are necessary for running Registration Client UI.

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

• Dockerfile is available under registration-client repository.

• 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)

Rename - “Print Stage” to “Credential Requestor Stage”

Note: The change in nomenclature from 'Print Stage' to 'Credential Requestor Stage' was implemented to enhance clarity and better reflect its expanded functionality.

History of Print Stage in MOSIP

In MOSIP 0.9.0, the "print stage" was primarily designed to facilitate the submission of printing requests. The core functionality of print stage revolved around initiating a request for the physical printing of credentials. However, as the system evolved and incorporated additional features, the scope of the print stage expanded beyond its original purpose.

In the evolved approach, at the print stage, apart from processing a print request, the application enables partner-specific print capabilities. Contrary to its initial purpose, the print stage no longer serves the singular function of printing credentials. Instead, it has transformed into a multifaceted component with enhanced set of responsibilities.

In the current system, the print stage's role extends beyond traditional printing activities. Its primary function now revolves around initiating a request for credential generation once a Unique Identification Number (UIN) is generated. This request is not aimed at physical printing but serves as a mechanism to gather additional information for specific partners. These partners may require supplementary data beyond what is initially generated with the UIN.

Therefore, in the evolved approach, the print stage has transitioned from being a straightforward printing request to a more versatile component that manages the initiation of credential requests tailored to partner-specific information needs. This adaptation reflects the system's responsiveness to changing requirements and the dynamic nature of credentialing processes. This reason led us to re-name the “Print Stage” to the “Credential Requestor Stage” as this name serves the purpose of the work executed by this stage.

Introduction

The Credential Requestor Stage in MOSIP, formerly known as the Print Stage, is a crucial component used to request credentials for configurable partners after the UIN is generated. This stage enables countries to share information with multiple partners, each with specific needs after UIN generation. Partners, such as Print Partners and Digital Card Partners, may require demographic or biometric information to perform operations.

What is the credential requestor stage?

The Credential Requestor Stage plays a crucial role in the MOSIP system, serving as a mechanism to solicit credentials from configurable partners post-UIN generation. In this context, partners, previously registered with MOSIP, require demographic and biometric data to execute their respective operations. For instance, a Print Partner necessitates specific demographic details for the purpose of printing cards. Similarly, digital card partners seek demographic information to generate digital cards. Additionally, DPGs might seek confirmation of successful UIN generation to integrate this information into their systems. The Credential Requestor Stage facilitates various use cases where the country aims to share pertinent information with multiple partners subsequent to UIN generation.

What are the latest changes done in the credential requestor stage?

Partner Profile Configuration

MOSIP has introduced a new partner profile for the Credential Requestor Stage. The partner profiles are maintained here.

Sample Partner Profile:

jsonCopy code{
  "partners": [
    {
      "id": "digitalcardPartner",
      "partnerId": "mpartner-default-digitalcard",
      "credentialType": "PDFCard",
      "template": "RPR_UIN_CARD_TEMPLATE",
      "appIdBasedCredentialIdSuffix": ".pdf",
      "process": null,
      "metaInfoFields": null
    },
    {
      "id": "printPartner",
      "partnerId": "mpartner-default-print",
      "credentialType": "euin",
      "template": "RPR_UIN_CARD_TEMPLATE",
      "appIdBasedCredentialIdSuffix": null,
      "process": null,
      "metaInfoFields": null
    },
    {
      "id": "opencrvsPartner",
	  "partnerId": "opencrvs-partner",
      "type": "opencrvs",
      "template": "RPR_UIN_CARD_TEMPLATE",
      "process": ["OPENCRVS_NEW"],
      "metaInfoFields": ["opencrvsBRN"]
    }
  ]
}

Field Description

• id: Logical unique identifier

• partnerId: Partner identifier configured in MOSIP

• credentialType: Type of credential configured in MOSIP

• template: Template used for generating the credential

• appIdBasedCredentialIdSuffix: Applicable for special conditions where the credential ID is the application ID itself, with an optional suffix (for example, .pdf). Currently, this is applicable for digital card credentials.

• process: If applicable for a particular process. If applicable for all processes, value is null

• metaInfoFields: Meta information fields to be sent as additional information while generating the credential

Configuration Changes

Once the partner profile is configured, the System Integrator (SI) should make changes to the following configurations:

• mosip.registration.processor.credential.partner-profiles: Specify the file name for the partner profiles. By default its → registration-processor-credential-partners.json. If a country intends to change the file name only then this configuration should be updated otherwise default configuration can be used

• mosip.registration.processor.credential.default.partner-ids: Specify default partner IDs for which credentials will be created automatically

• mosip.registration.processor.credential.conditional.partner-id-map: Define conditions for conditional partners. Credentials for these partners will be requested only if the conditions are met. Use MVEL expressions for conditions

• mosip.registration.processor.credential.conditional.no-match-partner-ids: Specify a partner ID to be used when no conditions are met for conditional partners

Conditional Partner Requests

• The stage will create credentials for default partner IDs by default

• For conditional partners, credentials will be requested only if they match a particular MVEL expression

• MVEL expressions can be written on any identity field as well as meta info field

• If there is no condition match for conditional partners, SI can configure a no-match partner, which will be used when no conditional partner match is found

Configuration File Locations

1. Credential Requestor Stage Configuration: Click here to view credential requestor stage configuration details.

2. Partner Profile Configuration: Click here to view partner profile configuration details.

Conclusion

The Credential Requestor Stage configuration is an essential part of MOSIP's functionality, enabling seamless communication with partners and ensuring the secure exchange of information post-UIN generation.

Note: Ensure that configured IDs are logically unique and consistent across future configurations.

Overview

ID Schema is a standard JSON schema that defines dataset that can be stored in the Identity repository for a resident. The schema allows the adopters to customize the fields that's needed for running the identity program.

Defining the ID Schema is the first step towards creating a foundational ID system. Once defined, all applications built on top of the MOSIP platform must conform to the same.

One should not confuse ID Schema with what is seen on the screen of the Registration client/ Pre-registration. ID Schema is the final data that you would like to store against each user in the final ID Repository. Quite often we collect more data than listed in ID Schema. This is essential to validate the user's claim. We should consider these data as transactional and it will never reach the final ID Repository.

Understanding ID Schema

This guide is intended for adopters who would customize the default ID Schema to suit the needs of a specific deployment.

Terminology

• Field: Unit of data collected from residents (eg. fullName, dateOfBirth, proofOfIdentity etc).

• Field attribute: Qualification of Field (e.g.: fieldCategory, fieldType, etc).

• Definition: Custom data types are defined for collecting different types of data:

  • simpleType: Multiple languages.

  • documentType: Document metadata.

  • biometricType: Biometric file CBEFF XML metadata

JSON keys

• bioAttributes:

  • leftEye, rightEye, leftIndex, leftRing, leftLittle, leftMiddle, rightIndex, rightRing, rightMiddle, rightLittle, rightThumb, leftThumb, face,

• fieldCategory

  • none: Cannot be used for any purpose. But will be stored in id.json (default subpacket). These are used in exceptional cases when we need to store some data for future reference in case of investigating an ID fraud or if law mandates the storage of such data.

  • pvt: Private information, can be used in authentication. A limited data that can be used for authentication & kyc.

  • kyc: Information that can be disclosed to partners either as a credential or through the ekyc API's.

  • evidence: Field is treated as proof and may be subjected to removal. In certain countries law mandates deletion of such data once the Identity of the user is verified. Marking some of the fields as evidence helps in deleting them without violating the source of truth signatures.

  • optional: Field is treated as proof and will be removed after a predefined interval (defined as policy).

• format

  • lowercased: Value stored in lower case format

  • uppercased: Value stored in upper case format

  • none: No format applied to the data

• validators

  • type: Validation engine type. Supported type as of now is regex.

  • validator: Based on the type the actual script is placed here. In case the type is regex then the actual regex pattern is used here.

  • arguments: Array to hold parameter or dependent field IDs required for validation.

• subType

  • For every documentType field, document category code must be the value of this key. This document category code is used to validate the provided document types in the ID object.

Refer to the sample ID Schema. A guide to customising the same is given below.

ID schema is loaded as a part of master data to identity_schema table in mosip_masterdata DB.

Dependencies

If any changes are made to the default ID Schema, make sure the following dependencies are updated as well:

1. UI Specifications

   • Pre-registration

   • Registration Client

2. Identity Mapping JSON

3. ID Authentication Mapping JSON

4. Applicanttype MVEL

Versions of ID Schema

ID Schema is identified based on it's version in the MOSIP system. On publishing of an ID Schema, the schema is versioned. Every ID Object stores the ID Schema version which is validated during ID Object validation.

Good Practice

The following is the list of good practices that MOSIP recommends for creating your ID Schema.

• As a privacy by design practice, it is recommended that the number of fields is kept to a usable minimum in order to avoid profiling.

• Larger number of data results in serious data quality issues.

• Keeping the fields minimum ensures everyone is inclusively added to the foundational identity.

• As a best guide, limit the total number of fields to be less than 10.

• Stick to one version of ID Schema for better compatibility.

Overview

This guide helps the operator in setting up the registration client.

Know your machine TPM keys

A Trusted Platform Module (TPM) is a specialized chip on a local machines that stores RSA encryption keys specific to the host system for hardware authentication.The pair is maintained inside the chip and cannot be accessed by software. 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.

To extract the TPM public key, use the TPM key extractor utility.

Prerequisites

To onboard the machine and the operator, the Admin needs to:

1. Create and activate the registration client machine using Admin portal.

2. Create a user/operator account in Keycloak

3. Assign the operator a role of either the Supervisor or Officer using the Admin portal.

4. Finally, perform the User Zone mapping and User Center mapping in the Admin portal.

System prerequisites:

• CPU - Dual Core Processor - 2GHZ

• RAM - 16 GB

• Local Storage Disk Space - 500 GB

• USB 2.0 ports or equivalent hub.

• Physical machine with TPM 2.0 facility.

• Windows OS [10 v]

Registration client setup

To setup the registration client:

1. Download the reg-client.zip from the hosted server.

2. Unzip the client. You can see the directory structure below.

3. Click run.bat to launch registration client.

Launching the registration client

The client always launches with the pre-loader screen which displays the information about the network status, build status verification, online status, etc.

1. First time launch

• After the pre-loader, the login screen is displayed.

• Any valid operator credentials can be provided to authenticate and start the initial sync.

• On successful intial sync, the operator will be prompted to restart the application.

• After the first launch, the operator can notice .mosipkeys and db folders created under the registration client setup folder.

Note: Deletion of either the .mopsipkeys or the db folder makes the application get into an invalid state and hence will fail to launch. To be able to launch the client again, the operator should make sure that both the folders are removed and then re-launch the client.

1. On the next launch after the initial sync,

• The registration client login page provides the operator an option to select the language for viewing the registration client UI.

• After successful login, the operator either lands into the operator onboard page or the home page.

For more details on operator onboarding, refer to Operator onboarding guide.

For more details on Home page, refer to Registration client home page.

Modes of operation

• Offline- Operator can use the registration client in offline mode to only do the registrations and EOD process. During offline mode, the operator authentication will be based on locally saved password hash. An operator can work in offline mode only if they have logged into to the registration client being online atleast once.

• Online- Machine must be online for the registration client first launch. For any server-client sync or vice-versa, the registration client must be online. In the online mode, the client reaches out to the server for password authentication.

Note: On successful onboard of the operator, biometric templates of the operator are stored locally. Biometric authentication does not reach out to the server everytime, instead it is validated based on the locally stored templates on the registration client machine.

Setting up MOCK SBI (MDS)

In the development environment, Registration client can be tested using mock SBI. Find the instructions to build and run the mock SBI, click here.

Troubleshooting

1. Incorrect username/password

-> Cross-check the machine keys mapping in server ('Machine not found' error in logs)

-> Cross-check machine status

-> 'Invalid Request' error in log - Check your machine time, it shouldnt be less or greater than local timezone datetime (usually accepted lag is +5/-5 minutes)

-> check logs/registration.log for more details

2. Configuration / masterdata Sync failed

-> check if kernel-syncdata-service is up.

Settings Schema

Default settings schema is configured as below:

[
	{
		"name":"scheduledjobs",
		"description":{
			"ara":"إعدادات الوظائف المجدولة",
			"fra":"Paramètres des travaux planifiés",
			"eng":"Scheduled Jobs Settings"
		},
		"label":{
			"ara":"إعدادات الوظائف المجدولة",
			"fra":"Paramètres des travaux planifiés",
			"eng":"Scheduled Jobs Settings"
		},
		"fxml":"ScheduledJobsSettings.fxml",
		"icon":"scheduledjobs.png",
		"order":"1",
		"shortcut-icon":"scheduledjobs-shortcut.png",
		"access-control":[
			"REGISTRATION_SUPERVISOR"
		]
	},
	{
		"name":"globalconfigs",
		"description":{
			"ara":"إعدادات التكوين العامة",
			"fra":"Paramètres de configuration globale",
			"eng":"Global Config Settings"
		},
		"label":{
			"ara":"إعدادات التكوين العامة",
			"fra":"Paramètres de configuration globale",
			"eng":"Global Config Settings"
		},
		"fxml":"GlobalConfigSettings.fxml",
		"icon":"globalconfigs.png",
		"order":"2",
		"shortcut-icon":"globalconfigs-shortcut.png",
		"access-control":[
			"REGISTRATION_SUPERVISOR"
		]
	},
	{
		"name":"devices",
		"description":{
			"ara":"إعدادات الجهاز",
			"fra":"Réglages de l'appareil",
			"eng":"Device Settings"
		},
		"label":{
			"ara":"إعدادات الجهاز",
			"fra":"Réglages de l'appareil",
			"eng":"Device Settings"
		},
		"fxml":"DeviceSettings.fxml",
		"icon":"devices.png",
		"order":"3",
		"shortcut-icon":"devices-shortcut.png",
		"access-control":[
			"REGISTRATION_SUPERVISOR",
			"REGISTRATION_OFFICER"
		]
	}
]

Clicking on in the home page opens a pop-up displaying configured Settings page as per the above sample settings schema.

Device settings

• All the connected devices are listed in this page.

• Option to scan for SBI for any specific port range is available in this page.

• If more than one device is idenitied, operator can choose amongst the listed devices to set the default device for the current login session.

• Access control on this page is controlled via the settings-schema.

Global configuration

• All the Registration Client related configuration key-value pairs are listed in this page.

• Operator can set the local preference on the server configraton value, applicable only for permitted configuration keys.

• Access control on this page is controlled via the settings-schema.

Scheduled Jobs

• All the available background jobs are listed here along with their cron expression.

• Every job's next and previous trigger time is listed along with the job name.

• Privileged operator can update the cron expression of any job.

• Synchornize Data in home page will trigger all of these listed jobs with just one click.

• If the operator needs to trigger specific job, the same can be handled in this page.

• Access control on this page is controlled via the settings-schema.

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

OTP Request Service is used by Authentication/e-KYC Partners to generate OTP for an individual's UIN/VID. The generated OTP is stored in IDA DB for validation during OTP Authentication.

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

Software setup

Below are a list of tools required in ID Repository Services:

1. JDK 11

2. Any IDE (like Eclipse, IntelliJ IDEA)

3. Apache Maven (zip folder)

4. pgAdmin

5. Postman

6. Git

7. Notepad++ (optional)

8. lombok.jar (file)

9. settings.xml (document)

Follow the steps below to set up ID Repository Services on your local system:

1. Download lombok.jar and settings.xml from .

2. Unzip Apache Maven and move the unzipped folder in C:\Program Files and settings.xml to "conf" folder C:\Program Files\apache-maven-3.8.4\conf.

3. Install Eclipse, open the lombok.jar file and wait for some time until it completes the scan for Eclipse IDE and then click Install/Update.

4. Check the Eclipse installation folder C:\Users\userName\eclipse\jee-2021-12\eclipse to see if the lombok.jar is added. By doing this, you don't have to add the dependency of lombok in your pom.xml file separately as it is auto-configured by Eclipse.

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

Code setup

For the code setup, clone the repository and follow the guidelines mentioned in the .

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 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

1. For the environment setup, you need an external JAR that is available with different versions. (E.g.: You can download kernel-auth-adapter.jar and add to project Libraries → Classpath → Add External JARs → Select Downloaded JAR → Add → Apply and Close).

2. Clone .

3. Create an empty folder inside the mosip-config with sandbox-local name and then copy and paste all config files inside sandbox-local folder except .gitignore, README and LICENSE.

4. As ID Authentication is using two properties files, id-authentication-default and application-default, you will have to configure them according to your environment. The same files are available for reference.

Properties to be updated:

application-default.properties

• mosip.mosip.resident.client.secret = <current_password>.

• db.dbuser.password=<password>.

• mosip.kernel.xsdstorage-uri=file:///home/user/Desktop/tspl/mosip-config/sandbox-local/(i.e. sandbox-local folder location).

• Comment this out auth.server.admin.issuer.internal.uri in application-default.properties file because you already have this auth.server.admin.issuer.uri , and hence there is no need of auth.server.admin.issuer.internal.uri.

• mosip.identity.mapping-file=<Path_to_identity_mapping_json_file>. (For Example: file:///home/user/Desktop/tspl/mosip-config/sandbox-local/identity-mapping.json)

id-authentication-default.properties

• ......

• ......

5. To run the server, two files are required- and .

6. Put both the files in the same folder and change the location attribute to sandbox-local folder in config-server-start.bat file and also check the version of kernel-config-server.jar towards the end of the command.

Example:

java -jar -Dspring.profiles.active=native -Dspring.cloud.config.server.native.search-locations=file:C:\Users\myDell\mosipProject\mosip-config\sandbox-local -Dspring.cloud.config.server.accept-empty=true -Dspring.cloud.config.server.git.force-pull=false -Dspring.cloud.config.server.git.cloneOnStart=false -Dspring.cloud.config.server.git.refreshRate=0 kernel-config-server-1.2.0-20201016.134941-57.jar.

7. Run the server by opening the config-server-start.bat file.

The server should now be up and running.

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 will create a Java application which you can see in debug configurations and then change its name. (e.g.: project name with environment - "Auth-Otp-Service-Dev").

2. Open the arguments and pass this -Ddomain.url=dev.mosip.net -Dapplication.base.url=http://localhost:8090 -Dspring.profiles.active=default -Dspring.cloud.config.uri=http://localhost:51000/config -Dspring.cloud.config.label=master in VM arguments.

3. Here, the domain URL represents the environment on which you are working (eg., it can be dev2.mosip.net or qa3.mosip.net).

4. Click Apply and then debug it (starts running).

Authentication OTP Service API

• For API documentation, refer .

Overview

The services mentioned below are used by Authentication/e-KYC Partners.

• Authentication service- used to authenticate an individual's UIN/VID using one ore more authentication types.

• KYC Authentication service- used to request e-KYC for an individul's UIN/VID using one ore more authentication types.

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

Software setup

Below are a list of tools required in ID Repository Services:

1. JDK 11

2. Any IDE (like Eclipse, IntelliJ IDEA)

3. Apache Maven (zip folder)

4. pgAdmin

5. Postman

6. Git

7. Notepad++ (optional)

8. lombok.jar (file)

9. settings.xml (document)

Follow the steps below to set up ID Repository Services on your local system:

1. Download lombok.jar and settings.xml from .

2. Unzip Apache Maven and move the unzipped folder in C:\Program Files and settings.xml to "conf" folder C:\Program Files\apache-maven-3.8.4\conf.

3. Install Eclipse, open the lombok.jar file and wait for some time until it completes the scan for Eclipse IDE and then click Install/Update.

4. Check the Eclipse installation folder C:\Users\userName\eclipse\jee-2021-12\eclipse to see if the lombok.jar is added. By doing this, you don't have to add the dependency of lombok in your pom.xml file separately as it is auto-configured by Eclipse.

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

Code setup

For the code setup, clone the repository and follow the guidelines mentioned in the .

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 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

1. For the environment setup, you need an external JAR that is available with different versions. (E.g.: You can download kernel-auth-adapter.jar and add to project Libraries → Classpath → Add External JARs → Select Downloaded JAR → Add → Apply and Close).

2. Clone .

3. Create an empty folder inside the mosip-config with sandbox-local name and then copy and paste all config files inside sandbox-local folder except .gitignore, README and LICENSE.

4. As ID Authentication is using two properties files, id-authentication-default and application-default, you will have to configure them according to your environment. The same files are available for reference.

Properties to be updated:

application-default.properties

• mosip.mosip.resident.client.secret = <current_password>.

• db.dbuser.password=<password>.

• mosip.kernel.xsdstorage-uri=file:///home/user/Desktop/tspl/mosip-config/sandbox-local/(i.e. sandbox-local folder location).

• Comment this out auth.server.admin.issuer.internal.uri in application-default.properties file because you already have this auth.server.admin.issuer.uri , and hence there is no need of auth.server.admin.issuer.internal.uri.

• mosip.identity.mapping-file=<Path_to_identity_mapping_json_file>. (For Example: file:///home/user/Desktop/tspl/mosip-config/sandbox-local/identity-mapping.json)

id-authentication-default.properties

• ......

• ......

5. To run the server, two files are required- and .

6. Put both the files in the same folder and change the location attribute to sandbox-local folder in config-server-start.bat file and also check the version of kernel-config-server.jar towards the end of the command.

Example:

java -jar -Dspring.profiles.active=native -Dspring.cloud.config.server.native.search-locations=file:C:\Users\myDell\mosipProject\mosip-config\sandbox-local -Dspring.cloud.config.server.accept-empty=true -Dspring.cloud.config.server.git.force-pull=false -Dspring.cloud.config.server.git.cloneOnStart=false -Dspring.cloud.config.server.git.refreshRate=0 kernel-config-server-1.2.0-20201016.134941-57.jar.

7. Run the server by opening the config-server-start.bat file.

The server should now be up and running.

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 will create a Java application which you can see in debug configurations and then change its name. (e.g.: project name with environment - "Auth-Service-Dev").

2. Open the arguments and pass this -Ddomain.url=dev.mosip.net -Dapplication.base.url=http://localhost:8090 -Dspring.profiles.active=default -Dspring.cloud.config.uri=http://localhost:51000/config -Dspring.cloud.config.label=master in VM arguments.

3. Here, the domain URL represents the environment on which you are working (eg., it can be dev2.mosip.net or qa3.mosip.net).

4. Click Apply and then debug it (starts running).

Authentication Service API

• For API documentation, refer .

This guide contains all the details you may want to know about the operator onboarding.

Creating the first operator in MOSIP

To generate the first operator in MOSIP eco-system, refer to the steps below.

The Admin needs to:

1. Create the role Default in KeyCloak with all the other roles.

2. Create the operator' user account in KeyCloak.

3. Assign the operator user account with the Default role.

4. Perform Zone and Center mapping for the operator using the Admin Portal.

5. Onboard the operator machine using the Admin Portal. Machine' details can be extracted using the

The operator will need to:

1. Download the latest registration client and login with the credentials set in KeyCloak. The operator will automatically skip Operator/Supervisor onboarding and reaches the home page of the registration client.

2. Register themselves in MOSIP and get a RID and UIN.

Once the operator is registered:

• The Admin changes the role of the operator to either REGISTRATION_OFFICER or REGISTRATION_SUPERVISOR.

• Deletes the role Default from KeyCloak so that no other user has the role Default.

• This operator can now register and onboard other Supervisors and Officers.

On-boarding an operator

• Admin needs to map the operator' UIN in KeyCloak under Attributes with attribute name as individualId.

• Admin needs to remove the "Default" role mapping for the operator' user account if it exists.

• The operator needs to login (password based) to the Registration Client using Keycloak credentials.

• The operator needs to ensure that the Registration Client machine is online.

• The operator will land into the below page and needs to click on Get Onboarded

• The operator needs to provide their biometrics and click Save.

• All the biometric modalities displayed in the Operator biometrics page must be captured before clicking on Save.

• Captured biometrics quality must be greater than or equal to the threshold displayed in the UI.

  Note- The threshold values are configurable and can be set as per the ID issuer.

• After successful onboarding, the operator is automatically re-directed to the .

Note:

• After successful onboarding of the operator, the templates are extracted from the captured biometrics using configured Bio-SDK. The extracted templates are stored in Derby DB. This can be used later for operator' biometric-authentication and also for local de-duplication checks during registration.

• After the first login and successful on-boarding, the registration client would mandate the operator to login with the configured authentication mode decided by the administrator.

• Any number of operators can login to a registration client machine but they need to be mapped to the same center where the machine is onboarded.

• Login operator' user ID is case-insensitive.

Summarizing, on-boarding of an operator is successful only if,

• The operator is active and not block listed.

• The operator and the machine belongs to the same center.

• The operator's User ID is mapped to their UIN.

• The operator's biometric authentication is successful during on-boarding.

• The system is online during on-boarding.

Operator onboarding workflow

1. Operator logs into Registration Client for the first time and is redirected to Onboarding screen. Here, they need to capture all their biometrics and then click SAVE button.

2. Request from Registration Client goes to for operator authentication.

3. Registration Processor passes this request to where it checks whether the user is mapped to a valid UIN and then matches the biometrics sent in the request with the biometrics of the mapped UIN.

4. Success/Failure response sent back to Registration Processor based on the authentication result.

5. Registration Processor sends back this response to Registration Client.

6. After successful authentication, the captured biometrics are sent to configured Bio-SDK to extract templates.

7. Extracted templates are sent back from .

8. The extracted templates are stored in local Derby DB.

9. These templates stored in local DB can be used later for operator's biometric-authentication and also for local de-duplication checks during registration.

Modes of login

• MOSIP supports single factor and multi factor login including password, iris, fingerprint, and face authentication for registration client. An administrative configuration setting determines the mode of authentication login.

• The registration client can authenticate an operator in offline mode using the locally stored biometrics templates (face/finger/iris) and password hash.

Temporarily lock the operator

The registration client temporarily locks the operator’s account in case they provides an invalid password/fingerprint/iris/face for X times continuously to login (X is configurable). The temporary account lock lasts for X minutes (X is again configurable).

Logout

An Operator can logout of the registration client by:

• Clicking on the Logout button,

• Closing the registration client,

• Being in-active on the registration client for configured amount of time after which they are automatically logged out.

• Upon logout, any unsaved data will be lost.

• Data will not be automatically saved in the database and will not be retained in memory though transaction details which is used for auditing will be captured and stored (except for PII data).

Note- Registration client provides an alerts to the operator ‘X’ minutes before reaching the auto logout time limit. Registration client displays a countdown timer in the alert. The operator can choose to dismiss the alert and continue working. This will also reset the timer to zero.

Resident Portal is a self-help web-b portal that can be used by the residents of a country to avail of the services related to their Unique Identification Number (UIN). The architecture, interface overview, and key services provided are discussed below:

1. Architecture

2. Interface overview

3. Key Services

   1. UIN services

      1. View My History

      2. Secure My ID

      3. Manage My VID

      4. Track My Request

      5. Download My Personalized Card

      6. Update My Data

      7. Share My Credential

   2. Get Information

      1. Supporting Document

      2. Registration Center

   3. Verify Email ID/Phone number

   4. Get My UIN

   5. Booking an Appointment