The Future of Digital Identity: Secure, Scalable and Open-Source.
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.
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.
Note: For more details on licensing, click .
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
Note: To read through the previous version of the documentation, please refer to our !
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.
Dive into interactive workshops,webinars and more.
Join the MOSIP community.
eSignet
Enabling Secure, Inclusive, and Seamless Digital Identity Verification.
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.
Explore more about eSignet.
Standards & Specifications
Ensuring secure and interoperable digital identity through global standards.
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.
✅
Inji
Empowering Trusted Digital Identity with Secure and Seamless Credential Verification.
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.
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.
CBEFF(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:
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.
Privacy and Security
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.
This page lists the standards and specifications published by MOSIP which are mentioned below:
Data Protection
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.
Biometric Capture:
A biometric device captures and signs biometric data before sending it to the Registration Client (PK2). Then registration client verifies the signature
Registration & Encryption:
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 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
Generate master symmetric encryption key K9.
Generate a 10,000 symmetric keys pool (ZKn). Encrypt each ZKn with K9 and store it in DB. (K12)
Randomly select one key from ZKn, and decrypt using K9.
Decryption by IDA
Generate master symmetric encryption key K18.
Decrypt data in Step 8 above using PK8.
Decrypt ZKn-IDA with K22 to get ZKn.
ID authentication flow
L1 devices contain to encrypt (DE1, K21) and sign (FK1) biometrics at the source and send them to the authentication client.
The authentication client further encrypts the auth request with the IDA-PARTNER public key.
IDA decrypts zero-knowledge data as given in and then performs a demographic and/or biometric authentication.
Sandbox Details
Seamless Integration with MOSIP: Explore Our Sandbox Environments.
Are you interested in integrating with MOSIP as a partner? We invite you to connect with us by completing the . 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.
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).
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.
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)
Hashed UIN Storage:
The UINs are hashed, encrypted, and stored in uin the table of mosip_idrepo DB. (K7.4)
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.
Demographic Data Storage:
Encrypted demographic data is stored in the Registration Processor Database. (K11)
Credential Issuance:
Encrypted resident data is shared with credential requestors and printers based on the subscribed policies. (K12)
Operator Authentication:
The Registration Client checks Keycloak to ensure that only authenticated operators can perform registrations.
Policy Validation for Data Transfer:
Derive new key ZKn' = ZKn + UIN/VID/APPID.
Encrypt biometric templates and demographics.
BIO = encrypt(bio/demo with ZKn').
Encrypt ZKn (this is done to share ZKn with IDA).
ZKn-IDA = encrypt(ZKn with K22)
Share the following with IDA:
ZKn-IDA
BIO
Random index (0 - 9999)
SHA-256 hash of UIN/VID/APPID
Share data in step 7 via standard Datashare encryption (which encrypts entire data with PK8).
Encrypt ZKn with K18 and store it at a random index.
Bio-data is stored as is.
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).
Understanding MOSIP’s Role in Foundational ID Systems.
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.
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:
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.
Digital ID DPI Framework
Blueprint for Scalable and Interoperable Identity Systems.
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.
Principles
The guiding foundation.
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 for more details.
Architecture
Modular, Secure, and Scalable: The Architectural Foundation of MOSIP.
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.
Discover how MOSIP's tools, components, and architecture come together.
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.
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.
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.
This document specifies a generic data structure and encoding mechanism for storing the Identity Data of a registered person using any ID platform. It also provides a transport encoding mechanism in a machine-readable optical format (QR).
2. Rationale
Once a person is registered in an identity system, their data serves as the foundation for identification, granting them access to social benefits and government services. The level of assurance in this identification process varies depending on the authentication methods employed. Low assurance is achieved through basic identifiers like ID numbers, demographic data, passwords, or PINs. Conversely, higher assurance levels are attained through one-time passwords (OTP) and biometrics.
Among these methods, biometric-based authentication, such as facial authentication, offers the highest level of assurance as it assures the presence of the individual. While this is effective for online systems & personal phones where verification is conducted on a server or a personal device; offline authentication presents challenges in maintaining a similarly high level of assurance. The offline authentication mechanism should work for people with no phone.
For instance, in a cross-border scenario, remote areas often face significant internet connectivity issues. Even when internet access is available, server reliability may be inconsistent. In such circumstances, scanning a standard QR code containing the person's facial photograph and identity information, alongside assurance that the data is country-signed, provides an additional layer of security and affirmation for the countries involved.
Please note: The trust layers required to sync the country's key are beyond the scope of this document. We assume the app scanning the QR code already has the country's key to verify.
To tackle the aforementioned challenge, we propose a standard CBOR-based QR Code that involves embedding a low-resolution image of the person with a minimal demographic dataset within the QR code. This QR code would be digitally signed by the ID authorities (Issuer) and then printed on a physical card. Subsequently, the signed data within the QR code can be utilized for facialauthentication. This approach also helps enhance interoperability.
Note: It is essential to recognize that QR codes have limitations regarding size. We suggest leveraging CBOR Web Token (CWT) with ED25519/ECC keys to generate a smaller signature and more condensed data.
3. Semantics
Claim 169 represents a JSON Object that includes the following ID attributes, as outlined in the table. You can find an illustration of the ID structure contained within Claim 169, as stated below:
3.1 CBOR Map Structure Overview
Note:
All the fields here are optional.
The issuer of IDClaim169 is expected to host the JWKS file at the standard .well-known URL. This allows relying parties to verify the signature of the issued IDClaim169.
Attribute #
Type
Attribute Name
Description
3.2 CBOR Map Structure Example
4. IANA Considerations
4.1 Registry Contents
Claim Name: identity-data
Claim Description: Registering the claim for storing identity data of a person, which could be personally identifiable data (PII) mostly used in Foundational/National ID for cross-border interoperability.
Claim Key: 169
Claim Value Type(s): map
Change Controller: MOSIP
Specification Document(s): ,
5. References
[1] C. Bormann, and P. Hoffman. "Concise Binary Object Representation (CBOR)". , October 2013.
[2] Mike Jones, Hannes Tschofenig, Ludwig Seitz "CBOR Web Token (CWT)". , March 2018.
6. Author(s)
Mahammed Taheer ()
Resham Chugani ()
Rounak Nayak ()
Sasikumar G ()
Sreenadh S ()
License
Empowering users through transparent licensing.
Introduction
MOSIP is built on a strong foundation of open-source principles: transparency, modularity, reusability, and global collaboration. To maintain consistency and compliance across all repositories, MOSIP adopts licensing practices that allow safe integration of external dependencies while staying true to its core licensing model.
MOSIP’s primary licenses across its repositories are the Mozilla Public License 2.0 (MPL 2.0) and the MIT License. These licenses support modularity, file‑level copyleft (in the case of MPL), and broad reuse (in the case of MIT). Their flexibility allows MOSIP to integrate permissive and certain weak‑copyleft components while maintaining a clear and consistent compliance framework.
Licensing in MOSIP Repositories
MOSIP follows a structured licensing approach across repositories.
MPL 2.0
The MPL 2.0 is the primary license used across all core MOSIP repositories. It is a file‑level weak copyleft license, meaning:
Only the files that contain MPL‑licensed code must remain under MPL.
Other files within the same repository or project may use different licenses, making MPL well‑suited for large, extensible systems like MOSIP.
Why MOSIP uses MPL 2.0:
Supports modular architecture by allowing individual components to evolve independently.
Guarantees openness of improvements since modifications to MPL‑licensed files must be published.
Compatible with many permissive licenses such as MIT, BSD, Apache 2.0.
Key obligations under MPL 2.0:
Modified MPL‑licensed files must be released under MPL 2.0.
The license text must be included with the distributed software.
Clear marking of any modified MPL‑licensed files.
MIT License (Permissive License)
The MIT License is a lightweight permissive license used in MOSIP for modules intended for broad reuse and easy integration such as sample applications, helper utilities, SDKs, and educational/reference implementations.
Why MOSIP uses MIT:
Minimal restrictions, enabling reuse across governments, partners, and vendors.
Extremely easy for external contributors to adopt.
Ideal for distributable components and community-driven tools.
Key Obligations:
Retain copyright and license notice.
Best suited for:
SDKs, sample apps, developer tools, UI components, reference implementations. Used in helper or reference implementations, sample apps, or where contributions from external developers are larger.
Creative Commons Attribution-ShareAlike 4.0 International License
The Creative Commons Attribution-ShareAlike 4.0 International License is used only for MOSIP non-code assets such as documentation, training content, diagrams, and sample datasets.
Why MOSIP uses CC-BY SA 4.0 tribution or legal barriers. - Perfect for documentation and educational materials.
Obligations:
Attribute our work, and Distribute your adapted work under the same license, without placing additional restrictions.
Best suited for:
Docs, training guides, communication assets, sample datasets.
Used for documentation, design assets, or datasets intended for unrestricted reuse.
Each repository includes:
LICENSE.txt
/third-party-licenses/ folder for dependency licenses
Dependency Integration Process in MOSIP
All MOSIP developers must follow the below steps when adding any third‑party dependency.
Step 1: Evaluate License Compatibility
Use the Compatibility Matrix detailed here: Open Source Licenses and their Compatibility. If incompatible, do not use the dependency.
Step 2: Include the Dependency’s License File
Add the third‑party license text into:
/licenses/ folder, or
Next to the main LICENSE file.
Step 3: Attribution Requirements
Update or create a NOTICE file if the license (e.g., Apache 2.0, ISC, Unicode) requires attribution.
**Sample NOTICE entry:
This project includes third‑party software:
Library Name — Licensed under Apache License 2.0
Step 4: Preserve Your Project’s License (MPL 2.0)
Even with third‑party components, MOSIP projects remain under MPL 2.0.
Add clarity in LICENSE file:
This project is licensed under MPL 2.0. It includes components licensed under other open-source licenses. See /licenses and NOTICE for details.
SBOM (Software Bill of Materials) and Compliance Review
MOSIP generates an SBOM for each release using tools such as CycloneDX.
What SBOM Ensures:
Identification of every dependency
Detection of incompatible licenses
Compliance verification before release Compliance Checks Include:
Contribution Compliance in MOSIP
MOSIP enforces several governance mechanisms across all GitHub repositories.
Developer Certificate of Origin (DCO)
Required for every contributor
Enforced automatically via GitHub checks
Every commit must be signed-off using: Signed-off-by:
Corporate Contributor License Agreement (CCLA)
Used when MOSIP moved ARC license from MPL → MIT
Email consent recorded for contributing organizations
External Contributions Log
Maintained at:
Google Sheet (external contributors)
MOSIP Docs → Contributions page
These logs track contributions from both individuals and rganizations.
Best Practices for MOSIP Developers
Prefer permissive licenses when choosing third‑party libraries.
Always review compatibility before integration.
Maintain up‑to‑date third‑party license folders.
Enables proprietary or differently‑licensed modules to coexist in the same repository, as long as MPL obligations are respected.
Aligns with digital public goods (DPG) principles by encouraging reuse while maintaining some safeguards.
Attribution and source code availability only for modified MPL files, not the entire project.
Conflicting licenses
Missing license files
Missing NOTICE requirements
Ensure SBOM is regenerated after adding dependencies.
Follow MOSIP’s repository structure and licensing templates.
4
tstr
Full Name
Full name of the person
5
tstr
First Name
First name of the person
6
tstr
Middle Name
Middle name of the person
7
tstr
Last Name
Last name of the person
8
tstr
Date of Birth
Date of birth in YYYYMMDD format
9
tstr
Gender
Gender with the following values: 1 - Male, 2 - Female, 3 - Others
10
tstr
Address
Address of the person - Separator character \n
11
tstr
Email ID
Email id of the person
12
tstr
Phone Number
Contact number of the person: Use international notation
13
tstr
Nationality
Nationality of the person:
Use the two-letter country code
14
int
Marital Status
Marital status - Can contain the following values: 1 - Unmarried, 2 - Married, 3 - Divorced
15
tstr
Guardian
Name/id of the entity playing the role of a guardian, such as a mother, father, spouse, sister, legal guardian etc.
16
tstr
Binary Image
Binary image of the person's photograph
17
int
Binary Image Format
Binary image format. Can contain the following values 1 - JPEG, 2 - JPEG2, 3 - AVIF, 4- WEBP
18
[int]
Best Quality Fingers
An unsigned 8-bit number encoding the hand position of the finger. It must be in the range 0-10, where 0 represents "Unknown", 1-5 represents right thumb to little finger, and 6-10 represents left thumb to little finger in sequence
Language used in other attributes: Use the three-letter language code
Privacy
Overview
The right to privacy is a fundamental right in many contexts. Privacy protection or preservation can be ensured in an application by adopting a privacy friendly design stance.
What is privacy and privacy protection?
Privacy takes many forms. From an identity system perspective, the confidentiality of identity information and anonymity when using the identity offers privacy.
MOSIP views the identity system as a custodian of the individual's data. This data has to be protected in order to protect the individual from privacy and security risks. Privacy protection measures include , transparency, user control, confidentiality, selective disclosure, user anonymity and intrusion protection.
Privacy design elements
MOSIP addresses privacy design at four levels.
1. Functional Privacy
Functional Privacy ensures the system is designed to process and expose only the data necessary for a specific function. It embodies data minimization and protects individuals from unnecessary data collection and exposure.
By embedding this principle, MOSIP achieves:
📉 Minimal data exposure across system components
🔒 Robust protection against unauthorized access and misuse
🛡️ Compliance with privacy principles like data minimization and purpose limitation
MOSIP achieves Functional Privacy through the following key mechanisms:
Selective Disclosure
What it is -Selective disclosure is the principle of limiting the data shared with different system components or relying parties to only what they strictly require.
Purpose -To prevent over-sharing of personal data across services and ensure privacy at every step of the identity lifecycle.
2. Security
Security is a foundational principle ensuring the protection of the system, user data, and transactions from unauthorized access, breaches, and malicious attacks.
By embedding strong security practices, MOSIP achieves:
🔒 Protection of sensitive identity data from external and internal threats
🧑💻 Resilience against cyberattacks and unauthorized system usage
🌐 Trust and confidence for governments, system integrators, and end-users
This robust security framework enables MOSIP to function as a reliable backbone for national ID systems deployed worldwide.
MOSIP implements its security framework through the following key sub-elements:
Data Security
What it is -Data security ensures that all data handled by MOSIP—whether in storage or while processing—is safeguarded against unauthorized access, tampering, or breaches.
Purpose -To prevent data leaks, ensure confidentiality and integrity, and protect user identities throughout their lifecycle.
3. User Centricity
User Centricity means putting individuals at the heart of the identity system. It ensures that users are empowered to control their data, understand how it’s used, and interact with the system in ways that are inclusive, usable, and respectful of their privacy.
By adopting user-centric principles, MOSIP achieves:
👤 Empowerment of individuals over their personal data
✅ Transparency and informed decision-making through consent
🌍 Inclusivity for diverse populations, including the marginalized
This approach ensures MOSIP supports privacy rights and accessibility for all users, making identity systems fair and equitable.
MOSIP integrates User Centricity through the following sub-elements:
User Control
What it is -User Control means enabling individuals to manage how their identity data is collected, used, and shared within the system.
Purpose -To empower users with autonomy over their data, preventing misuse or overreach by third parties.
4. Transparency
Transparency ensures that all stakeholders—governments, system integrators, and end users—have clear visibility into how the system works, how decisions are made, and how data is handled.
By embedding transparency into its architecture and processes, MOSIP achieves:
🏛️ Trust through openness and accountability
📜 Verifiability of system behavior and outputs
👥 Governance structures that ensure fair and ethical use of the platform
This fosters confidence in MOSIP as a public good and aligns it with international best practices for open and transparent digital systems.
MOSIP enables Transparency through the following sub-elements:
Openness
What it is -Openness means making MOSIP’s design, codebase, and operational principles publicly accessible to encourage trust, collaboration, and innovation.
Purpose -To promote community participation, allow peer review, and ensure the platform evolves securely and inclusively.
These design principles have resulted in features as well as development practices in MOSIP that enhance privacy protection. A typical example for a practice is how PII (Personally Identifiable Information) is dealt with when creating application or audit logs. An example of a feature is how our allow selective sharing of information.
🌐 Alignment with standards and specifications. (refer here to know more about the standards and specification)
How MOSIP implements it -MOSIP’s modular architecture ensures that different modules (e.g., Registration, ID Authentication) only access and process the subset of identity data they need for their specific tasks. For example:
The Registration Client only collects demographic and biometric data required for enrolment.
Authentication services only verify the attributes requested by the relying party without exposing the full identity.
Anonymization
What it is -Anonymization removes or masks personal identifiers to make it impossible to link data back to an individual.
Purpose -To ensure privacy in scenarios like analytics, system monitoring, and reporting where identification isn’t necessary.
How MOSIP implements it -Audit logs and analytics data in MOSIP are anonymized by stripping or pseudonymizing personally identifiable information (PII), ensuring privacy even in post-processing environments.
Need to Know
What it is -This principle limits access to personal data only to the individuals, modules, or systems that require it for their roles.
Purpose -To reduce the risk of unauthorized access and exposure of sensitive information.
How MOSIP implements it -MOSIP enforces Role-Based Access Control (RBAC) and fine-grained permissions across modules. For example:
Biometric data is accessible only to the modules responsible for deduplication and authentication.
Administrative users can only view logs relevant to their operational scope.
Encryption
What it is -Encryption secures sensitive data by converting it into an unreadable format accessible only with the right cryptographic keys.
Purpose -To safeguard sensitive identity data from unauthorized access, breaches, or interception during storage and transmission.
How MOSIP implements it
MOSIP uses encryption algorithms such as: RSA,Elliptic Curve Cryptography (EC),JSON Web Encryption (JWE)
Secure key management is enforced through Hardware Security Modules (HSMs) for cryptographic key storage and usage.
Tokenization
What it is -Tokenization substitutes sensitive data elements with randomly generated tokens to reduce direct exposure of real identifiers during system operations.
Purpose -To protect sensitive identifiers like UINs during processing and interaction between modules.
How MOSIP implements it -In MOSIP, sensitive identifiers (such as UIN) are tokenized during authentication or API interactions to ensure the original identifiers are not exposed to external systems.
🛠️ Compliance with global security standards and frameworks
How MOSIP implements it -MOSIP adopts a multi-layered security approach to protect sensitive data:
Encryption & Decryption – Encryption is achieved using algorithms such as RSA, EC, and JWE.
Hashing – Sensitive elements like biometric templates are hashed with secure algorithms.
HSM-backed Key Management – Cryptographic keys are securely managed using Hardware Security Modules.
Database Security – Role-based permissions and audit trails monitor access. refer this to know more about how MOSIP Identity Platform supports data security
Trusted Applications
What it is -Trusted applications refer to MOSIP’s mechanism to ensure that only verified and authorized software can interact with core modules and services.
Purpose -To prevent unverified, potentially malicious applications from accessing sensitive APIs or data within MOSIP.
How MOSIP implements it -MOSIP uses several mechanisms to ensure only authorized applications interact with the identity system:
API Key Management – Each external application accessing MOSIP APIs is registered and issued secure API keys.
Digital Certificates – Mutual TLS (mTLS) ensures both MOSIP and external applications verify each other’s identity.
Access Control
What it is -Access control manages who can view, modify, or use specific data and system functions within MOSIP.
Purpose -To ensure that only authorized personnel and system components can access sensitive data or perform privileged operations.
How MOSIP implements it -MOSIP enforces strict access policies through:
Role-Based Access Control (RBAC) – Defines roles (e.g., admin, registrar, operator) with precise permissions.
Principle of Least Privilege – Grants users/modules only the minimum access necessary for their tasks.
Audit Trails – Tracks and logs all access attempts and changes for monitoring and compliance.
📱 Usability to support users with varying levels of digital literacy
How MOSIP implements it
Users can update certain attributes through designated update mechanisms. For example, if a user wishes to update their address, they can log in to the resident portal and make the change directly. If they require assistance, they may visit a registration center, where an operator will update the address on their behalf. Once the update is successful, the new information will be reflected in the user’s records.
Authentication requests disclose what data is being accessed, giving users the choice to proceed or decline.
Consent
What it is -Consent is the process of obtaining explicit and informed agreement from individuals before accessing or using their personal data.
Purpose -To respect individual privacy rights and comply with global data protection regulations.
How MOSIP implements it -MOSIP integrates consent mechanisms at multiple stages:
During registration – Presents clear information about data usage and requires explicit consent before proceeding.
During authentication – Displays prompts specifying which identity attributes are being requested.
User decision – Individuals can approve or deny data-sharing requests before information is transmitted.
Usability
What it is -Usability ensures the system is designed to be simple, intuitive, and accessible to people of varying education levels and digital literacy.
Purpose -To make MOSIP approachable and effective for all users, including those unfamiliar with technology.
How MOSIP implements it
Multilingual support in registration and authentication modules.
Simple, clear UI/UX design in client applications.
Offline capabilities for areas with low connectivity.
Inclusion
What it is -Inclusion ensures that the identity system accommodates all segments of society, including marginalized groups, persons with disabilities, and those in remote areas.
Purpose -To prevent exclusion and ensure equitable access to identity for every individual.
How MOSIP implements it
Supports biometric exceptions for individuals unable to provide fingerprints.
Allows demographic-only registration when biometrics cannot be captured.
Provides accessibility features for people with disabilities.
You can refer to this to know more about how MOSIP Identity Platform supports inclusivity
How MOSIP implements it
Open-source architecture – Entire codebase is published under an open-source license on GitHub.
Open APIs and standards – API documentation and integration standards are freely available.
Community engagement – Feedback and contributions from global experts are encouraged.
Verifiability
What it is -Verifiability ensures that the system’s actions and outputs can be independently audited for correctness and compliance.
Purpose -To build stakeholder confidence that the system operates as intended without hidden processes or biases.
How MOSIP implements it
Audit trails – All critical system actions are logged for compliance and monitoring.
This document provides a comprehensive analysis of security implementations across multiple levels. Additionally, it clearly delineates the boundaries of responsibility between MOSIP and the countries implementing the system.
Within this document, we have categorized security practices into 'Internal Practices' and 'Operational Protection'.
Internal security practices are integrated into the MOSIP development lifecycle to build security within the system from the ground up. These include rigorous threat modeling, secure coding practices, comprehensive code reviews, and continuous vulnerability assessments to ensure that potential risks are identified and mitigated early. By embedding these security measures during development MOSIP fosters a proactive security culture that not only minimizes vulnerabilities but also supports a robust defense strategy throughout the system's lifecycle.
On the other hand, operational security practices include firewall rules, intrusion detection systems, continuous monitoring, and incident response strategies. These measures focus on maintaining the security and integrity of the system during its operational phase, addressing runtime threats and ensuring compliance with best practices. Operational practices are outside of MOSIP development stage and to be taken up by the implementing countries.
Internal Practices
Internal security practices encompass measures such as security requirement elicitation, design, adherence to the MOSIP Principles, Platform development, static and dynamic code analysis, dependency scanning, code signing, and vulnerability management. These practices ensure that potential threats are identified and mitigated early in the development lifecycle.
Platform Design
MOSIP's fundamental architecture and design incorporate high levels of privacy and security.
(Table to be updated soon)
Development and Release Practices
This section details the measures taken during the development, testing, and release phases to ensure maximum security. Multiple checks are enforced at each stage through the use of various tools, tests, and scans. Key practices include:
Static Application Security Testing (SAST)
Static Application Security Testing (SAST) is a cornerstone of our security strategy. Tools like SonarCloud are used to perform in-depth code analysis during the development phase, identifying vulnerabilities such as SQL injection, cross-site scripting (XSS), and insecure coding practices. SAST provides developers with real-time feedback, enabling them to address security flaws early, thereby reducing the cost and effort of remediation later in the software lifecycle. These tools integrate seamlessly into our CI/CD pipelines, ensuring that security is addressed continuously and early. Dependency scanning tools like Dependabot, CodeQL, and others further enhance this layer of protection by monitoring and updating vulnerable dependencies.
Sonar Cloud - Development Phase - SonarCloud is integrated with Github actions, offering developers actionable insights directly within the workflow. By highlighting security hotspots and technical debt, it enables teams to prioritize and address critical issues efficiently.
CodeQL (Java and Python) - Development Phase - CodeQL performs semantic code analysis, enabling the detection of complex vulnerabilities
Github Dependabot (Vulnerability assessment and Version upgrade suggestions) - Development Phase - Dependabot simplifies the process of updating dependencies by creating pull requests with the necessary upgrades reducing manual effort and ensuring the codebase remains secure against known vulnerabilities. Its integration into GitHub workflows ensures timely updates and fosters a proactive approach to dependency management.
Open source compliance scanning - Ensures that all open-source components in use comply with licensing requirements and security best practices. This scanning helps in identifying potential legal or security risks associated with third-party libraries. Automated tools are used to track, analyze, and flag issues related to incompatible or outdated licenses, ensuring smooth and compliant project operations.
Github scan - Provides robust scanning capabilities integrated directly into GitHub repositories. It includes features such as secret scanning, dependency graph analysis, and vulnerability alerts, helping developers proactively detect and fix security issues within their workflows.
Data Breach Detector - It is a prodcution grade tool/script which goes through the DB and utilizes Deduce library to find out anomalies in various places such as names, address or numbers in plaintext etc.
Dynamic Application Security Testing (DAST)
DAST focuses on identifying security vulnerabilities in a running application by simulating real-world attack scenarios. Unlike SAST, which examines static code, DAST tests live applications, analyzing responses to detect flaws such as authentication issues, session management vulnerabilities, and exposure of sensitive data. Tools like Burp Suite Professional and ZED Attack Proxy (ZAP) are leveraged to conduct automated and manual penetration tests. These tools allow testers to evaluate application behavior under various conditions, ensuring robust protection against runtime threats. By integrating DAST into the release process, vulnerabilities can be identified and mitigated before applications are deployed into production.
Burp Suite Professional : This tool is used for automated and manual penetration testing . It provides features such as intercepting proxy, web vulnerability scanner, and advanced debugging capabilities. Burp Suite enables testers to identify vulnerabilities like SQL injection, cross-site scripting (XSS), and insecure session management. It also supports extensions for customized scanning and integrates seamlessly into security workflows.
ZED Attack Proxy: This tool is used for finding vulnerabilities in web applications during the development and testing phases.
Release Practices
Release practices are essential for ensuring the security, authenticity, and traceability of software releases. Here is an overview of the components used in MOSIP releases.
Image Signing: ASC (ASCII-armored PGP) signing is typically used to ensure the authenticity and integrity of software artifacts, including Docker images, by attaching a digital signature. When signing software images, MOSIP uses the private key to sign the image, and users can verify the signature using the corresponding public key.
JAR (Java Archive) Signing is the practice of signing Java archive files to ensure that the contents of the JAR haven't been tampered with and to provide a way to verify the source of the file. This is currently not implemented in MOSIP.
Operational Practices
These recommendations provide a robust framework to ensure the security and integrity of production systems for MOSIP implementing countries, helping to mitigate risks and enhance overall cybersecurity posture.
SBI Compliant Devices: Ensure that all devices used in the production environment are compliant with the latest Secure Biometric Interface (SBI) standards to ensure a highest level of security.
Trusted Platform Module: A Trusted Platform Module (TPM) is a specialized chip on a local machines that stores cryptographic keys specific to the host system for hardware authentication. The private key is maintained inside the chip and can't be extracted out. By leveraging this security feature every individual machine would be uniquely registered and identified by the MOSIP server component with it's TPM public key.
Compliance Tool Kit: MOSIP Provides Compliance Tool Kit (CTK) to help the device vendors to check if their products comply with SBI specifications.
Access and Audit Logs: Enables detailed access and audit logging for all critical systems and services in the production environment.
Patch Management (Host/Machines): Implement a robust patch management policy to ensure that all production systems are up-to-date with the latest security patches.
Safe Data Centers: Ensure that data centers housing production systems are designed and operated with a focus on security, availability and operational safety.
International standards: Stay compliant on international standards such as ISO/IEC 27001, NIST Cybersecurity Framework, and relevant national regulations. Better to validate the compliance using third party assessments.
Ensuring Data Protection: Enforce robust data protection measures to safeguard sensitive information at rest and in transit.
Consent-Based Data Handling: Ensure that data is only collected, processed, and stored with the explicit consent of the individuals it pertains to, in accordance with privacy laws and regulations.
Regular Security Audits: Perform regular security audits to assess the effectiveness of security measures and identify potential vulnerabilities in production systems.
Principle of Least Privilege: Ensure that users and systems are granted only the minimum level of access necessary to perform their tasks, reducing the risk of accidental or malicious misuse.
Rate Limiting: Implement rate limiting to protect services from abuse, such as brute force attacks or denial-of-service (DoS) attempts.
Sandbox Environments – Applications are tested and validated in a sandbox before production deployment.
Multi-Factor Authentication (MFA) – Adds an additional layer of protection for administrative access.
Auditing – Consent actions are securely recorded for transparency and accountability.
Assisted user journeys for vulnerable individuals.
Incorporation of GenderMag principles to evaluate and improve usability across diverse cognitive styles and gender-inclusive perspectives
Designed for multilingual, multi-cultural, and resource-constrained environments.
Technology Stack - Releases 1.2.0.0 and Subsequent
Technologies and Tools Used
This page lists all the technologies used in building MOSIP. Free and open-source software with clear long-term support availability has been chosen. For a deployment, certain choices can be replaced with other free or commercial options.
This document specifies an enhanced version of the generic data structure and encoding mechanism for storing the Identity Data of a registered person using any ID platform, along with the corresponding transport encoding mechanism in a machine-readable optical format (QR).
This enhanced version is the outcome of the revival of the Claim 169 Working Group in September 2025, which undertook a collaborative effort to refine and extend the specification. As part of the detailed discussions and brainstorming sessions within the working group, additional attributes (19–23) were introduced to strengthen applicability, usability, and interoperability across diverse identity ecosystems; bring in multi-language support (for Full Name), along with certain updates on guidelines, standard CWT attributes, standard COSE attributes (for public key discovery), credential status and security considerations. For details, refer to the section titled, "What Changed" below.
Further details on the evolution of these changes and detailed discussions can be found under the section titled "Iteration 2" here.
2. Rationale
Once a person is registered in an identity system, their data serves as the foundation for identification, granting them access to social benefits and government services. The level of assurance in this identification process varies depending on the authentication methods employed. Low assurance is achieved through basic identifiers like ID numbers, demographic data, passwords, or PINs. Conversely, higher assurance levels are attained through one-time passwords (OTP) and biometrics.
Among these methods, biometric-based authentication, such as facial authentication, offers the highest level of assurance as it assures the presence of the individual. While this is effective for online systems & personal phones where verification is conducted on a server or a personal device; offline authentication presents challenges in maintaining a similarly high level of assurance. The offline authentication mechanism should work for people with no phone.
For instance, in a cross-border scenario remote areas often face significant internet connectivity issues. Even when internet access is available, server reliability may be inconsistent. In such circumstances, scanning a QR code containing the person's facial photograph and identity information, alongside assurance that the data is signed by an authorized issuing authority or other trusted source (e.g. Country/state/others), provides an additional layer of security and affirmation for the countries and/or entities involved.
Please note: The trust layers required to sync the country's keys are beyond the scope of this document. We assume the app scanning the QR code already has the country's key to verify.
To tackle the challenge above, we propose a standard CBOR-based QR Code that involves embedding a low-resolution image of the person with a minimal demographic dataset within the QR code. This QR code would be digitally signed by the ID authorities (Issuer) and then printed on a physical card. Subsequently, the signed data within the QR code can be utilized for facial authentication. However, it's essential to recognize that QR codes have limitations regarding size. We suggest leveraging CBOR Web Token (CWT) with ED25519/ECC keys to generate a smaller signature and more condensed data.
Claim 169 represents a JSON Object that includes the below table as ID attributes. You can find an illustration of the ID structure contained within Claim 169, where:
3. Semantics
3.1 CBOR Map Structure Overview
Note:
All the fields here are optional.
The issuer of ID Claim169 is expected to host the JWKS file at the standard .well-known URL. This allows relying parties to verify the signature of the issued IDClaim169.
The reserved numeric ranges defined above are designated for global interoperability and should be used consistently across implementations.
Unassigned numbers may be utilized within closed ecosystems, provided both the issuer and the consumer mutually agree that such usage is not intended for global interoperability.
To propose new globally consumable attributes for inclusion within the interoperable assigned range, entities are encouraged to contact the Claim 169 Working Group using the contact details provided below.
Note on Standard CWT Attributes
The attributes listed below are already included as part of the standard CWT (CBOR Web Token) metadata in the payload and therefore do not need to be separately specified within Claim 169. Implementers should refer to the standard CWT definitions for format and usage.
These fields are inherently part of the CWT structure and must be interpreted according to the standard specification. For details, refer to the IANA CWT registry here.
Included Attributes:
Attribute
Attribute Type
Attribute Name
Description
1
tstr
Issuer (iss)
Identifier of the entity issuing the credential
2
tstr
Subject (sub)
Identifier of the subject of the credential
4
int
Expiration Time (exp)
Note on Standard COSE Attributes
The attributes listed below are already defined as part of the standard CWT structure, and may be present in either the protected or unprotected COSE headers. As such, they do not need to be separately specified within Claim 169.
Implementers MUST refer to the standard COSE specifications for the correct format, semantics, and usage of these fields. These attributes are inherently part of the COSE structure and must be interpreted in accordance with the relevant standards. For details, refer to the IANA COSE registry here. The issuer may choose whether to include any of these attributes for purposes such as public key discovery, taking into account practical constraints such as QR code size limitations.
Included Attributes:
Attribute
Attribute Type
Attribute Name
Description
32
COSE_X509
x4bag
An unordered list of X.509 certificates
33
COSE_X509
x5chain
An ordered chain of X.509 certificates
34
COSE_CertHash
x5t
Note on Status of Credential
The status of the credential, when represented using CWT, is outside the scope of the Claim 169 CBOR structure. This specification does not define or constrain how credential status should be encoded or managed within a CWT. Issuers may determine the status handling mechanism independently, using the IETF-recommended CWT conventions, or any other standards-compliant method appropriate for their ecosystem. No specific guidance or constraints on CWT handling are prescribed by this specification.
3.2 CBOR Map Structure Example
3.2.1 Steps for Claim 169 Compliant QR Code Generation
Prepare Identity Data: Start with the sample JSON identity data provided for conversion into Claim 169 format.
Convert to Claim 169 Format
Transform the JSON data into the required Claim 169 structure.
Refer to the sample converted data for guidance.
Generate CWT Data
Use the Claim 169–formatted data to create the CBOR Web Token (CWT) for QR code generation.
Compress the CWT
Apply zlib compression to the generated CWT data.
Encode to Base45 and Generate QR Code
Encode the compressed CWT using Base45.
Use this encoded string to generate the final QR code.
4. Security Considerations
The current MAP structure is in plain text and is equivalent to having a physical card with printed details. Additionally, the QR code is digitally signed, providing trust and preventing tampering or the insertion of fake information. Please ensure that you do not include any data elements that are not permissible under your country’s legal and regulatory requirements.
CWT MUST be signed, create a COSE_Sign/COSE_Sign1 object using the Message as the COSE_Sign/COSE_Sign1 Payload; all steps specified in RFC8152 for creating a COSE_Sign/COSE_Sign1 object MUST be followed.
If the CWT is a COSE_Encrypt/COSE_Encrypt0 object,create a COSE_Encrypt/COSE_Encrypt0 using the Message as the plaintext for the COSE_Encrypt/COSE_Encrypt0 object; all steps specified in RFC8152 for creating a COSE_Encrypt/COSE_Encrypt0 object MUST be followed.
It is recommended that sensitive information, such as biometrics, be encrypted.
If you choose to encrypt the payload, please ensure that key sharing for decryption is handled separately, outside the scope of this specification. There are multiple key-sharing mechanisms that can be followed, and the choice remains to be outside of this specification. As an example, you could potentially follow the approach of the TOTP mobile authenticators.
A cached key may be used to enable offline encrypted QR code reading, where applicable.
To verify the claims the CWT is a COSE_Sign/COSE_Sign1. Follow the steps specified in Section 4 of ("Signing Objects") for validating a COSE_Sign/COSE_Sign1 object. Let the Message be the COSE_Sign/COSE_Sign1 payload. Once signature is valid we SHOULD validate the public key against a preconfigured key, in case encrypted. Else, if the CWT is a COSE_Encrypt/COSE_Encrypt0 object, follow the steps specified in Section 5 of [] ("Encryption Objects") for validating a COSE_Encrypt/COSE_Encrypt0 object. Let the Message be the resulting plaintext.
The security of the CWT relies upon on the protections offered by COSE. Unless the claims in a CWT are protected, an adversary can modify, add, or remove claims.
Since the claims conveyed in a CWT are used to make identity claim decisions, it is not only important to protect the CWT but also to ensure that the recipient can authenticate the party that assembled the claims and created the CWT. Without trust of the recipient in the party that created the CWT, no sensible identity verification can be made. Furthermore, the creator of the CWT needs to carefully evaluate each claim value prior to including it in the CWT, so that the recipient can be assured of the validity of the information provided.
Syntactically, the signing and encryption operations for Nested CWTs may be applied in any order; however, if encryption is necessary, producers normally should sign the message and then encrypt the result (thus encrypting the signature). This prevents attacks in which the signature is stripped, leaving just an encrypted message, as well as providing privacy for the signer. Furthermore, signatures over encrypted text are not considered valid in many jurisdictions.
5. IANA Considerations:
5.1 Registry Content
Claim Name: identity-data
Claim Description: Registering the claim for storing identity data of a person, which could be Personally Identifiable Data (PII) mostly used in Foundational/National ID for cross-border interoperability.
Claim Key: 169
Claim Value Type(s): map
Change Controller: MOSIP
Specification Document(s): Section 3, Section 4
6. Acknowledgments
This work is the result of the dedicated efforts of contributors who recognize the critical importance of interoperability and a consistent QR code specification. The revised version has been shaped significantly by the input of our working group committee, comprising members from the following organizations: GetGroup, PWC, Tech 5, UNHCR, Ooru, GIZ, OpenSPP.
We extend our gratitude to the committee members for their invaluable time and insights throughout the evaluation phase.
This document specifies an updated version of the generic data structure and encoding mechanism for storing the Identity Data of a registered person using any ID platform. It also provides a transport encoding mechanism in a machine-readable optical format (QR).
2. Rationale
Once a person is registered in an identity system, their data serves as the foundation for identification, granting them access to social benefits and government services. The level of assurance in this identification process varies depending on the authentication methods employed. Low assurance is achieved through basic identifiers like ID numbers, demographic data, passwords, or PINs. Conversely, higher assurance levels are attained through one-time passwords (OTP) and biometrics.
Among these methods, biometric-based authentication, such as facial authentication, offers the highest level of assurance as it assures the presence of the individual. While this is effective for online systems & personal phones where verification is conducted on a server or a personal device; offline authentication presents challenges in maintaining a similarly high level of assurance. The offline authentication mechanism should work for people with no phone.
For instance, in a cross-border scenario remote areas often face significant internet connectivity issues. Even when internet access is available, server reliability may be inconsistent. In such circumstances, scanning a QR code containing the person's facial photograph and identity information, alongside assurance that the data is country-signed, provides an additional layer of security and affirmation for the countries involved.
Please note: The trust layers required to sync the country's key are beyond the scope of this document. We assume the app scanning the QR code already has the country's key to verify.
To tackle the challenge above, we propose a standard CBOR-based QR Code that involves embedding a low-resolution image of the person with a minimal demographic dataset within the QR code. This QR code would be digitally signed by the ID authorities (Issuer) and then printed on a physical card. Subsequently, the signed data within the QR code can be utilized for facial authentication. However, it's essential to recognize that QR codes have limitations regarding size. We suggest leveraging CBOR Web Token (CWT) with ED25519/ECC keys to generate a smaller signature and more condensed data.
Claim 169 represents a JSON Object that includes the below table as ID attributes. You can find an illustration of the ID structure contained within Claim 169, where:
3. Semantics
3.1 CBOR Map Structure Overview
Note:
All the fields here are optional.
The issuer of IDClaim169 is expected to host the JWKS file at the standard .well-known URL. This allows relying parties to verify the signature of the issued IDClaim169.
Please ensure to review the and important note(s) below with respect to and .
Attribute
Type
Attribute Name
Description
Biometrics
Attribute
Type
Attribute Name
Description
Data formats
Data format
Description
Data sub formats
Image
Subformat
Description
Template
Subformat
Description
Sound
Subformat
Description
Guidelines
The reserved numeric ranges defined above are designated for global interoperability and should be used consistently across implementations.
Unassigned numbers may be utilized within closed ecosystems, provided both the issuer and the consumer mutually agree that such usage is not intended for global interoperability
Note on Standard CWT Attributes
The attributes listed below are already included as part of the standard CWT (CBOR Web Token) metadata in the payload and therefore do not need to be separately specified within Claim 169. Implementers should refer to the standard CWT definitions for format and usage.
These fields are inherently part of the CWT structure and must be interpreted according to the standard specification. For details, refer to the .
Included Attributes:
Attribute
Attribute Type
Attribute Name
Description
Note on Status of Credential
The status of the credential, when represented using CWT, is outside the scope of the Claim 169 CBOR structure. This specification does not define or constrain how credential status should be encoded or managed within a CWT. Issuers may determine the status handling mechanism independently, using the IETF-recommended CWT conventions, or any other standards-compliant method appropriate for their ecosystem. No specific guidance or constraints on CWT handling are prescribed by this specification.
3.2 CBOR Map Structure Example
3.2.1 Steps for Claim 169 Compliant QR Code Generation
Prepare Identity Data: Start with the sample JSON identity data provided for conversion into Claim 169 format.
Convert to Claim 169 Format
Transform the JSON data into the required Claim 169 structure.
Refer to the sample converted data for guidance.
Generate CWT Data
Use the Claim 169–formatted data to create the CBOR Web Token (CWT) for QR code generation.
Compress the CWT
Apply zlib compression to the generated CWT data.
Encode to Base45 and Generate QR Code
4. Security Considerations
The current MAP structure is in plain text and is equivalent to having a physical card with printed details. Additionally, the QR code is digitally signed, providing trust and preventing tampering or the insertion of fake information. Please ensure that you do not include any data elements that are not permissible under your country’s legal and regulatory requirements.
CWT MUST be signed, create a COSE_Sign/COSE_Sign1 object using the Message as the COSE_Sign/COSE_Sign1 Payload; all steps specified in for creating a COSE_Sign/COSE_Sign1 object MUST be followed.
If the CWT is a COSE_Encrypt/COSE_Encrypt0 object,create a COSE_Encrypt/COSE_Encrypt0 using the Message as the plaintext for the COSE_Encrypt/COSE_Encrypt0 object; all steps specified in for creating a COSE_Encrypt/COSE_Encrypt0 object MUST be followed.
The security of the CWT relies upon on the protections offered by COSE. Unless the claims in a CWT are protected, an adversary can modify, add, or remove claims.
Since the claims conveyed in a CWT is used to make identity claim decisions, it is not only important to protect the CWT but also to ensure that the recipient can authenticate the party that assembled the claims and created the CWT. Without trust of the recipient in the party that created the CWT, no sensible identity verification can be made. Furthermore, the creator of the CWT needs to carefully evaluate each claim value prior to including it in the CWT so that the recipient can be assured of the validity of the information provided.
Syntactically, the signing and encryption operations for Nested CWTs may be applied in any order; however, if encryption is necessary, producers normally should sign the message and then encrypt the result (thus encrypting the signature). This prevents attacks in which the signature is stripped, leaving just an encrypted message, as well as providing privacy for the signer. Furthermore, signatures over encrypted text are not considered valid in many jurisdictions.
5. IANA Considerations:
5.1 Registry Content
Claim Name: identity-data
Claim Description: Registering the claim for storing identity data of a person, which could be Personally Identifiable Data (PII) mostly used in Foundational/National ID for cross-border interoperability.
Claim Key: 169
Claim Value Type(s): map
Change Controller: MOSIP
Specification Document(s): ,
6. Acknowledgments
This work is the result of the dedicated efforts of contributors who recognize the critical importance of interoperability and a consistent QR code specification. The revised version has been shaped significantly by the input of our working group committee, comprising members from the following organizations: GetGroup, PWC and Tech 5.
We extend our gratitude to the committee members for their invaluable time and insights throughout the evaluation phase.
Language used in other attributes: Use the three-letter ISO 639-3 language code
4
tstr
Full Name
Full name of the person
5
tstr
First Name
First name of the person
6
tstr
Middle Name
Middle name of the person
7
tstr
Last Name
Last name of the person
8
tstr
Date of Birth
Date of birth in YYYYMMDD format
9
int
Gender
Gender with the following values 1 - Male, 2 - Female, 3 - Others
10
tstr
Address
Address of the person, separator character \n
11
tstr
Email ID
Email id of the person
12
tstr
Phone Number
Contact number of the person: Use E.123 international notation
13
tstr
Nationality
Nationality of the person:
Use the two-letter ISO 3166-2 country code or three-letter ISO 3166-1 alpha-3 country code
14
int
Marital Status
Marital status - Can contain the following values 1 - Unmarried, 2 - Married, 3 - Divorced
15
tstr
Guardian
Name/id of the entity playing the role of a guardian, such as a mother, father, spouse, sister, legal guardian etc.
16
tstr
Binary Image
Binary image of the person's photograph
17
int
Binary Image Format
Binary image format. Can contain the following values 1 - JPEG, 2 - JPEG2, 3 - AVIF, 4 - WEBP
18
[int]
Best Quality Fingers
An unsigned 8-bit number encoding the hand position of the finger. It must be in the range 0-10, where 0 represents "Unknown", 1-5 represents right thumb to little finger, and 6-10 represents left thumb to little finger in sequence
19
tstr
Full Name - Secondary Language
Secondary Language Identity Full Name
20
tstr
Secondary Language
Secondary Language Code. Language used in other attributes: Use the three-letter ISO 639-3 language code
21
tstr
Location Code
Geo Location/Code
22
tstr
Legal Status
Legal Status of the identity
23
tstr
Country of Issuance
Country of Issuance
24.. 49
Unassigned
For future - For Demographic Data attributes
50
[Biometrics]
Right Thumb
Person's Right Thumb biometrics
51
[Biometrics]
Right Pointer Finger
Person's Right Pointer Finger biometrics
52
[Biometrics]
Right Middle Finger
Person's Right Middle Finger biometrics
53
[Biometrics]
Right Ring Finger
Person's Right Ring Finger biometrics
54
[Biometrics]
Right Little Finger
Person's Right Little Finger biometrics
55
[Biometrics]
Left Thumb
Person's Left Thumb biometrics
56
[Biometrics]
Left Pointer Finger
Person's Left Pointer Finger biometrics
57
[Biometrics]
Left Middle Finger
Person's Left Middle Finger biometrics
58
[Biometrics]
Left Ring Finger
Person's Left Ring Finger biometrics
59
[Biometrics]
Left Little Finger
Person's Left Little Finger biometrics
60
[Biometrics]
Right Iris
Person's Right Iris biometrics
61
[Biometrics]
Left Iris
Person's Left Iris biometrics
62
[Biometrics]
Face
Person's Face biometrics
63
[Biometrics]
Right Palm Print
Person's Right Palm Print biometrics
64
[Biometrics]
Left Palm Print
Person's Left Palm Print biometrics
65
[Biometrics]
Voice
Person's Voice biometrics
66.. 74
Unassigned
For future - For Biometrics Data attributes
75.. 99
Unassigned
For future - For any other data
Optional biometrics data sub format
3
tstr
Data issuer
Optional biometric data issuer
6
WSQ
100..200
Vendor specific
Timestamp indicating when the credential expires
5
int
Not Before (nbf)
Timestamp before which the credential must not be accepted
6
int
Issued At (iat)
Timestamp indicating when the credential was issued
Gender with the following values 1 - Male, 2 - Female, 3 - Others
10
tstr
Address
Address of the person, separator character \n
11
tstr
Email ID
Email id of the person
12
tstr
Phone Number
Contact number of the person: Use international notation
13
tstr
Nationality
Nationality of the person:
Use the two-letter country code or three-letter country code
14
int
Marital Status
Marital status - Can contain the following values 1 - Unmarried, 2 - Married, 3 - Divorced
15
tstr
Guardian
Name/id of the entity playing the role of a guardian, such as a mother, father, spouse, sister, legal guardian etc.
16
tstr
Binary Image
Binary image of the person's photograph
17
int
Binary Image Format
Binary image format. Can contain the following values 1 - JPEG, 2 - JPEG2, 3 - AVIF, 4 - WEBP
18
[int]
Best Quality Fingers
An unsigned 8-bit number encoding the hand position of the finger. It must be in the range 0-10, where 0 represents "Unknown", 1-5 represents right thumb to little finger, and 6-10 represents left thumb to little finger in sequence
19.. 49
Unassigned
For future - For Demographic Data attributes
50
[Biometrics]
Right Thumb
Person's Right Thumb biometrics
51
[Biometrics]
Right Pointer Finger
Person's Right Pointer Finger biometrics
52
[Biometrics]
Right Middle Finger
Person's Right Middle Finger biometrics
53
[Biometrics]
Right Ring Finger
Person's Right Ring Finger biometrics
54
[Biometrics]
Right Little Finger
Person's Right Little Finger biometrics
55
[Biometrics]
Left Thumb
Person's Left Thumb biometrics
56
[Biometrics]
Left Pointer Finger
Person's Left Pointer Finger biometrics
57
[Biometrics]
Left Middle Finger
Person's Left Middle Finger biometrics
58
[Biometrics]
Left Ring Finger
Person's Left Ring Finger biometrics
59
[Biometrics]
Left Little Finger
Person's Left Little Finger biometrics
60
[Biometrics]
Right Iris
Person's Right Iris biometrics
61
[Biometrics]
Left Iris
Person's Left Iris biometrics
62
[Biometrics]
Face
Person's Face biometrics
63
[Biometrics]
Right Palm Print
Person's Right Palm Print biometrics
64
[Biometrics]
Left Palm Print
Person's Left Palm Print biometrics
65
[Biometrics]
Voice
Person's Voice biometrics
66.. 74
Unassigned
For future - For Biometrics Data attributes
75.. 99
Unassigned
For future - For any other data
3
tstr
Data issuer
Optional biometric data issuer
6
WSQ
100..200
Vendor specific
.
To propose new globally consumable attributes for inclusion within the interoperable assigned range, entities are encouraged to contact the Claim 169 Working Group using the contact details provided below.
5
int
Not Before (nbf)
Timestamp before which the credential must not be accepted
6
int
Issued At (iat)
Timestamp indicating when the credential was issued
Encode the compressed CWT using Base45.
Use this encoded string to generate the final QR code.
It is recommended that sensitive information, such as biometrics, be encrypted.
If you choose to encrypt the payload, please ensure that key sharing for decryption is handled separately, outside the scope of this specification. There are multiple key-sharing mechanisms that can be followed, and the choice remains to be outside of this specification. As an example, you could potentially follow the approach of the TOTP mobile authenticators.
A cached key may be used to enable offline encrypted QR code reading, where applicable.
To verify the claims the CWT is a COSE_Sign/COSE_Sign1. Follow the steps specified in Section 4 of RFC8152 ("Signing Objects") for validating a COSE_Sign/COSE_Sign1 object. Let the Message be the COSE_Sign/COSE_Sign1 payload. Once signature is valid we SHOULD validate the public key against a preconfigured key. In case encrypted Else, if the CWT is a COSE_Encrypt/COSE_Encrypt0 object, follow the steps specified in Section 5 of [RFC8152] ("Encryption Objects") for validating a COSE_Encrypt/COSE_Encrypt0 object. Let the Message be the resulting plaintext.
Technology Stack - Releases 1.2.1.0 and Subsequent
This page lists the current baseline technology stack used to build MOSIP. We prioritise free and open-source components with a clear long-term support (LTS) path. In deployments, many components can be swapped for equivalent open-source or commercial alternatives, based on your architecture and operational needs.
Domain
Tools/Technologies
Version
Licence Type
Commercial
Production
Cost
Operating System
Ubuntu Server
24.04
Creative Commons License v 3.0
No
No
NA
Infrastructure
Cloud - Azure/AWS
NA - Cloud tool
Commercial
Yes
Depends on Deployment Arch.
Depends on Deployment Arch.
Development - Language Runtime
Java SE 21
OpenJDK 21
GPL-2.0 + CPE
No
Yes
NA
Development - Expression language
mvel2
2.5.2.Final
Apache License
Version 2.0, January 2004
Development - Scheduling
quartz
2.3.2
Apache License
Version 2.0, January 2004
Development - Internalization
nv-i18n
1.29
Apache License 2.0
Development - UI Application framework
JavaFx
OpenJFX 11.0.2
GPL v2 + Classpath
No
Yes
NA
Development - Application Framework
Vert.x
3.9.13
Apache License 2.0
No
Yes
NA
Development - Application Framework
Spring
6.1.x
Apache License 2.0
No
Yes
NA
Development - Utilities
Apache commons(60+ to be considered)
Latest version
Apache License 2.0
No
Yes
NA
Development - Data Grid
Apache Ignite
2.3.0
Apache License 2.0
No
Yes
NA
Development - Object Mapper
Orika
1.5.2
Apache License 2.0
No
Yes
NA
Development - validator
Hibernate validator
8.0.1.Final
Apache Software License 2.0
No
Yes
NA
Development - Encryption
BouncyCastle
1.78
Adaptation of MIT X11 License
No
Yes
NA
Development - JSON marshal/unmarshal
Jackson
2.15.4
Apache License 2.0
No
Yes
NA
Development - Unit Testing
Junit
5.x and above
Common Public License - v 1.0
No
No
NA
Development - Log
logback
1.4.14
GNU Lesser GPL Version 2.1
No
Yes
NA
Development - Templating
velocity
1.7
Apache License 2.0
No
Yes
NA
Development - IDE
Eclipse
Latest version
Eclipse Public License Version 2.0
No
No
NA
Development - Unit Testing
Karma
4.1.0
MIT License
No
No
NA
Development - Unit Testing
Jasmine
3.4.0
MIT License
No
No
NA
Development - API Documentation
Swagger
2.0.7
Apache License 2.0
No
No
NA
Development - Application Server
Tomcat server
10.x
Apache License 2.0
No
Yes
NA
Development - Orchestration
Apache Camel
2.23.0
Apache License 2.0
No
Yes
NA
Development - Database
H2 DB
2.2.224
MPL and EPL
No
Yes
NA
Development - Database
PostgreSQL
Server: 15
Postgresql License
Yes
No
NA
Development - Database
Derby DB
10.13.1.1
Apache License 2.0
Development - Database Modeling tool
PG Data Modeler
0.9.3
Commercial
No
Yes
Nominal
DevOps tools
Jira
6.4 and above
Not Open source
Testing tools
Java profiler
13.0.7
Open Source License
No
NA
DevOps tools
SonarLint
v3.5
GNU GPL
DevOps tools
GitHub
NA - Cloud tool
Commercial - Github
DevOps tools
SonarQube
6.7.3 LTS
GNU GPL
DevOps tools
Maven
3.9.x
Apache License 2.0
DevOps tools
Docker
18.03.x CE
Apache 2.0
DevOps tools
Ansible
2.2
GNU GPL v3.0
DevOps tools
Github actions
NA - Cloud tool
DevOps tools
Travis
NA - Cloud tool
MIT License
DevOps tools
Glowroot
NA - Cloud tool
Apache License 2.0
DevOps tools
Prometheus
2.45.0
Apache License 2.0
DevOps tools
Grafana
1.24.6
Apache License 2.0
DevOps tools
Python
3.x
PSF License
Messaging
ActiveMQ
2.39.0 and 1.1.5
Apache License 2.0
Messaging
Apache Kafka
3.2.1-debian-11-r9
Apache License 2.0
Caching
Hazelcast
NA
Apache License 2.0
Object Store
MinIO
2025.2.28-debian-12-r1
GNU AGPL v3
Web Server/HTTP proxy server
Nginx
1.24.0 (Ubuntu)
2-clause BSD license
IAM
KeyCloak
7.1.18
Apache License 2.0
DevOps tools
RKE2
v1.28.9+rke2r1
Apache License 2.0
DevOps tools
Helmsman
v3.17.1
Apache License 2.0
DevOps tools
istioctl
v1.22
Apache License 2.0
DevOps tools
Terraform
v1.8.5
BUSL 1.1
DevOps tools
ELK Elasticsearch
v7.17.2
Elastic License 2.0 (ELv2) and SSPL 1.0 (dual-licensed)
