Welcome to the "Try It Out" section! Here, we offer you hands-on experience to better understand how our product works and how you can leverage its features. This section will guide you through some simple steps to get started.
If you're a developer or a partner interested in experiencing or integrating with Inji Web, we invite you to explore our designated sandbox environments.
Collab: Development Integration Environment
Collab serves as our development integration environment, featuring QA-tested dockers. It's a dedicated space where our partners and contributors can build on the platform or integrate with the latest QA-tested version of the code.
This environment undergoes regular nightly builds from our engineering team, making it a hub for continuous development activities.
How to use:
Access resources on Collab, our sandbox environment, through the provided link.
Collab Guides
Explore the guides of the various Inji Modules from below:
Inji Mobile
Inji Web
Inji Verify
Synergy: Stable Integration Environment
Synergy represents our stable environment, where the most recently released version of the MOSIP platform and applications are deployed for partners to seamlessly integrate and conduct testing.
For quick access to environment related resources, please visit the provided link.
Feedback and Support
If you require any assistance or encounter any issues during the testing and integration process, kindly reach out to us through the support mechanism provided below.
Provide a detailed description about the support you require or provide detailed information about the issue you have encountered, including steps to reproduce, error messages, logs and any other relevant details.
\
Use case
Use Cases of Verifiable Credentials and Their Impact
Use Case 1: Healthcare Industry
Current Challenge: Patients often need to share medical records and test results securely across different healthcare providers. This process is cumbersome, requiring manual handling of paper documents or insecure sharing via email and other communication channels.
Solution with Verifiable Credentials: Healthcare providers can issue VCs for vaccination records, allergies, or medication history. VCs can securely store and share medical records, test results, and vaccination history digitally. Patients can then easily share these credentials with other providers, ensuring continuity of care and faster treatment. Patients can control access to their data, ensuring only authorized healthcare providers can verify and access their information.
Benefits:
Reduced Friction: Patients can easily share verified medical credentials with healthcare professionals, streamlining the consultation and treatment process
Enhanced Privacy and Security: Verifiable credentials use cryptography to ensure data integrity and protect sensitive medical information
Use Case 2: Education Sector
Current Challenge: Students often require verified academic transcripts and certificates when applying for further education or job opportunities, which they often carry physical transcripts or certifications. Requesting and verifying these documents can be time-consuming and prone to fraud.
Solution with Verifiable Credentials: Educational institutions can issue VCs such as digital diplomas, certificates, and transcripts. Students can share these credentials with potential employers or other educational institutions quickly and securely, streamlining verification and reducing wait times.
Benefits:
Efficient Verification: Employers and educational institutions can instantly verify the authenticity of academic credentials without relying on manual checks or third-party verification services
Prevention of Fraud: Verifiable credentials use cryptographic signatures to ensure the integrity and authenticity of educational documents, reducing the risk of forgery
Use Case 3: Financial Services
Current Challenge: Customers often need to prove their identity and financial history when applying for loans, opening bank accounts, or accessing other financial services. This process typically involves submitting multiple paper documents and undergoing lengthy identity verification procedures.
Solution with Verifiable Credentials: Financial institutions can issue VCs that include identity information, credit scores, and financial history. Customers can use these credentials to securely and selectively share their information with authorized institutions.
Benefits:
Streamlined Onboarding Process: VCs enable faster and more efficient customer onboarding, reducing paperwork and administrative overhead for financial institutions
Enhanced Data Privacy: Customers have greater control over their personal and financial data, minimizing the risk of identity theft and unauthorized access
Use Case 4: Travel and Immigration
Current Challenge: Travelers often face challenges proving their identity and vaccination status when crossing borders. Paper-based documents are prone to loss or damage, leading to delays and disruptions during travel. Travelers juggle multiple documents for border crossings (passports, visas, health certificates) leading to delays and frustration.
Solution with Verifiable Credentials: Governments and health authorities can issue verifiable credentials for vaccination records, identity verification, and travel permissions. Travelers can present these digital credentials at checkpoints or border crossings securely and efficiently. These credentials can be easily accessed via mobile wallets and verified electronically, speeding up border processing and reducing queues.
Benefits:
Facilitated Cross-Border Travel: Verifiable credentials enable seamless verification of identity and vaccination status, reducing wait times and administrative hurdles at immigration checkpoints
Improved Public Health Measures: Authorities can track and verify vaccination records more effectively using digital credentials, supporting efforts to manage public health crises such as pandemics
Use Case 5: Employment
Challenge: Job seekers often face delays due to lengthy background checks and verification of employment history and skills
Solution: Employers can issue verifiable credentials for past employment and skills acquired. Job seekers can then share these credentials with potential employers, allowing for faster verification and a smoother hiring process
Use Case 6: Government Services
Challenge: Citizens often need to present physical documents (birth certificates, proof of residence) to access government services, leading to inefficiency and potential loss of documents
Solution: Government agencies can issue verifiable credentials for citizen information. These credentials can be securely accessed and shared for various services, reducing administrative burdens and streamlining access
Benefits of Verifiable Credentials in all above mentioned scenarios:
Reduced Friction: Verifiable credentials eliminate the need for physical documents, simplifying processes and speeding up transactions
Enhanced Security: Cryptographic verification ensures the authenticity and integrity of credentials, reducing the risk of fraud
User Control: Individuals control their data, choosing what information to share and with whom
Improved Efficiency: Streamlined workflows and faster access to services for both users and institutions
Conclusion
Verifiable credentials offer versatile solutions across various domains by leveraging digital technologies to enhance data security, privacy, and efficiency. By addressing common challenges associated with identity verification and data sharing, verifiable credentials empower individuals and organizations to streamline processes and improve trust in digital interactions.
Roadmap
Our community strives to deliver major releases as per the designated schedules, while offering minor releases every other month! The roadmap outlines the vision, goals, and planned development milestones of our ongoing projects over a specific period of time. It also provides a high-level overview of the Inji stack's future direction, features, enhancements, and major updates.
Inji's principles, as discussed here, underpin the design and development of the roadmap. The year-wise roadmap details how these principles will be applied and advanced in a step-by-step manner, ensuring that the Inji stack evolves in alignment with the core principles.
Head below to navigate through our year-wise roadmap that provides a strategic overview of the journey ahead and highlights the key milestones & objectives for each year!
Inji Wallet is a product of the combined efforts of multiple stakeholders. Contributions from the community form the backbone and drive its growth and stability. The contributions have come in multiple ways, ranging from direct code contributions, review of design and architecture, bug fixing, and support for technology evaluation.
All Inji code is owned and maintained by International Institute of Information Technology, Bangalore, on behalf of Inji.
All trademarks are the property of their respective holders. Other products and company names mentioned herein may be trademarks and/or service marks of their respective owners.
Setup
The Setup section of Inji Documentation will enable you (DevOps, Administrators and Developers) to plan and estimate a minimum requisite infrastructure to deploy the the Inji stack seamlessly.
Reach out to us through the channel that best fits your purpose, as outlined below.
Community Forum
Join the conversation at community.mosip.io to ask questions, share ideas, and explore discussions about MOSIP and its solutions.
Feedback
We truly value your input. Every suggestion counts in shaping our products and processes.
Click here to share your feedback and help us make Inji better. \
Other Queries
For anything more specific or direct, feel free to write to us at info@mosip.io — we’re happy to connect!
Test
This section is for hands-on exploration and user-facing flows in Inji Certify. Use it when you want to validate an end-to-end issuance journey.
You’ll find quick reference diagrams and functional overview.
Workflow: End-to-end sequence of how issuance works in Certify.
The 'Setup' section offers a detailed overview of the process and steps involved in building and deploying Inji Certify.
Develop
The 'Develop' section helps you dive deeper on how Inji-Certify is built and how to extend it. Subsections cover the tech stack, architecture and key management.
Architecture
Inji Certify is a platform designed to manage and facilitate the issuance of Verifiable Credentials (VCs). It features a modular architecture that supports both direct issuance and proxying of VCs from external sources. It interacts with external digital wallets via APIs.
This layered component diagram represents the architecture of the Inji Certify system.
The diagram is organized into four distinct layers, each representing a different aspect of the system's functionality:
API Layer:
This layer serves as the entry point for external interactions with the system.
It exposes various APIs that allow clients to interact with the underlying services.
VC Signer and Template Engine:
This layer is responsible for the creation and signing of Verifiable Credentials (VCs).
The Template Engine component within this layer handles the generation of credential templates.
The VC Signer component ensures that the credentials are properly signed and verifiable.
Keymanager Service:
This layer manages cryptographic keys used for signing and verifying credentials.
It ensures the secure storage and retrieval of keys, and handles key rotation and management tasks.
Plugin interaction:
This foundational layer consists of three plugins that provide essential services to the upper layers:
Data Provider Plugins: These plugins fetch relevant data from external sources or registries. They retrieve the necessary information and return it to Inji Certify as a JSON object. Inji Certify then utilizes this data to generate and issue the corresponding VCs..
Audit Plugin: Tracks and logs actions within the system for auditing purposes.
VC Issuance Plugin: Exposes API for VCI Issuance which internally connects with credential service and sends the Verifiable Credential (VC) issued by the service as a response.
Each layer builds upon the services provided by the layer below it, creating a modular and scalable architecture for the Inji Certify system.
Tested Operating Systems
Inji Certify is currently compatible and certified with the following browsers:
Sl No
OS
Version
1.
Windows - Google Chrome
Version 124.0.6367.92
2.
Mac- Safari
Version 16.6 (18615.3.12.11.2)
3.
Ubuntu
Version 22.04
Note: We have conducted specific testing on Ubuntu, Mac, and Windows using Google Chrome for the latest release of Inji Certify. It supports and is compatible with other operating systems and browsers, but we have specified the following list to indicate the platforms our team has thoroughly tested.
We are thrilled to announce the inaugural release of Inji Certify, featuring a seamless installation guide for deploying Inji Certify. This release highlights the key integration with microservices such as eSignet VCI and Sunbird RC, in Version 0.8.0.
Summary
Below are the details for the Inji Certify 0.8.0 release:
Inji Certify introduces seamless integration with microservices eSignet VCI and Sunbird C. These robust services are dedicated to credentialing, facilitating seamless authentication, issuance, and verification of verifiable credentials within the platform. Click on the following links to learn more:
Why and what was the segregation of eSignet VCI Component to Inji Certify?
Segregation of eSignet VCI Component to Inji Certify
Inji Certify, a platform for issuing and managing verifiable credentials (VCs), has enhanced its system by segregating the eSignet VCI component. This strategic move optimizes functionality and scalability.
Important Update: Now eSignet VCI is known as Inji Certify Core!
What was eSignet VCI?
eSignet VCI was a microservice for secure authentication, issuance, and verification of VCs, based on OAuth 2.0 and OpenID Connect protocols. It ensures reliable user authentication and promotes interoperability across systems.
Reasons for Segregation
1. Enhanced Specialization and Focus
Separating eSignet VCI allows Inji Certify to focus on credential issuance while eSignet VCI concentrates on secure authentication and verification, improving efficiency.
2. Improved Scalability
Each component can now scale independently based on demand, ensuring the platform handles varying loads effectively.
4. Streamlined Maintenance and Updates
Independent updates and maintenance reduce downtime and allow for quicker deployment of enhancements and security patches.
5. Facilitating Multi-Tenancy
The segregation will support multiple issuers on a single Inji Certify instance, ensuring data integrity and security for each issuer in the upcoming implementation of Inji Certify.
How the Segregation Works
Modular Structure: Now eSignet VCI is maintained as a separate module within the Inji Certify which offers an Inji Certify core under the Certify repository, ensuring a clear separation of concerns while maintaining a unified codebase.
Enhanced Configuration: Organizations can now configure Inji Certify core which offers the VC issuances independently to meet specific requirements, allowing for customized solutions.
The segregation of eSignet VCI enhances Inji Certify’s performance and scalability, providing a robust solution for issuing and managing verifiable credentials. This strategic move ensures a more secure and efficient credentialing ecosystem for organizations and users.
Inji Mobile
Inji Mobile is the mobile wallet app in the Inji stack. Use it to download, store, and share verifiable credentials (VCs).
Welcome to the Inji Wallet Sandbox: Here, you can try out all the features of our app in a risk-free environment. Experiment with different settings, test your use cases, and get hands-on experience with Inji Wallet’s functionalities.
Refer Inji Wallet Collab Guide to know more about how you can explore 'Inji Wallet' in our 'sandbox collab environment'.
Local Setup
Mimoto can be deployed in local using Docker Compose setup. This service streamlines deployment and management, offering a seamless and efficient way to handle backend operations.
Below sections details the docker-compose setup to run mimoto which act as BFF for Inji Wallet and backend for Inji web. This docker compose setup is intended only for local use and not for production deployment.
What is in the docker-compose folder?
The certs folder holds the p12 file which is created as part of OIDC client onboarding.
"config" folder holds the mimoto system properties file, issuer configuration and credential template.
"loader_path" this has mimoto mount volume from where all the runtime dependencies are loaded to classpath.
"docker-compose.yml" file contains the mimoto setup.
How to run this setup?
Create loader_path folder under the docker-compose directory and download the kernel auth adapter(kernel-auth-adapter-1.2.0.1.jar) from here.
Copy the downloaded jar under loader_path directory and rename it to kernel-auth-adapter.jar
Add ID providers as issuers in mimoto-issuers-config.json
Start esignet services and update esignet host references in mimoto-default.properties and mimoto-issuers-config.json
Create certs folder in the same directory and create OIDC client. Add key in oidckeystore.p12 and copy this file under certs folder. Refer here to create client
Update client_id and client_alias in mimoto-issuers-config.json file.
Update p12 file password mosip.oidc.p12.password in mimoto-default.properties file.
To start the docker-compose file, run the command docker-compose up
Replace http://localhost:8099 by ngrok public domain at following places
token_endpoint in mimoto-issuers-config.json
mosipbox.public.url, mosip.api.public.url in mimoto-default.properties
Develop
This section offers an overview of the architecture and technologies utilized within Inji Wallet, ensuring compatibility, security, and efficiency in the management of Verifiable Credentials.
Permissions & Requirements
Permissions
Android
Following permissions are required to be included in the AndroidManifest.xml to access Bluetooth Low Energy on Android.
Permissions required for Central (Wallet) when target is Android 12 or higher
Permissions required for Central (Wallet) when target is Android 11 or lower
Permissions required for Peripheral (Verifier) when target is Android 12 or higher
Permissions required for Peripheral (Verifier) when target is Android 11 or lower
iOS
Following permissions are required to be included in info.plist to access the Core Bluetooth APIs on iOS.
Minimum Version Requirements
BLE version: BLE 4.2 and above.
Android version: Android version 9 (API level 28) and above.
iOS version: The SDK requires iOS minimum deployment target version as 13.0.
Capabilities
Wallet: In this role, Tuvali can discover Verifier devices over BLE and can connect and share data. This role is supported on both, Android and iOS devices meeting minimum version requirement.
Verifier: In this role, Tuvali can advertise itself to Wallets and receive data. This role is supported only on Android devices at the moment. iOS doesn't support being a Verifier.
Telemetry
This telemetry module is derived from the sunbird telemetry module. It is responsible for generating events that can provide valuable analytics.
Note: The publication of this project is currently a work in progress and has not been released yet. Stay tuned for further announcements.
Specifications
Backend Services
This section contains the guides and information that could benefit the developers, system integrators, relying parties and the end users.
For more information on backend systems, read through:
<key>NSBluetoothAlwaysUsageDescription</key>
<string>Bluetooth is used to allow sharing VCs with another device</string>
<key>NSBluetoothPeripheralUsageDescription</key>
<string>Bluetooth is used to allow sharing VCs with another device</string>
Inji
Overview
Inji is a verifiable credentialing stack that provides a way to share tamper-proof, instantly verifiable data which is cryptographically signed by a trusted issuer, and users can store them securely on their devices or browsers and share them when needed.
Issuer: The entity that issues the credential and makes claims about the subject (e.g., a university issuing a degree, a government issuing a passport, an employer issuing a work permit). The issuer cryptographically signs the VC. Inji's 'Issuance-module' is called Inji Certify.
Holder: The individual or entity which possesses the credential (e.g., the student with the degree, the citizen with the passport, the employee with the work permit). The holder stores and manages their VCs. Inji's 'Holder-module' is called Inji Wallet.
Verifier: The entity that requests and verifies the credential to confirm a claim (e.g., an employer checking a degree, a border agent checking a passport, a landlord checking a work permit). The verifier checks the cryptographic proofs to ensure the VC's authenticity and integrity. Inji Verify.
Some everyday examples of Verifiable Credentials include:
A national ID issued as a digital credential
A diploma issued by a university
A background verification report from an employer
A subsidy or benefit eligibility certificate from a government agency
VCs allow:
Instant verification, even offline
User control over when and how data is shared
Interoperability across platforms and borders
Reduced fraud and manual checks
Inji's Triangle Of Trust
For a quick overview of Inji, which primarily includes Inji Wallet, Inji Verify and the Inji Certify as key components, you can watch the video titled "Inji Stack End To End Use Case Demonstration". This video provides a visual walkthrough of the key features and showcases how all modules interact through a persona-based demonstration, highlighting its real-world application. Head to the section titled “What Does Inji Include” for a comprehensive overview of how Inji functions, explaining how each component operates independently, while maintaining the interoperability necessary for seamless and secure credential verification.
Inji’s Key Capabilities
Secure Issuance: Issue verifiable credentials with digital signatures, ensuring authenticity. Cross-Platform Accessibility: Available via mobile app or web interface, ensuring inclusivity for all users. Privacy-Preserving Sharing: Users control what they share, with whom, and for how long. Offline Compatibility: Works in low-connectivity or offline environments, critical for inclusion. Fast, Trusted Verification: Credentials can be verified quickly and securely, even by non-technical service providers.
Inji Stack Components
Inji Certify– Credential Issuance
Enables trusted entities to issue digitally signed credentials. Supports:
Multiple formats: JSON-LD, SD-JWT,mDOC and many more. A tool that enables issuers to seamlessly connect with existing data sources to issue verifiable credentials.
Connecting with existing databases and offering configurable credential schemas, it caters to diverse use cases across different sectors and industries.
Revocation management
Ledger and credential status checks
Schema and credential registry management
Inji Wallet – Credential Holding and Sharing
Empowers users to manage their credentials on different devices:
Inji Mobile: Android and iOS app to download, store, and present credentials securely
Inji Web: Browser-based wallet for users without smartphones, offering print and share features
Inji Verify – Credential Verification
Allows service providers and organizations to:
Scan and validate credentials
Check credential status (validity, expiry, revocation)
Integrate with the existing relying party or service providers
Real-World Applications
Domain
Example Applications
Healthcare
Immunization records, medical certifications
Education
Degrees, training certificates, learning records
Social Welfare
Benefit eligibility, ration cards
Finance
KYC credentials, account onboarding
Mobility
Driving licenses, transportation passes
Employment
Job credentials, background checks
Others
Many more
Interoperability and Standards
Inji follows widely adopted open standards, ensuring flexibility and long-term sustainability:
W3C Verifiable Credentials Data Model
OpenID for Verifiable Presentation (OpenID4VP)
OpenID for Verifiable Credential Issuance (OpenID4VCI)
Claim 169
ISO/IEC 18013-5: mDoc/mDL
IETF SD-JWT-based Verifiable Credentials
W3C based SD-JWT-based Verifiable Credentials
DID (Decentralised Identifiers) support
Inji: How the Pieces Work Together
This section will contain a clear diagram illustrating the interaction between Inji Certify, Inji Wallet (mobile + web), Inji Verify. The diagram should also show the components involved to build Inji.
How it works?
Issuance: An issuer creates a digital credential with claims about a subject and cryptographically signs it.
Holding: The signed credential is then given to the holder, who stores it securely in a digital wallet or similar application.
Presentation: When needed, the holder can present the VC (or a verifiable presentation, which can include multiple VCs or selectively disclosed information) to a verifier.
Verification: The verifier uses the cryptographic proofs within the VC to confirm that it was issued by a trusted party and has not been tampered with. This verification often involves checking against a "Verifiable Data Registry" where public keys of issuers are stored.
Component Diagram
Summary
Inji provides a secure, inclusive, and interoperable solution for issuing and managing digital credentials. By enabling individuals to hold their credentials and share them when needed, Inji supports faster access to services while protecting privacy and reducing fraud. Whether you are:
A user needing better control over their identity and credentials,
An issuer needing to deliver secure digital certificates, or
A verifier needing reliable proof of information, Inji offers the tools you need to make digital credentialing simple, trusted, and universal.
Using Mock Data
Introduction
Welcome to the Inji ecosystem, which encompasses the Inji Mobile Wallet, Inji Web Wallet, Inji Verify, and Inji Certify. These tools provide a powerful platform for managing and verifying digital credentials with ease. This document guides you through using mock data to explore the functionalities of each component, allowing you to understand and leverage their capabilities effectively. Read on to discover how you can interact with Inji's ecosystem, using demo credentials and mock data as explained below.
Whether you're a Developer, System Integrator, or an Enthusiast eager to dive into the world of verifiable credentials, use this guide for necessary information to get started with Inji in our Collab environment. Let's begin this journey of seamless setup and exploration.
This guide explains the use of mock data for following:
Inji Mobile Wallet
Inji Web Wallet
Inji Verify
What would you need?
You will need UIN (Unique identification number) as a demo credential whic will allow you to explore Inji's capabilities and experience seamless VC sharing. You can also try this with 'Sample Insurance Credentials'.
Issuance of UIN (Unique identification number) as a demo credential will allow you to explore Inji's capabilities and experience seamless VC sharing firsthand.
Now you can self generate your own UIN Credential using the .
Click on the Get UIN button located at the top-right corner of the page. This will open the , Alternatively, you can simply click on this to self register. You need to duly fill the self registration form.
Note: You can use 111111 as the OTP, for any OTP based feature in Collab environment.
For sample Insurance Credentials, please provide the below details in the eSignet authentication page:
Policy Name: insuranceCredentials
DOB: 2000-01-01
Policy Number: 12345
The mock data you will need for Inji Web Wallet is same as that of Inji Mobile Wallet (Explained above).
Follow the procedure to try out Inji Verify in our collab environment:
To obtain sample verifiable credentials embedded in a QR code, please initiate the process by following the steps to generate the QR code, click !
To use the QR code with verifiable credentials and test out the Inji Verify application, exploring the scan and upload features, please use the QR codes provided below:
Project Governance
Open source projects can have a variety of contributors. This can potentially lead to confusion or conflict. This document sets forth a simple transparent set of guidelines to describe the roles and process to be followed. As part of that it covers:
Process of open source contributions and review of code in this project.
Decision-making process on backlogs and including contributions.
The MOSIP project follows a simple structure with 3 levels.
Level 1 - MOSIP Technology Committee. This committee is responsible for high level roadmap and policy decisions such as licensing, and technology stack.
Code Contribution
The recommended Github workflow here is for developers to submit code and documentation contributions to Inji open-source repositories.
Fork the repository.
Clone the fork to your local machine. E.g.:
Pre-Authorized Issuance
Overview
The Pre-Authorized Code Flow with Credential Offer enhances the credential issuance experience by enabling wallets to obtain Verifiable Credentials (VCs) directly using a pre-authorized code embedded in a credential offer. This flow is part of the OpenID for Verifiable Credential Issuance (OpenID4VCI) standard, designed to streamline issuance where the issuer has already authenticated the user or established user context outside of the standard interactive authentication flow.
In this flow, the Credential Issuer prepares and issues a Credential Offer that contains:
Credential metadata
Issuer endpoints
A pre-authorized code that the wallet can exchange for an access token
The wallet then uses this pre-authorized code to securely request the VC from the issuer without requiring the user to authenticate again through a separate interactive login step.
Why This Feature Matters
The Pre-Authorized Code Flow brings several advantages:
Seamless User Experience: Eliminates the need for end-user interactive authentication (e.g., signing in) during VC issuance when prior authentication is already completed by the issuer.
Flexible Delivery: Credential Offers can be delivered via QR codes, deep links, or other channels, enabling both same-device and cross-device issuance experiences.
Optional Transaction Code: Issuers can require an additional user transaction code (PIN), adding an extra factor of security during issuance.
Interoperability: Aligns with OpenID4VCI standards, improving compatibility with other identity systems and wallets.
How It Works – Step-by-Step (Certify Perspective)
The following sequence describes how Inji Certify handles credential issuance using the Pre-Authorized Code Flow.
1. Certify Prepares the Credential Offer
Inji Certify collects the required user claims and generates a Credential Offer containing:
A pre-authorized code
Credential metadata
Issuer endpoints
The credential offer is exposed as a URI which can be sent to the user as notification or other modes.
2. Certify Exposes Issuer Metadata
When the wallet processes the credential offer, it requests issuer metadata from Certify’s .well-known endpoint. Certify responds with discovery information, including:
Supported credential configurations
Token endpoint details
Credential endpoint details
Required parameters for token exchange
This enables the wallet to understand how to interact with Certify for issuance.
3. Certify Receives Token Request
Certify receives a back-channel token request from the wallet at the Token Endpoint. The request includes:
The pre-authorized code
An optional transaction code (PIN), if configured
Certify validates the pre-authorized code and, where applicable, verifies the transaction code before proceeding.
4. Certify Issues Access Token
Upon successful validation, Certify issues an access token to the wallet. This token authorizes the wallet to request the verifiable credential.
5. Certify Issues the Verifiable Credential
Certify receives a credential request from the wallet at the Credential Endpoint, secured using the access token. Certify validates the token, constructs the Verifiable Credential based on the requested configuration, and returns the issued VC to the wallet.
The wallet then securely stores the credential for the holder’s use.
Security Considerations
Replay Attacks: Because the pre-authorized code can be replayed if disclosed publicly, issuers may enforce mitigations such as PIN requirements or time-limited codes.
Metadata Validation: Wallets must validate issuer metadata before proceeding with token exchanges to prevent malicious credential offers.
Limitations
Client authorisation is not supported. Therefore, only a single issuance mode can be configured for an issuer. For example, if an issuer is configured to issue Verifiable Credentials using the pre-authorised flow, other modes—such as wallet-initiated issuance—will not be supported.
Supported Issuance Modes
Pre-Authorized Code Flow without PIN – direct token exchange using pre-authorized code
Pre-Authorized Code Flow with PIN – token exchange requires both a pre-authorized code and a user transaction code
Please refer to this link to know more about the technical design and configuration.
Presentation During Issuance
The Presentation During Issuance (PDI) feature enhances the credential issuance experience by allowing Inji Certify to request and verify an existing Verifiable Credential (VC) from the holder’s wallet as a mandatory step before issuing a new VC. This feature is aligned with the OpenID for Verifiable Credential Issuance (OpenID4VCI) and OpenID for Verifiable Presentations (OpenID4VP) standards.
In this flow, the issuer enforces a verification step during issuance, where the wallet is required to present a specific credential to validate the holder’s eligibility before issuing a VC.
This approach ensures that issuance is conditional, secure, and user‑consented, while avoiding reliance on external or offline verification mechanisms.
Presentation During Issuance brings several advantages:
Stronger Trust at Issuance:
Workflow
Workflow
Overview
Inji Certify is a platform designed to manage and facilitate the issuance of Verifiable Credentials (VCs). It features a modular architecture that supports both direct issuance and proxying of VCs from external sources. It interacts with external digital wallets via APIs.
The workflow for credential issuance in the described scenario can be summarized as follows:
Digital Wallet (External)
Description: Digital wallets are external applications used by users to store and manage their VCs. Inji Certify does not include a built-in wallet. Instead, it provides APIs for seamless integration with various wallet providers.
API Layer
Description: This layer serves as the entry point for all interactions with Inji Certify, including requests from external Digital Wallets. It handles routing, authorization (using OAuth2 OpenID Connect), and request validation.
Core Layer (Internal Components within the Blue Box)
This section comprises the core components responsible for VC processing:
VC Signer:
Description: Digitally signs Verifiable Credentials to guarantee authenticity and integrity.
Template Engine:
Description: Manages templates for different VC types, populating them with data before signing.
Keymanager Service:
Description: Securely stores and manages the cryptographic keys used for signing VCs.
Data Sources Layer (Bottom Left)**
Description: This layer encompasses the databases and data stores holding the information required to generate VCs in "issuer mode".
Plugins (Middle Bottom)
Inji Certify operates in two primary modes via its plugin system:
Issuer Mode (using Data Provider Plugin):
Data Provider Plugin: Retrieves data from various sources (databases, APIs, etc.) to populate VC templates. In this mode, Inji Certify generates and issues VCs directly.
Proxy Mode (using VC Issuance Plugin):
VC Issuance Plugin: Handles the specifics of proxying VCs issued by external sources. In this mode, Inji Certify does not generate the VC itself, but acts as a conduit for VCs issued elsewhere.
Audit Plugin: Logs all significant events related to VC Issuance and other events.
Description: Represents external entities that issue VCs. Inji Certify can operate in "proxy mode" to distribute VCs from these external issuers.
Infrastructure Components (Bottom)
Postgres DB: The main database.
Cache: The caching system.
HSM (Hardware Security Module): For secure key management.
Functional Overview
Verifiable Credentials (VCs) are digital representations of physical credentials such as passports and licenses. These credentials are cryptographically signed, ensuring tamper resistance and immediate verifiability. VCs empower users by allowing them to store credentials in digital wallets and seamlessly access various services.
Database Integration: Inji Certify enables issuers to connect with existing databases to issue VCs. It assumes the source database has a primary key for each data record and information required to authenticate a user (e.g., phone, email, or other personal information).
Credential Schema Configuration: Issuers can configure their credential schemas for various types of certificates they wish to issue, ensuring alignment with W3C VC v1.1 standards.
Local Setup
Inji Certify is a robust platform that enables issuers to connect with an existing Credential Registry to issue verifiable credentials. Issuers can configure credential schemas for various types of certificates they wish to issue. Certificates are generated in JSON-LD format as per the W3C Verifiable Credentials (VC) v1.1 standard.
This guide is designed to help developers set up Inji Certify in their local environment, providing detailed instructions to replicate the platform's functionality for development or testing purposes.
To begin, visit the Inji Certify repository on GitHub:
Repository Link:
The repository contains all the necessary files and instructions to set up Inji Certify on your local machine.
Key Manager
The Key Manager in Inji Certify is a critical component which is used as an embedded library responsible for secure cryptographic key lifecycle management.
It handles:
Generation of asymmetric and symmetric keys.
Storage and encryption of private keys.
Technology Stack
This section intends to provide an overview of the technologies and frameworks utilized to build Inji Certify.
UI & Rest end points
The table below outlines the frameworks, tools, and technologies employed by Inji Certify
Inji Certify v0.13.1 release includes an automation bug fix required to support the new features introduced in version 0.13.0.
Corrected the certificate path in the automation scripts to ensure the appropriate certificates are used for generating biometric data during prerequisite creation for MOSIP ID use cases.
Here below is the bug which has been addressed as part of this release.
Version 0.12.1
Release Version: 0.12.1
Release Type: Developer Release
Release Date: 11th September, 2025
Inji Certify v0.12.1, brings enhancements in automation of testing to support latest eSignet release v1.6.2
Support for eSignet v1.6.2 – Test automation has been updated to accommodate the blocker change requiring jti in the authentication request. With this fix, the automation now fully supports .
Version 0.10.2
Release Version: v0.10.2 (Patch)
Release Type: Developer Release
ReleaseDate: 21st Feb, 2025
This patch release 0.10.2 for Inji Certify addresses fixes related to release versions, ensuring that the correct images of Inji Web and Mimoto are selected during local deployment using Docker Compose.
Below is the list of bug fixes as part of the 0.10.2 release:
Test Report
The scope of testing is to verify fitment to the specification from the perspective of
Functionality
Deployability
Configurability
Version 0.8.1
Release Name: Inji Certify 0.8.1 (Patch)
Support: Developer Release
Release Date: 17th May, 2024
Overview
Version 0.8.1 introduces significant enhancements to streamline the management and issuance of verifiable credentials using the Sunbird platform. Key updates include:
Sunbird Installation and Configuration:
Postman collections are provided for creating issuers and credential schemas.
DID Generation:
To generate Decentralized Identifiers (DIDs) using the web method and an empty services list. The configuration within the Sunbird installation ensures that the generated DIDs are resolvable. When creating an issuer (which involves a DID generation call), this configuration will be used to generate the DIDs.
Added steps to make the generated DID discoverable for local testing
Credential Schema and Issuance Registry:
Users can create credential schemas and issuance registries.
Important identifiers ($.schema[0].author and $.schema[0].id) were noted for schema requests.
Endpoint and Environment Variable Configuration:
Hostname configuration for endpoints based on Docker setup.
aud variable and audUrl in the postman collection updated to the local OAuth token endpoint.
Knowledge-Based Identification (KBI):
KBI process implemented as per Postman collection.
Base64 encoded KBI details for authorization.
Credential Generation:
We adjusted the pre-request script for /vci/credential API.
Keypair and algorithm updated for generating smaller Verifiable Credentials.
Revocation in Inji Mobile Wallet is the mechanism that allows the wallet to determine and display whether a stored verifiable credential (VC) is revoked or not. Inji uses the mechanism to evaluate revocation for supported credential formats. The revocation check runs automatically when credentials are downloaded, and can be triggered manually by the user. To get more details on the technical implementation and design of this feature, click to explore.
Protects Verifiers & Holders: Prevents use of credentials that an issuer has invalidated (e.g., lost, compromised, or superseded).
Maintains Trust: Ensures relying parties receive only valid credentials and avoids false acceptances.
Presentation During Issuance (PDI)
Presentation During Issuance (PDI) in Inji Mobile Wallet is a mechanism that allows an issuer to request and verify an existing Verifiable Credential (VC) from a user before issuing a new credential.
Instead of relying on OTPs, reference numbers, or manual checks, PDI enables issuers to request a Verifiable Presentation (VP) from the wallet as part of the issuance flow. The issuer validates the presented credential to confirm identity, eligibility, or authorization before issuing the new credential.
Inji Wallet implements this feature using OpenID4VCI for issuance and OpenID4VP for presentation, with protocol complexity abstracted through dedicated client libraries.
Issuers verify cryptographically signed credentials rather than relying solely on user-entered verification methods, reducing the risk of impersonation and fraud.
Credentials are issued only after validating trusted, issuer-backed proofs, ensuring relying parties receive authentic and eligible credentials.
Architecture
Inji Wallet is a mobile application designed to enhance user convenience by allowing them to securely download and manage their Verifiable Credentials (VC) offline. The diagram below illustrates the extensive features of Inji Mobile Wallet, highlighting the essential modules involved in issuing Verifiable Credentials.
Furthermore, this overview outlines various user flows, detailing the seamless processes users can follow. These processes include downloading VC by utilizing eSignet for authentication, securely activating VC, logging in to eSignet, and effortlessly sharing VCs.
The Inji Mobile Wallet adopts a layered architecture pattern, ensuring clear separation of concerns and robust security for verifiable credentials. Built with React Native, it delivers a seamless, cross-platform experience on both iOS and Android.
Presentation Layer (Green)
Technical Stack
Wallet Application
The following table summarizes the main technologies, tools, and frameworks used to build the Inji Wallet application:
Tool / Technology
Version
Description
License
0.74.5
The following table lists the technologies, tools, and frameworks used for building native libraries:
Tool / Technology
Version
Description
License
Integration Guides
This section provides guidelines and specifications for integrating any software development kit (SDK) with Inji Wallet. It also contains references to available SDKs and tools that developers, system integrators, relying parties, and end users may find useful.
SDK Integration Specifications
To ensure seamless integration with Inji Wallet, SDKs must follow these requirements:
Availability
The SDK should be published as an npm module for integration with React Native applications.
For Android, integration must be supported via a Maven dependency.
For iOS, integration must be supported via Swift Package Manager (SPM). For example, the npm modules tuvali and secure-keystore demonstrate suitable implementations.
API Design
Provide a simple API surface for easy integration.
Must include an initialization API (e.g., init or a constructor API).
Include all necessary functional APIs to perform core actions.
Provide a disconnect API to safely detach the SDK when needed.
Preferably design APIs to be asynchronous, allowing users to continue app usage without UI blocking.
Traceability & Logging
APIs may optionally accept a parameter such as traceabilityId to enhance logging and request traceability.
Build Your Own Wallet with Inji Libraries
Use Inji’s modular SDKs and libraries to assemble a wallet tailored to your needs. Each library provides specific capabilities that can be integrated into your application.
Build your own wallet using Inji libraries – click here!
OpenID4VP Library – Enable credential sharing through OpenID4VP protocols.
– Verify VCs received over Bluetooth.
(BLE Sharing) – Share credentials offline via Bluetooth Low Energy.
– Manage secure storage of keys and sensitive data.
– Add biometric face matching for enhanced verification.
– (Details coming soon!) for monitoring and analytics.
VCI-Client
vci-client library enables to carry out the credential request from the consumer application (mobile wallet or web) and download the VC.
Request credentials from OID4VCI-compliant credential issuers
Supports both the Verifiable Credential download flows defined in the OID4VCI specification:
Secure Keystore
Secure Keystore is a cross-platform cryptographic key management library for Android and iOS, supporting secure key generation, encryption/decryption, HMAC, and digital signatures using native platform security features (Android Keystore and iOS Keychain/Secure Enclave).
Platforms Supported
Android 6.0+ (Hardware-backed keystore)
iOS 13.0+ (Secure Enclave + Keychain)
Artifacts
Maven Snapshots are available
Using Swift Package Manager:
Open Xcode
Go to File > Swift Packages > Add Package Dependency
Use the URL: https://github.com/mosip/secure-keystore-ios-swift.git
Add the following in your settings.gradle.kts:
In build.gradle.kts:
Face Match
Face Match is an optional component in Inji Wallet. This is built as a standard that allows anyone to integrate their Facematch SDK. Its expected that the wallet providers would integrate the SDK that matches the specification.
We extend our sincere appreciation to the IRIScan team for their invaluable support to MOSIP by providing an opensource face match SDK for our internal reference integration. We are truly impressed by your commitment and outstanding contribution. We welcome and invite our other esteemed partners to collaborate with MOSIP, for a similar integration.
Repository
NPM Package
Installation
To install any face sdk module, please add it's dependency in the package.json file.
Once done rebuild the Inji Wallet.
The Inji Wallet should be able to integrate and use the face sdk.
Face Compare with liveness is coming soon
This feature enables Inji Wallet to verify specific parameters for liveness. We utilize local face verification to guarantee the user's presence during a transaction. This measure is implemented to combat fraud, going beyond the ISO/IEC 30101 standard.
The following guidelines apply to individuals who are developing the face SDK:
It is prohibited to collect any personally identifiable information (PII) or phone details.
Inji Wallet includes built-in telemetry, and all telemetry data must be transmitted to the designated system. Telemetry enhances Inji Wallet's observability features by capturing specific events, creating measures, and monitoring various user actions and events.
Recording or transmitting IP addresses, user details, Phone IMEI, phone numbers, or user photos in telemetry or logs is strictly prohibited.
The use of phone numbers and device fingerprints should be limited to managing the SDK license.
Face SDK Specifications
This is a draft specification that is used to implement the face match in the Inji Wallet or any similar wallets.
This API is asynchronous and can be used for initializing the implementer's SDK. During initialization, the implementers can use this API to build logic to validate the license, download the latest model file if needed, or inform the server about its usage. This API is expected to return errors when there is a critical issue with the initialization process. If the API is called more than once, then the SDK can optionally return based on the current status. The implementation of this API should support offline mode. In offline mode, the implementor should ensure smooth usage. Care should be taken by the implementor to ensure the SDK is lightweight and does not slow down the app.
The implementation of this API should immediately return if initialization has already been completed.
Mimoto
Mimoto is a BFF(Backend for Frontend) for Inji Wallet. It's being used to get default configuration, download verifiable credentials (VC) and activate VC.
It provides all necessary APIs to the Inji Wallet and acts as a proxy for resident services. Mimoto gets the request from Inji Wallet, performs all the validations and forwards it to respective services. Additionally, it subscribes to the web-sub event to be able to download the VC once it's ready.
Detailed API documentation of Mimoto is available here.
Support for downloading VC from multiple Issuers
To get a list of issuers, this API is called. For retrieving the credential types and display properties, .well-known location is referred for every issuer from the mimoto-issuers-config.json
Download via eSignet
Inji Wallet allows the users to download VC by redirecting the user to eSignet UI. Multiple APIs are being called to complete the process in the backend.
Inji Wallet initiates authenticate API by redirecting users to eSignet UI. On eSignet UI, user is given option to enter the unique ID, the user is asked to enter an OTP on the next screen. In the backend, token API is called to get a token. Refer for more details.
After getting a token response, Inji Wallet initiates a download request. Refer
Credentials have to be activated in order to use them for online login. When a user selects Activate option, an OTP is sent to the user and credentials are activated.
To send an OTP to a user, the below API is called.
After successful OTP validation, a keypair is generated in the phone and the public key is synced with server. The mimoto receives a certificate and create thumbprint which it stores in the keystore securely. This is called as the activation process.
The configurable properties for mimoto can be found at . This property file is maintained as one for each deployment environment. On repository, each environment configuration is placed in a corresponding branch specific to that environment.
Refer to of Collab environment.
The implementers can choose to use the existing configurations or add new configurations to them.
The user is currently on the + button on the Home screen, which will open Add new card screen, where all the issuers are displayed Below issuers list API gives out all the issuers list
To get complete configuration of the specific issuer, below api is called.
eSignet
The eSignet service is utilized by Inji Wallet for online login. Users have the ability to log in to any service provider portal that is integrated with eSignet.
Online login
QR code scanning and login to the service provider portal
The user is required to open the portal integrated with eSignet and utilize the app scanner to scan the QR code.
After successfully scanning the QR code, Inji Wallet will access the API below and transmit the link code.
Link Transaction endpoint V2
After successfully completing the offline face authentication and selecting the required and optional information, the two specified APIs are invoked.
Linked Authentication Endpoint V2
Linked Consent Endpoint V2
Inji Certify
Overview
The Inji Certify service is utilized by Inji Wallet for downloading the VC.
Download VC
The user is currently on the Add new card screen and chooses an issuer(For example, Republic of Veridonia National ID Department).
Inji Wallet utilizes the react-native-app-auth library for authorization flow.
It first redirects the user to the authorization server configured respective to the Issuer (For example, e-Signet).
The user performs authentication (For example, on the eSignet UI, the input the necessary information such as a unique ID and OTP (One-time Password)).
Post successful authentication, the user is redirected back to the Inji Wallet app with an authorization code.
Inji Wallet then exchanges the authorization code for an access token.
Using the access token, Inji Wallet makes a request to the credential endpoint from Inji Certify to download the credential.
VC Issuance endpoint
For credential request, refer credential_endpoint attribute in issuer's configuration response.
Level 2 - Project leadership. This is the executive leadership at MOSIP that includes key project roles within MOSIP such as product owner, engineering lead, and architects. These members will be appointed as maintainers and lead in the project by MOSIP.
Level 3 - Members. This is a set of people who are working on the project.
Given below is a list of specific roles and their responsibilities.
Maintainers are individuals who have “Commit” rights; And are the primary caretakers of the code and the strategic vision of the project. They are empowered to make decisions and resolve disputes for all contributions. They are appointed by MOSIP.
Project Lead is the chair of the committee of maintainers. They are appointed by MOSIP.
Contributors are the people or organisations who take part actively in the project and its meetings, code, design, and test and are recognized for their contributions. The contributors are part of the GitHub Members and would be actively involved in the discussion of a PR and review. Members strongly influence the Maintainer's decision.
Members are either individuals or persons affiliated with contributing organisations. All contributions are bound by the licensing of the project.
Product Owner is responsible for the analysis, design, development, and implementation of business solutions to meet the needs of the organisation. He/She must have a strong understanding of the business domain, processes, and software development lifecycle Agile development methodologies).
Scope of Contributions
The whole of the project is open to contributions. The kind of contributions that are welcome include:
Code
Documentation
Design
Raising Bugs
Feature Request
Code, Documentation & Design
All artefacts including the code are maintained in the github repository.Contributions can be made by raising a Pull Request.
Reporting Issues & Feature Request
Issues and backlog are maintained in Jira and members of the project team will have access to Jira to add feature requests and report bugs
One off users will not have access for bug reports and feature requests. They can report the same in the community pages
Regular users who do not have access, can request the same and the maintainers can provide access after considerationWe use Jira to track the work associated with the project (account required). That is where issues open for community contribution can be found.Pull Request Review ProcessThe process to contribute the code is present here. Once code is submitted, it is reviewed through the following process:
We use Jira to track the work associated with the project (account required). That is where issues open for community contribution can be found.
The process to contribute the code is present here. Once code is submitted, it is reviewed through the following process:
At least two members should have reviewed the submitted contribution for the pull request to be accepted. The maintainers may request for more reviews of the code from other relevant members.
If the members deem the submitted code to be critical to overall product development, they can seek the inputs of the relevant product owners for the review process.
The maintainers review the two (or more) sets of comments received from the tech leads and the submitted code before taking a decision regarding committing the code to the appropriate branch.
The decision by the maintainer is communicated to the contributor via Jira as well as Pull Request.
In exceptional cases such as an emergency or an urgent requirement or a very trivial but time-sensitive correction, a maintainer may - at their discretion - choose to directly review the submitted pull request and take a decision on the commit.
Project Lead initiates the release process. The process can be found here.
Attribution is in accordance with the relevant licence. Individual and affiliated contributors will be listed.
The key decisions to be taken are for the following activities
Roadmap and backlog priority
Triaging of bugs and requirements
Accepting a contribution Pull Request)
Releases
Most decisions will be made in periodical meetings where owners of the relevant aspect of work present a case for a decision and the decision will be made either by consensus, or by majority where a quorum exists. The maintainers of the project will be the decision makers. The project lead will have veto power on decisions due to their expertise and commitment to the vision of the project. Contributors can share their views in these meetings for consideration.
Open Source Governance Process at MOSIP
1. Overview
2. Governance Structure
Roles and Responsibilities
3. Contributions
Process to Contribute
Pull Request Review Process
Release process
Attribution
4. Decision-Making
Certificate management (self-signed and externally signed).
Digital signing operations (e.g., signing Verifiable Credentials).
Key rotation and revocation.
Secure integration with hardware-backed key stores (e.g., HSM).
By consolidating these cryptographic operations in one trusted service, Certify ensures the integrity, confidentiality, and long-term security of all cryptographic materials.
Below are the main capabilities and how Key Manager supports them in Inji Certify:
The Key Manager generates various types of keys: root/master keys, module-level keys, and application-specific (base) keys.
Asymmetric algorithms such as RSA, ECC, Ed25519 etc. are used based on the VC configuration.
Root and module master keys can be generated at the time of installation of Inji Certify
Base keys (application-specific) are auto-generated as needed.
Private keys are stored securely in a key store. In Inji implementation, a Hardware Security Module (HSM) is used to store root and master keys, while base keys are stored in a database encrypted by module keys.
Key metadata (aliases, identifiers) is maintained in a key-alias table; the encrypted key material resides in a key-store table.
The Key Manager supports integration with HSMs via PKCS#11 or JCE.
Self-Signed Certificates: When no external CA is provided, the Key Manager can generate self-signed certificates. For example, root key is self-signed.
CSR Generation: It supports generating CSR (Certificate Signing Requests) for any key, so that you can obtain a certificate signed by an external CA.
Uploading Externally-Signed Certificates: Once you obtain a CA-signed certificate, you can upload it to the Key Manager, updating existing certificate with CA signed certificate.
For signing credential (VC) issuance, the Key Manager uses the appropriate key (module or base) and the associated certificate to sign the VC payload.
Automatic Rotation: Keys have default validity periods. For example, in MOSIP, root keys are valid for ~5 years, module keys for ~3 years, base keys for ~2 years.
Forced Rotation: Admins can force key regeneration via APIs (e.g., a generateMasterKeyAPI) with a “force” flag. Existing keys are invalidated and new ones generated.
On expiry, key manager automatically generates new keys and ensures that cryptographic operations switch over to the new valid keys.
Duration of key rotation is configurable which is handled through a table named as 'key-policy-def'.
Key manager has the capability to pre generate keys before expiry. Duration for the pre generation is a configurable which is handled through a table named as 'key-policy-def'.
In case of externally CA signed certificate is used for key generation, and certificate expires, the system falls back: Key Manager re-generate keys using a self-signed certificate (or whatever default mechanism is configured).
Mitigation: To avoid lapse in trust or broken signing, users (issuer administrators) must proactively upload a new valid certificate before the current one expires.
The Key Manager is designed to work with HSMs, ensuring that root and module keys never leave secure hardware.
For setups without HSM, the Key Manager also supports other keystore types (PKCS12), configurable via properties. (This option is not recommended during the production environment).
Role of Key Manager Specifically in VC Signing Workflow (In Certify).
Putting the above capabilities in the context of Verifiable Credential (VC) issuance in Inji Certify:
Initial Setup (If PKI is already existing)
The system admin uses Inji Certify API which internally uses KeyManager service to generate a master signing key pair.
The admin can request a CSR from Inji Certify API for the generated signing key (via generateCSR), so they can share it to be externally singed by CA
Once the certificate is signed, they upload the CA certificate to Inji Certify, then upload their signed certificate, binding it to the key.
When Certify issues a VC, it calls Key Manager to sign the credential payload.
Key Manager uses the private key associated with the signing key (which is backed by the uploaded certificate) to compute a digital signature.
The signed VC thus has cryptographic integrity and can be verified by relying parties using the public certificate.
Security & Trust: All signing keys are managed securely; private keys are never exposed, especially when using HSM.
Flexibility: Support both self-signed workflows (for simplicity) and externally-CA-signed certificates (for integration into existing PKI).
Operational Control: Administrators have full control over key lifecycles, rotation, and certificate management.
Interoperability: By using standard cryptography and certificate formats, Certify’s VCs can be validated by any compliant verifier.
Resilience: With key-rotation and fallback mechanisms, the system can recover from certificate expiry.
For deeper technical details about the Key Manager component itself, you can refer to the MOSIP documentation here.
Overview
Capabilities & Responsibilities
Key Generation
Secure Storage
Certificate Management
Signing & Cryptographic Operations
Key Rotation
Certificate Expiry Handling
Integration with Hardware Security Module (HSM)
Credential Issuance
Key Benefits for Inji Certify
Customizability
Verification is performed not only from the end user perspective but also from the System Integrator (SI) point of view. Hence Configurability and Extensibility of the software is also assessed. This ensures readiness of software for use in multiple countries. Since MOSIP is an "API First" product platform.
Testing scope has been focused around the below features
Docker compose testing for Mock Data Provider plugin (csv), Framer use case - 1.1 & 2.0 VC
Integration with INJI Web - Limited to download only 1.1 VC
Persona based approach has been adopted to perform the IV&V, by simulating test scenarios that resemble a real-time implementation.
A Persona is a fictional character/user profile created to represent a user type that might use a product/or a service in a similar way. Persona based testing is a software testing technique that puts software testers in the customer's shoes, assesses their needs from the software and thereby determines use cases/scenarios that the customers will execute. The persona needs may be addressed through any of the following.
Functionality
Deployability
Configurability
Customizability
The verification methods may differ based on how the need was addressed.
Verification is performed on configurations as mentioned below
Default configuration
English
Note:
Docker setup - Authorization endpoints pointing to collab.mosip.net
Total
Passed
Failed
Ignored
129
53
0
67
Test Rate: 100%,
With Pass Rate: 96% and Fail Rate: 0%
Total
Passed
Failed
Ignored
129
41
0
79
Test Rate: 100%,
With Pass Rate: 100% and Fail Rate: 0%
Total
Passed
Failed
Ignored
129
26
0
94
Test Rate: 100%,
With Pass Rate: 100% and Fail Rate: 0%
Ignored scenarios are not related to particular use case and 9 scenarios are known issues that can be tracked in INJICERT-681.
Below are the detailed test metrics by performing manual/automation testing. The project metrics are derived from Defect density, Test coverage, Test execution coverage, test tracking and efficiency.
The various metrics that assist in test tracking and efficiency are as follows:
Passed Test Cases Coverage: It measures the percentage of passed test cases. (Number of tests passed / Total number of tests executed) x 100
Failed Test Case Coverage: It measures the percentage of all the failed test cases. (Number of failed tests / Total number of test cases executed) x 100
Testing Scope
Test Approach
Verified configuration
Test execution statistics
Automation Statistics
Sunbird use case
Mock use case
Mosipid use case
Detailed Test metrics
Component: Inji Wallet UI (React Native)
Purpose: Renders the user interface and manages application state using xState.
Features: Cross-platform UI, declarative state management, user interaction handling.
Communication Bridge Layer (Yellow)
Component: React Native Bridge
Purpose: Enables communication between JavaScript and native code (Java, Kotlin, Swift).
Functionality: Accesses native platform features from React Native.
This architecture ensures scalability, security, and maintainability, delivering a seamless digital credential management experience.
Architecture Layers
Inji Wallet Architecture
Detailed Component Breakdown
React Native Application Components
Native Modules
External Modules
Data Flow & Component Interactions
Key Architectural Principles
Technology Stack Summary
On successful registration the UIN is sent to you over the email you used for registration, For more details you follow the Generating Demo Credentials Guide.
Inji Mobile Wallet
UIN Credentials
Insurance Credentials:
Inji Web Wallet
Inji Verify
Verifiable QR Code - Valid VC
Sample QR code - Valid VC Data
Data Model v2.0
Sample QR code - Valid VC Data
Data Model v1.1
Verifiable QR Code - Expired VC
Sample QR code - Expired VC Data
Verifiable QR Code - Invalid VC
Sample QR code - Invalid VC Data
Feel free to scan or upload these QR codes to experience the functionality firsthand.
dependencyResolutionManagement {
repositories {
google()
mavenCentral()
maven("https://oss.sonatype.org/content/repositories/snapshots/")
}
}
---
## 📘 API Documentation
- `deviceSupportsHardware() => boolean`
Checks if the device supports secure hardware-backed keystore.
- `generateKey(alias, isAuthRequired, authTimeout?)`
Generates a symmetric key for encryption/decryption with optional biometric auth.
- `generateKeyPair(type, alias, isAuthRequired, authTimeout?)`
Creates a public-private key pair (RSA or EC) with optional authentication.
- `encryptData(alias, data, onSuccess, onFailure)`
Encrypts data using a symmetric key associated with the given alias.
- `decryptData(alias, encryptedText, onSuccess, onFailure)`
Decrypts previously encrypted data using the associated key alias.
- `sign(signAlgorithm, alias, data, onSuccess, onFailure)`
Signs data using the specified key and signature algorithm (RSA, ECDSA are supported).
- `generateHmacSha(alias, data, onSuccess, onFailure)`
Generates an HMAC signature using the specified alias and data.
- `generateHmacSha256Key(alias)`
Creates a symmetric key suitable for HMAC-SHA256 operations.
- `hasAlias(alias) => boolean`
Checks if a key exists for the specified alias.
- `removeKey(alias)`
Deletes the key associated with the given alias from the keystore.
- `removeAllKeys()`
Clears all keys stored in the keystore.
- `retrieveKey(alias)`
Retrieves the public key for the specified alias.
- `storeGenericKey(publicKey, privateKey, account)`
Stores a custom key pair in the keychain/keystore linked to an account.
- `retrieveGenericKey(account)`
Retrieves the stored key pair associated with the specified account.
---
Mobile OS based on a modified Linux kernel and open-source software, designed for touchscreen devices. Used to build the app for Android devices.
14
Mobile OS developed by Apple for smartphones. Swift is used for iOS development.
JavaScript framework for building native mobile apps using React.
VC Issuance: Authorized methods return VCs of an individual in linked data-proof (JSON-LD) and JWT formats.
Inji Certify is a powerful and versatile platform designed for seamless issuance of Verifiable Credentials (VCs). It leverages a robust architecture that integrates with existing credential registries, enabling organizations to efficiently and securely issue standards-compliant VCs.
Key features of Inji Certify for VC Issuance include:
Seamless Integration: Replaces the earlier reliance on eSignet with a seamless integration of the Sunbird RC plugin, streamlining the credential issuance process.
Flexible Schema Definition: Allows issuers to easily define and customize credential schemas for various credential types, ensuring compliance with W3C VC v1.1 standards and facilitating interoperability.
Efficient Issuance: Enables the efficient issuance of VCs in the industry-standard JSON-LD format.
Enhanced Security: Incorporates robust security measures to protect the integrity and confidentiality of issued credentials.
Inji Certify supports a flexible plugin architecture that allows for seamless integration with various external systems and data sources. This plugin architecture enhances the platform's adaptability and allows for customization to meet diverse credentialing needs.
The plugins are categorized into two main types:
Role: VC Issuance Plugins are responsible for the core process of generating and issuing Verifiable Credentials (VCs).
Functionality:
These plugins typically interact with external identity or authentication systems (e.g., identity providers, registries) to obtain necessary information about the credential recipient (e.g., name, date of birth, unique identifiers).
They then utilize this information to generate the VC in the appropriate format (e.g., JSON-LD) according to the defined credential schema.
Finally, the plugin issues the generated VC to the recipient.
Examples:
Mock Certify Plugin: This plugin simulates a real-world scenario by interacting with the Mosip Mock Identity System. It retrieves sample identity data from the mock system and subsequently generates and issues VCs based on this data. This plugin is valuable for testing and development purposes.
MOSIP IDA Certify Plugin: This plugin integrates with the Mosip National ID System, a real-world identity platform. It retrieves verified identity information from the Mosip National ID System and utilizes this data to generate and issue VCs.
Role: Data Provider Plugins are responsible for fetching relevant data from external sources or registries.
Functionality:
These plugins connect to external data sources (e.g., databases, APIs, registries) and retrieve the necessary information about the credential recipient or the credential itself.
The retrieved data is then provided to a VC Issuance Plugin for further processing, including VC generation and issuance.
Examples:
Mock CSV Data Provider Plugin: This plugin retrieves data from a CSV file that acts as a sample data source or a simplified registry. It extracts relevant information from the CSV file and provides it to a connected VC Issuance Plugin. This plugin is useful for testing and development purposes, allowing for easy simulation of data from various sources.
Postgres Data Provider Plugin: This plugin connects to a PostgreSQL database that acts as a data repository. It retrieves relevant data (e.g., user profiles, academic records) from the specified tables within the PostgreSQL database and provides this data to a connected VC Issuance Plugin for further processing.
Inji Certify employs OpenID4VCI, an extension of the OAuth 2.0 protocol, for secure and interoperable credential issuance. This mechanism ensures:
Standards-Based Interaction: Establishes compatibility with various digital wallet providers.
Reliable User Authentication: Authenticates individuals before issuing credentials.
Wallet-Initiated Flow: Supports a streamlined flow where VCs are delivered just in time upon request from the user’s wallet.
Functional Overview
Overview
How does Inji Certify work?
Verifiable Credentials Issuance with Inji Certify
Plugin Integration
VC Issuance Plugins
Data Provider Plugins
Authentication and Credential Transfer
Before proceeding with the installation, ensure you have the following installed:
A URL to host your DID for verifying VCs(Verifiable Credentials) can use here or any other self-hosted server which is highly available for use by verifiers.
Please visit the Pre-requisites section in the ReadME file to explore in detail.
The setup involves deploying Inji Certify using Docker Compose. Follow the steps given in the README file within the Inji Certify repository.
Once the setup is complete, you can start exploring the functionality of Inji Certify:
Configure Credential Schemas: Set up schemas for various types of certificates you wish to issue.
Interact with the System: Test the issuance and management of credentials through our reference platform Inji Web. Please click here to explore the steps!
For additional configuration and usage instructions, consult the documentation included in the repository.
This means configure mosip.certify.authorization.url and configure the mosip.certify.authn.issuer-uri & mosip.certify.authn.jwk-set-uri appropriately.
General Concept: This step configures your application ("Certify") with the essential endpoints of your chosen Identity Provider ("Keycloak").
mosip.certify.authorization.url: This corresponds to the provider's standard OAuth 2.0 Authorization Endpoint, where users are redirected for login and consent.
mosip.certify.authn.issuer-uri: This is the standard OIDC Issuer Identifier. Your application uses this to verify the iss (issuer) claim in tokens it receives, ensuring they come from the expected provider.
mosip.certify.authn.jwk-set-uri: This is the standard OIDC JWKS URI. Your application fetches the provider's public keys from this URL to verify the digital signature of received JWTs (like ID Tokens).
Note: Any compliant OAuth 2.0 / OIDC provider will have corresponding values for these standard endpoints, which you'd find in their documentation or OIDC discovery document (.well-known/openid-configuration).
Configuremosip.certify.identifier to the value matching the aud value configured in the client.
General Concept: This configures your application's own identifier (mosip.certify.identifier) as it should appear in the aud (Audience) claim of tokens issued by the IdP for this specific application ("client" registration in the IdP).
Note: Validating the aud claim is a standard security measure for resource servers (like your "Certify" application) to ensure a received token was intended for them and not another application. The value is typically the Client ID or a specific Audience URI defined during application registration in the IdP.
Configure the scope correctly as per the scope of the VerifiableCredential as configured in the Keycloak client in the prior steps.
General Concept: scope is a standard OAuth 2.0 parameter representing the permissions your application is requesting.
Note: Your application needs to be configured to request the specific scopes it requires (these might be standard OIDC scopes like openid, profile, email, or custom scopes related to specific functionalities, like Verifiable Credentials here). Importantly, these scopes must also be explicitly allowed for your application ("client") within the Identity Provider's settings (in Keycloak's client configuration in this case).
Configure the credential types to match the VC in the well known
General Concept: This step is specific to the application's domain (handling Verifiable Credentials). It involves configuring the application to understand the specific types of resources it manages.
Note: The reference to "well known" likely points to a discovery mechanism (perhaps the OIDC discovery endpoint if extended, or a domain-specific registry/schema definition location) where these credential types are formally defined. This ensures the application's internal configuration aligns with external standards or definitions relevant to its function.
To explore all the available APIs of Inji Certify, refer to the API documentation provided within the platform. This will allow you to interact with the various endpoints and understand their functionality in detail.
For further insights and guidance on using Inji Certify effectively, refer to the following:
Comprehensive Documentation: Available within the repository’s README file.
Support: Engage with the developer MOSIP community or seek support for any issues encountered during the setup.
Configuring Certify with Keycloak Authorization Server
Set the Authorize URL of Certify to point to the KeyCloak Authorization server,
Explore the APIs
Additional Resources
18.2v
React lets you build user interfaces out of individual pieces called components. Used for OIDC UI
2.3.6.RELEASE
Spring Boot is an open-source Java framework used to create a Micro Service. Spring boot is used for programming standalone, production-grade Spring-based applications with minimal effort. Used for esignet-services
2.0
9.5.0
Nest (NestJS) is a framework for building efficient, scalable Node.js server-side applications. It uses progressive JavaScript, is built with and fully supports TypeScript. Used for Sunbird credentialing services
11
Java is a high-level, class-based, object-oriented programming language that is designed to have as few implementation dependencies as possible. Used in eSignet-services
12.1V
PostgreSQL is an advanced, enterprise-class open-source relational database that supports both SQL (relational) and JSON (non-relational) querying.
PostgreSQL License (, )
Deployment:
The table below specifies the tools needed to deploy Inji Certify:
Tool/Technology
Version
Description
License
26 and above
Docker is a set of platform as a service (PaaS) products that use OS-level virtualization to deliver software in packages called containers.
Tool/Technology
Version
Description
License
JIRA
Description
Authenticate user API failing with test automation
Repository
Version
inji-certify
Below is the list of known issue(s) related to the release v0.13.1. To access all the known issues related to Inji Certify please refer here.
If you want to develop a new feature, please elaborate on the idea and discuss the design before starting development. 2. In your local repository, fetch the upstream.
3. On your local repo, switch to a branch if you are working on an older release or stay in main/develop branch.
4. Create a new issue branch with the name of the issue.
5. Make sure you are up-to-date with the upstream repo.
6. Now feel free to make the change in the code or documentation. Reach out to our community for any queries. Once done with the work, commit your changes by referring to the Issue ID in the commit message. Eg:
7. Once again ensure that you are up-to-date with the upstream repo as it may have moved forward.
8. Build and test your code. Make sure to follow the coding guidelines. Provide unit test cases for the changes you have built.
9. Push to your forked repo (origin).
10. On your forked remote repository from GitHub, create a pull request using the Contribute button. Direct the pull-request to main or any specific branch upstream.
11. Make sure the automatic tests/checks on GitHub for your pull request pass.
12. Reviewers shall review the pull request. Reach out to the community for a faster response.
Ensures that sensitive credentials (eg: Driving Licenses ) are issued only after validating an authoritative credential (eg: National ID).
User‑Centric Verification: The holder presents credentials directly from their wallet with explicit consent.
Reduced Backend Dependencies: Eliminates the need for additional backend integrations or manual checks for eligibility verification.
Standards Alignment: Leverages OpenID4VCI and OpenID4VP, improving interoperability across issuers and wallets.
Privacy by Design: Credentials are shared only for verification purposes and are not persisted beyond the issuance transaction.
The following sequence describes how Inji Certify handles Driving License issuance using the Presentation During Issuance feature.
The resident initiates the download of a Driving License VC from the Inji Wallet. The wallet sends an issuance request to Inji Certify using the supported OpenID4VCI issuance flow.
Certify evaluates the issuance policy and determines that National ID verification is mandatory for Driving License issuance.
Inji Certify prepares and sends a Presentation Request to the wallet, specifying:
Required credential type: National ID VC
Required claims or attributes (if applicable)
Challenge / nonce to prevent replay attacks
This request instructs the wallet to present a valid National ID credential before issuance can proceed.
Upon receiving the presentation request:
The wallet discovers available credentials that satisfy the request
The resident is prompted to select their National ID VC
The wallet constructs a Verifiable Presentation (VP), signed using the holder’s proof
The generated VP is then submitted to Inji Certify.
Inji Certify validates the received Verifiable Presentation by performing:
Cryptographic signature verification
Issuer trust validation
Credential schema and claim validation
Expiry and revocation status checks
Nonce and challenge verification
Only upon successful verification does Certify proceed further.
After successful presentation verification:
Certify constructs the Driving License Verifiable Credential
The credential is issued to the wallet via the credential endpoint
The wallet securely stores the issued Driving License VC for the resident’s use.
The resident can now view and use the Driving License VC from their wallet. If verification fails at any stage, the issuance is terminated and an appropriate error is returned.
Replay Protection: Presentation requests include nonces and challenges to prevent replay attacks.
Explicit User Consent: Wallet requires user approval before sharing any credential.
Minimal Disclosure: Only required credentials and claims are requested for verification.
No Persistent Storage: Presented credentials are not stored beyond the verification process.
Client‑based authorization is not supported.
Only a single issuance mode can be configured per issuer.
If Presentation During Issuance is enabled, alternative issuance modes (e.g., simple wallet‑initiated issuance without verification) are not supported for the same issuer.)
Please refer to the relevant GitHub technical documentation for detailed configuration, policy setup, and API‑level implementation details.
Overview
Why This Feature Matters
How It Works – Step‑by‑Step (Certify Perspective)
1. Certify Receives Issuance Request
2. Certify Sends Presentation Request
3. Wallet Collects User Consent and Credential
4. Certify Verifies the Presentation
5. Certify Issues the Driving License VC
6. Issuance Completion
Security Considerations
Limitations
User Safety & Compliance: Alerts users that a credential is no longer usable and prevents them from unknowingly sharing revoked data.
Offline-first UX: The wallet supports offline scenarios (BLE) and indicates pending status when online checks are unavailable.
Status recheck: Status checks are performed when the credential is first downloaded and can be triggered manually by the user.
Fully supported (revocation checks):
ldp_vc (Linked Data Proof VC) with an credentialStatus entry that follows W3C Bitstring Status List semantics.
Status entries where statusPurpose == "revocation".
Multi-bit status lists (statusSize > 1) are supported (0 = valid, >0 = revoked).
Not yet checked (bypass for now):
sd-jwt (SD-JWT) — revocation check currently bypassed (future work planned).
mDoc/mDL — depending on issuer support; currently may be bypassed if the credential lacks a StatusList entry.
When a verifiable credential is downloaded into the wallet, the app automatically checks whether it is still valid.
The wallet looks up the status for every credential downloaded, where the wallet checks if the issuing authority has marked it as still active or revoked (no longer valid).
The wallet verifies the information before trusting the response. The wallet makes sure the data is correct:
a) It checks that the file is valid.
b) It checks that the information is up-to-date.
c) It checks (on Android) that the file is digitally signed and secure.
The wallet updates the screen, and the app now shows the correct status:
a) 🟢 Valid — You can use or share it
b) 🔴 Revoked — You cannot use it
Wallet logs the activity. The action (“Status checked”) is saved in your History so you always know when the last check happened.
Format coverage:
Revocation checks currently apply only to credentials using the W3C Bitstring Status List (LDP-VC). SD-JWT and some other credential formats are bypassed for status checks until issuers provide compatible status-list metadata or wallet libraries add support.
iOS signature verification:
Full cryptographic signature verification of the Status List Credential is skipped on iOS for the current release (processing still decodes bitstring). iOS signature verification is planned for a future update.
Network dependence & offline UX:
When offline or when the status list URL is unreachable, the wallet marks the status as PENDING. Verifiers must treat PENDING per their policy (some verifiers may allow conditional acceptance; others must reject).
Revocation push & near-real-time updates:
Current flow is pull-based; there is no push notification mechanism for immediate issuer-driven revocation propagation to wallets. This may cause brief windows of stale state between issuer revocation and wallet recheck.
Multi-purpose status entries:
Wallet currently supports only statusPurpose = "revocation". Other purposes (e.g., suspension) are not handled.
Error reporting granularity:
Some failure states map to a generic PENDING; more granular error messaging could help users and integrators diagnose issues (e.g., signature failure, decode error, invalid index).
Scale of encodedList:
Very large encodedList files for population-scale deployments may require optimized storage, streaming, and verification strategies (e.g., segmented lists, CDN usage).
Users don’t need to remember IDs or complete repetitive verification steps. Credential selection and consent happen directly within the wallet.
Only required credentials are shared, and users explicitly approve what data is presented, ensuring transparency and user control.
Built on OpenID4VCI and OpenID4VP standards, PDI supports interoperable credential ecosystems across sectors and issuers.
Credentials That Can Be Presented (for verification)
Any verifiable credential that:
Is stored in the wallet
Matches the issuer’s presentation policy
Conforms to supported formats and schemas
Supported Formats
W3C JSON-LD Verifiable Credentials (v1.1 and v2.0)
Credentials conforming to the W3C Verifiable Credentials Data Model, including JSON-LD-based credentials with linked data proofs.
mDoc / mDL (ISO 18013-5 / 18013-7)
Mobile document credentials, such as mobile driving licenses and other ISO-compliant mobile IDs, where issuer and verifier support is available.
SD-JWT (IETF)
Selective Disclosure JWT-based credentials compliant with IETF specifications, enabling privacy-preserving disclosure of claims.
The exact credential requirement is defined by the issuer.
User requests a new credential
The user initiates a request for a new credential from an issuer using Inji Wallet.
Issuer requires verification
The issuer determines that an existing credential must be presented to confirm eligibility or identity.
Wallet displays eligible credentials
Inji Wallet identifies and shows credentials that satisfy the issuer’s request.
User selects a credential
The user chooses one credential to present.
User reviews and approves sharing
The wallet clearly shows what information will be shared, and the user provides explicit consent.
Wallet sends Verifiable Presentation
The wallet creates and sends a signed Verifiable Presentation to the issuer.
The issuer verifies the presentation
The issuer validates:
Credential authenticity
Trust chain of the original issuer
Proof of subject control
The issuer issues the new credential
Upon successful verification, the issuer issues the requested credential.
The wallet stores the issued credential
The new credential is securely stored and becomes available to the user.
Display issuer requirements
Show eligible credentials
Capture user consent
Create and send Verifiable Presentations
Store newly issued credentials securely
Define presentation requirements
Verify presented credentials
Enforce issuance policies
Issue credentials upon successful verification
Some failure cases (e.g., invalid presentation, policy mismatch) may return generic errors; enhanced user-facing messaging may be added in future updates.
Presentation During Issuance – Inji Wallet: To learn how PDI works end-to-end, including issuer policies, presentation exchange, and issuance flows.
Overview
Why This Feature Matters
a) Stronger Security & Fraud Prevention
b) Trust-Based Issuance
c) Improved User Experience
d) Privacy-Preserving Verification
e) Standards-Based & Interoperable
Supported Credential Types
How Does the Presentation During Issuance Flow Work?
User Flow (Step-by-Step)
Wallet Responsibilities
Issuer Responsibilities
Error Feedback Granularity
Learn More
The implementation should not attempt to initialize multiple times unless it's necessary.
The implementation should work in offline mode.
The implementation should support auto-downloading the latest models or any other configuration/artefacts necessary.
To enhance logging and traceability, the implementer should accept a parameter known as traceabilityId, which helps to trace the logs on the server.
Signature
Name
Description
Type
config
Configuration with model file and matcher threshold
Any object
Inji Wallet would initialize the config as a JSON. The JSON would contain the following items
Attribute Name
Description
traceabilityId
Traceability id is used to trace the telemetry data
io.inji.sdk.*
Any configuration that starts with io.inji.sdk would
be sent in the config map.
Standard Return Codes (true or false)
Response
Status
true
Success
false
Error
An asynchronous API that compares two images, allowing for different image formats such as PNG, JPG, HEIC or Template. Upon completion returns a boolean value. The API has an expected timeout and it is expected that the implementors clear the memory and processing upon timeout.
To ensure fraud prevention in compliance with ISO/IEC 30101, the faceAuth verification should include passive liveness checks, such as picture-in-picture.
To enhance logging and traceability, the implementors should send telemetry using traceabilityId. The id is set during the configure API call, It is expected that the same is used here. In Inji Wallet, AppId is used as traceabilityId.
Timeout is set in seconds.
Signature
Parameters
Name
Description
Type
timeout
Timeout in seconds. After this time the SDK should stop processing.
integer
capturedImage
The image that is captured by the camera
Standard Return Codes (match or no match)
Response
Status
true
Matched
false
Not Matched
false
Error
The following guidelines apply to individuals who are developing the face SDK:
It is prohibited to collect any personally identifiable information (PII) or phone details.
Inji Wallet includes built-in telemetry, and all telemetry data must be transmitted to the designated system. Telemetry enhances Inji Wallet's observability features by capturing specific events, creating measures, and monitoring various user actions and events.
Recording or transmitting IP addresses, user details, Phone IMEI, phone numbers, or user photos in telemetry or logs is strictly prohibited
The use of device fingerprints should be limited to managing the SDK license.
Introduction
Configure API
async function configure(config: any): Promise<boolean> {
if (already initialised & successful) {
return true;
}
Initialise....
if (successfully initialised) {
return true;
}
return false;
}
async function faceCompare(timeout: int ,capturedImage: string, vcImage: string): Promise<boolean> {
logic to compare capturedImage & vcImage.....
setTimeout(cancel);
//logic to match
if (matched) {
return true;
}
return false;
}
The resources section provides a comprehensive introduction to the Inji modules — Inji Mobile Wallet, Inji Web Wallet, Inji Verify, and Inji Certify, showcasing how its modules deliver trusted, low-cost, and scalable credential management across sectors.
Each demonstration video explains the product’s purpose, setup, features, and practical applications. Together, they offer an end-to-end understanding of how verifiable credentials can be issued, held, and verified instantly, across both digital and paper-based formats.
An introduction to the Inji Stack, the open-source suite by MOSIP for verifiable credentials.
Explanation of how the core modules like Inji Certify, Inji Wallet, and Inji Verify work together to create a trusted digital credential ecosystem.
Overview of Inji's role in enabling secure, interoperable, and privacy-preserving data exchange.
Demonstrates the potential of verifiable credentials in sectors like education, healthcare, governance and many more.
What you'll learn:
Introduction to Inji Certify, the credential issuance module of the Inji Stack.
Demonstrates how authorized entities can issue, manage, and revoke verifiable digital credentials.
Explains interoperability with OpenID4VC, W3C VC, and other standards.
What you'll learn:
Step-by-step local deployment of Inji Certify using Docker Compose.
Explains configuration of plug-ins, environment variables, and credential templates.
Demonstrates issuance and revocation flows in a local testing environment.
What you'll learn:
In-depth look at Inji Certify's credential issuance architecture.
Explains credential templates, signing algorithms, revocation APIs, and integration with data sources.
Details plug-in architecture for flexible issuance from multiple registries or databases.
What you'll learn:
Comprehensive walkthrough of the Inji Mobile Wallet app.
Demonstrates secure storage, management, and sharing of verifiable credentials.
Covers key features:
What you'll learn:
Introduction to the Inji Web Wallet, a browser-based wallet that complements the mobile app.
Demonstrates credential management and secure sharing using QR codes in both digital and printed form.
Explains how the web wallet supports W3C VC, OpenID4VP, and ISO standards for global interoperability.
What you'll learn:
Step-by-step guide to setting up the Inji Web Wallet locally using IntelliJ instead of Docker for faster iteration.
Walkthrough of dependencies, configuration steps, and environment setup.
Demonstrates how to load and test credentials within the local environment.
What you'll learn:
Configuration of Mimoto backend for Inji Wallet integration using Docker Compose.
This setup provides a ready-to-run local Docker environment for Mimoto, which acts as the backend for Inji Web and the BFF (Backend-for-Frontend) for Inji Mobile, enabling secure OIDC-based authentication and credential exchange.
It helps developers quickly configure, test, and integrate Mimoto with Inji services in a non-production environment.
What you'll learn:
Overview of Inji Verify, the verifier module for digital and paper-based credential verification.
Highlights modular SDK integration, interoperability with OpenID4VP, and verifier backend service.
What you'll learn:
Detailed explanation of Inji Verify's architecture, including backend services, SDKs, and UI components.
Covers OpenID4VP flows, handling of verifiable presentations, and data validation.
Shows how to run Verify locally using Docker Compose and how to integrate SDK components into React-based applications.
The workshop aims to provide a comprehensive understanding of the Inji ecosystem, focusing on its various components, configuration, and practical usage. It covered essential topics to help participants effectively use and integrate Inji's features.
Understanding DID Methods: The workshop explains the different Decentralized Identifier (DID) methods supported by Inji, helping participants grasp how digital identities are managed.
OIDC Client and p12 File Creation: Participants learn how to create an OIDC client and generate a p12 file, ensuring secure key storage and authentication processes.
Configuring Mimoto in Inji Web: Detailed steps are provided to configure Mimoto within the Inji Web application, addressing common issues and ensuring seamless integration.
The Workshop demonstrates how to integrate Inji Certify, a credential issuance platform, with a custom data provider plugin to issue 'Verifiable Credentials'. The specific use case covered is issuing farmer IDs based on official land registry data.
Data Setup: A sample farmer registry is created in a database with details like National ID, Name, Phone Number, and Land Ownership Information.
Configuration: A velocity template is defined to format the data, issuer information and verification keys are configured, and a "well-known" property is set up.
Plugin Development: A data provider plugin is created to fetch farmer data from the registry based on the national ID.
The webinar delves into the technical architecture and implementation details of the Inji Stack, specifically focusing on the Inji Wallet and its integration with other stacks/components like eSignet and Inji Certify. The webinar offers a comprehensive overview of the technical intricacies involved in building a decentralized credential issuance and verification system using the MOSIP's Inji platform.
Inji Wallet: A mobile application that acts as both a digital wallet for storing verifiable credentials (VCs) and a verifier of VCs.
Integration with eSignet and Inji Certify: eSignat is used for authentication and authorization, while Inji Certify is responsible for issuing VCs.
Technical Architecture: The webinar covers the high-level architecture, including the use of Mimoto as a backend for frontend (BFF), the role of the Tuvali library for secure VC transfer, and the integration of native modules for specific functionalities.
The webinar delves into MOSIP's solutions for identity verification and credential management also to see how national IDs empower citizens in the digital age.
National ID as an Enabler: Learn how national IDs can be used to access various services.
Digital Transformation: Explore how IDs can streamline processes for citizens and governments.
eSignet: An online authentication solution supporting multiple methods like OTP, digital wallets, and biometrics.
National ID VC Issuance
Overview
The UIN Issuance capability in Inji Certify 0.14.0 introduces a flexible and extensible approach to credential issuance by decoupling dependency on the traditional IDA system and enabling dynamic data retrieval through a new IDA Data Provider Plugin. This enhancement allows Certify to fetch raw KYC data, transform it into Verifiable Credentials (VCs), and support multiple cryptographic key types and signing algorithms aligned with MOSIP standards.
Instead of relying on a fixed IDA-driven issuance flow, Certify now leverages a plugin-based architecture where external data sources (such as IDA APIs) can be integrated seamlessly. This enables greater control over credential structure, claim mapping, localization, and signing behavior, making the issuance process more adaptable across different country implementations.
Why This Feature Matters
The introduction of the IDA Data Provider Plugin and enhanced issuance flow brings several key benefits:
Flexible Data Integration: Allows Certify to fetch raw KYC data directly from IDA APIs, enabling custom credential structures instead of relying on predefined formats.
Expanded Cryptographic Support: Supports multiple key types such as RSA, EC R1, ECK1, and ED, overcoming earlier limitations where only RSA-based signing was supported.
Improved Customization: Enables dynamic mapping of claims using templates, including support for custom claims and localized attributes (e.g., multi-language names and addresses).
Decoupled Architecture: Separates data fetching from credential issuance using plugin models, making the system more modular and extensible.
Enhanced Trust & Verification: Supports country-specific signing keys with public key verification via DID URLs, allowing issuers to validate credential authenticity independently.
Operational Resilience: Automatically falls back to internal key manager certificates if external signing certificates expire, ensuring uninterrupted issuance.
Optimized QR Code Generation: Introduces image compression via the kernel biometric API to efficiently embed photos in QR codes without performance issues.
The following sequence describes how Inji Certify handles UIN-based credential issuance using the new plugin-driven architecture:
Certify invokes the IDA Data Provider Plugin, which implements the DataProviderPlugin interface. The plugin uses the fetchData method to construct a request containing:
Individual ID (UIN/VID)
Required claims
This request is sent to the IDA KYC Exchange API.
The plugin retrieves an access token through an OIDC flow:
Token is obtained using e-Signet integration
Cached authentication context is used to optimize performance
Individual ID is retrieved from cache (optionally encrypted based on configuration)
The IDA API responds with a JSON payload containing KYC attributes such as:
Name
Gender
Address
Photo
The plugin forwards this data to Certify for processing.
Certify maps the retrieved KYC data into VC claims using configurable templates:
OIDC claims are transformed into VC-compatible structure
Localization is applied where available (multi-language fields)
Custom claims can be injected via mapping and policy configurations
Certify determines the type of identifier:
UIN or VID is inferred based on format/length using regex or policy rules
Encryption settings are applied based on configuration (secure vs non-secure storage)
Certify prepares the credential for signing:
Selects signing key (country-provided or internal key manager)
Supports multiple key types (RSA, EC, ED, etc.)
Publishes the public key via DID URL for external verification
Certify generates the Verifiable Credential:
Applies the configured template and claims
Signs the credential using the selected key
Embeds compressed photo (if required for QR code)
The credential is then returned to the requesting wallet or system.
Countries can verify issued credentials using the public key exposed via DID URL
If a country-specific certificate expires:
Certify automatically switches to internal key manager
Secure Data Handling: Sensitive identifiers (UIN/VID) can be encrypted based on configuration, though compatibility with e-Signet must be ensured.
OIDC-Based Authentication: All KYC data requests are secured via access tokens obtained through OIDC flows.
Key Transparency & Trust: Public keys published via DID URLs allow independent verification of credential signatures.
Certificate Lifecycle Management: Automatic fallback ensures continuity, but proper monitoring and renewal of certificates is critical.
Encryption of individual ID may require careful alignment between e-Signet and Certify configurations.
Localization support depends on consistency of input data (e.g., language-tagged attributes).
Custom claim configuration requires validation of supported mapping properties.
IDA API-based KYC data retrieval via plugin
Support for multiple signing algorithms and key types
Template-driven VC generation with localization support
QR code optimization with compressed images
Please refer to the relevant for detailed configuration, policy setup, and API‑level implementation details.
Overview
Overview
Inji Certify enables issuers to generate, sign and issue a verifiable credentials. It follows the standard of OpenID4VCI (Open ID For VC Issuance) draft 13. It also issues VC complaints with W3C Verifiable Credentials (1.1 & 2.0). Issuers can configure credential schemas for different certificate types, generating credentials in different VC formats such JSON-LD, SD-JWT etc.
How is the 'Inji Certify Documentation' organised?
The docs follow the typical journey: understand → try → set up → build → integrate → deploy → operate.
Overview: Get the product basics and the mental model. Subsections cover capabilities and core concepts like Features.
Test: Run a working flow end-to-end before you invest in setup. Subsections cover “Try it out”, workflow, and end-user steps.
: Get Certify running locally or in a shared environment. Subsections cover local setup and a guided deployment path.
: Go deeper on how Certify is built and how to extend it. Subsections cover the tech stack, architecture, supported OS, and key management.
: Use the API reference to integrate wallets, clients, and surrounding services. Expect endpoint-level details, request/response shapes, and auth expectations.
: Jump straight to production-style deployment instructions. This points to the Kubernetes-focused deployment guide.
: Track what changed between versions and what to upgrade to. Subsections include per-version notes and test reports.
As an OpenID4VC (draft 13) compliant issuer, Inji Certify provides the following features:
Feature
Status
Description
To know more about features available in Inji Certify please refer to .
Inji Certify features a modular architecture that supports both direct issuance and proxying of VCs from external sources. It interacts with external digital wallets via APIs.
For a detailed view of Inji Certify’s architecture and components, check this .
Inji Certify provides a plugin-based architecture that enables modular, extensible, and customizable credential issuance workflows.
VC Issuance Plugins Handle the retrieval and alignment of Verifiable Credentials (VCs) as per standards, and manage the issuance process.
Data Provider Plugins Fetch raw data from various sources, generate the credential, sign it, and issue it.
Currently supported integrations: PostgresSQL and CSV files.
Inji Certify supporting two mode of deployment to cater different users with different purpose:
Local Development Setup
Deployment with Kubernetes cluster
If you are creating your own custom plugin, you can refer to to know steps to deploy custom plugins using kubernetes.
API Documentation: API endpoints, base URL (/v1/certify), and mock server details are available via Stoplight and Swagger documentation: .
Product Documentation:
To know more about Inji Certify in the perspective of functional and use cases you can refer to our main document:
We welcome contributions from everyone!
to learn how you can contribute code to this application.
If you have any questions or run into issues while trying out the application, feel free to post them in the — we’ll be happy to help you out.
Code of Conduct
Preamble
Community was created to foster an open, innovative and inclusive community around open source & open standards. To clarify expected behaviour in our communities we have adopted the Contributor Covenant. This code of conduct has been adopted by many other open-source communities and we feel it expresses our values well.
Our Pledge
We as members, contributors, and leaders pledge to make participation in our community a harassment-free experience for everyone, regardless of age, body size, visible or invisible disability, ethnicity, sex characteristics, gender identity and expression, level of experience, education, socio-economic status, nationality, personal appearance, race, caste, colour, religion, or sexual identity and orientation.
We pledge to act and interact in ways that contribute to an open, welcoming, diverse, inclusive, and healthy community.
Our Standards
Examples of behaviour that contributes to a positive environment for our community include:
Demonstrating empathy and kindness toward other people
Being respectful of differing opinions, viewpoints, and experiences
Giving and gracefully accepting constructive feedback
Accepting responsibility and apologizing to those affected by our mistakes, and learning from the experience
Focusing on what is best not just for us as individuals, but for the overall community
Examples of unacceptable behaviour include:
The use of sexualized language or imagery, and sexual attention or advances of any kind
Trolling, insulting or derogatory comments, and personal or political attacks
Public or private harassment
Community leaders are responsible for clarifying and enforcing our standards of acceptable behaviour and will take appropriate and fair corrective action in response to any behaviour that they deem inappropriate, threatening, offensive, or harmful.
Community leaders have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, and will communicate reasons for moderation decisions when appropriate.
This Code of Conduct applies within all community spaces and also applies when an individual is officially representing the community in public spaces. Examples of representing our community include using an official e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event.
Instances of abusive, harassing, or otherwise, unacceptable behaviour may be reported to the community leaders responsible for enforcement at . All complaints will be reviewed and investigated promptly and fairly.
All community leaders are obligated to respect the privacy and security of the reporter of any incident.
Community leaders will follow these Community Impact Guidelines in determining the consequences for any action they deem in violation of this Code of Conduct:
Community Impact: Use of inappropriate language or other behaviour deemed unprofessional or unwelcome in the community.
Consequence: A private, written warning from community leaders, providing clarity around the nature of the violation and an explanation of why the behaviour was inappropriate. A public apology may be requested.
Community Impact: A violation through a single incident or series of actions.
Consequence: A warning with consequences for continued behaviour. No interaction with the people involved, including unsolicited interaction with those enforcing the Code of Conduct, for a specified period of time. This includes avoiding interactions in community spaces as well as external channels like social media. Violating these terms may lead to a temporary or permanent ban.
Community Impact: A serious violation of community standards, including sustained inappropriate behaviour.
Consequence: A temporary ban from any sort of interaction or public communication with the community for a specified period of time. No public or private interaction with the people involved, including unsolicited interaction with those enforcing the Code of Conduct, is allowed during this period. Violating these terms may lead to a permanent ban.
Community Impact: Demonstrating a pattern of violation of community standards, including sustained inappropriate behaviour, harassment of an individual, or aggression toward or disparagement of classes of individuals.
Consequence: A permanent ban from any sort of public interaction within the community.
This Code of Conduct is adapted from the , version 2.1, available at .
Community Impact Guidelines were inspired by .
For answers to common questions about this code of conduct, see the FAQ at . Translations are available at .
Version 0.12.2
Release Version: 0.12.2
Release Type: Developer Release
Release Date: 23rd October, 2025
Overview
Inji Certify v0.12.2 focuses on enabling issuers with greater control and flexibility in managing their credential signing infrastructure, while also improving usability and operational stability.
This release introduces new issuer-facing APIs that allow seamless integration with external Certificate Authorities (CAs) through a complete CSR generation and signed certificate upload workflow. By orchestrating with Key Manager, Certify ensures that issuers can securely generate CSRs, validate and store CA-signed certificates, and immediately leverage them for VC signing, thereby expanding deployment capacity and supporting sovereign CA setups.
Alongside this core capability, the release also improves accessibility for external users by updating key documentation references and Postman collections to point to the collaboration environment, ensuring a smoother setup and integration experience. Additionally, database scripts now include the Shedlock table, resolving prior gaps and providing reliable distributed job scheduling for production deployments.
Together, these enhancements not only extend the functional capacity of Certify but also strengthen its readiness for large-scale, real-world integrations.
CSR & Certificate Management APIs – Certify now exposes APIs to generate CSRs via Key Manager for aphidand refid, download them, and upload externally signed certificates. Uploaded certificates are validated and securely stored, enabling their use in VC signing.
Updated Documentation Links – Postman collections and reference URLs have been updated to point to the collaboration environment, ensuring external users can easily test and integrate.
JIRA
Description
Below is the list of known issues related to the release v0.12.2. To access all known issues related to Inji Certify please click
JIRA
Description
Repositories
Tags
The following table outlines the tested and certified compatibility of 0.12.2 with other modules.
Module
Version (with tag links)
Version 0.10.1
Release Version: v0.10.1
Release Type: Developer Release
ReleaseDate: 3rd February, 2025
Overview
Inji Certify continues to innovate by integrating new features that enhance the product's interoperability and adaptability, addressing the growing demand for verifiable credential (VC) issuance on digital platforms. This release introduces support for Data Model 2.0 and enables SVG rendering. Additionally, we've improved the deployment process, making it easier for users to configure and deploy Certify with various data sources
Major Highlights
Local deployment using docker compose
Enabling local inji certify deployment via docker compose for easier setup and environment management with an externally deployed authentication setup like MOSIP's eSignet
Support for VC 2.0 Data Model:
Enabled Inji to generate credentials in the VC 2.0 format.
Introduced SVG templates for visually representing VC 2.0 credentials.
Implementation of Data Provider Plugin
Enabling inji certify to retreive data from different data sources using the data provider plugin. In this release the product support to interact with below 2 different data sources:
Postgres
ED25519 (2018 & 2020) VC Signing
Enhanced security with ED25519 Signature (2018 & 2020) signing.
Below is the list of bug fixes as part of the 0.10.1 release:
Below is the list of known issues. To read in detail and view all the topics related to Inji Certify please click
Repositories
Tags Released
The following table outlines the tested and certified compatibility of <release version> with other modules.
Module
Version(With tag links)
Claim 169 QR Code Support
Overview
Inji Mobile Wallet supports receiving and using Verifiable Credentials (VCs) that contain Claim-169formatted QR code blocks. These QR blocks are issued as CBOR Web Tokens (CWT) embedded inside the credential and encoded as Base64.
This feature enables secure, compact, and privacy-preserving QR sharing, especially suited for offline and quick verification scenarios.
The wallet can:
Download credentials containing embedded Claim-169 QR blocks
Store and render QR payloads securely
Allow users to present QR-based identity data when required
Perform validation checks for size, structure, and format
QR blocks follow standards based on:
IANARegistry
CBOR (Concise Binary Object Representation)
CWT (CBOR Web Token)
A Claim-169-enabled VC may include:
Each QR block contains CBOR data with attributes such as:
Claim ID
Attribute
Claim-169 QR codes allow identity data to be shared without internet connectivity, enabling fast in-person verification.
Each QR can contain only the required attributes, reducing unnecessary disclosure of personal data.
Users can present identity data by simply displaying a QR code for scanning.
Claim-169 QR support applies to Verifiable Credentials that:
Contain embedded CWT QR blocks
Include Base64-encoded Claim-169 QR fields
Are issued via supported issuance flows
Supported VC formats include:
W3C Verifiable Credentials (JSON-LD 1.1 / 2.0)
Step 1: Credential Download
When a credential containing QR blocks is downloaded:
Wallet extracts QR fields (qr1, qr2, etc.)
Decodes Base64 → obtains CWT
Performs optional validation:
Step 2: Viewing QR Codes
When the user opens the credential:
Wallet detects available QR blocks
Converts CBOR payload → QR image
Displays QR with issuer-defined label (e.g., Age Verification)
If decoding fails or QR exceeds size limits, an error message is shown.
Step 3: Sharing QR Codes
For verifier interactions:
User selects the required QR code
Wallet displays QR on screen
Verifier scans the QR directly
No additional data leaves the device beyond what is encoded in the QR.
A single credential may contain multiple QR codes, for example:
Age Verification
Address Verification
Identity Proof
Note: While Inji Certify supports the design for issuing multiple QR codes, Inji Wallet currently does not support multiple QR codes for Claim-169 credentials.
Signature verification of CWT payloads may vary by platform.
Requires issuer configuration to provide QR labels and supported attributes.
Only Base64-encoded CWT QR blocks are supported in the current release.
Claim 169 QR Code Support: To learn how this QR code is issued and works with Inji Mobile Wallet, please click to understand its issuance.
Tuvali API Documentation
Tuvali module is based on the OpenID for Verifiable Presentations over BLE implementation to support sending vc/vp using Bluetooth Low Energy local channel. The below sections explains the APIs of the library in detail.
Firstly, for establishing the secured connection over BLE the connection params which include name and key needs to be exchanged between the two devices. This exchange of parameters can be accomplished but is not limited to by using a QR code.
For example, use a QR code generator to visually display params and a QR code scanner to get params. A mobile app that displays a QR code can act as an Verifier by including its connection params as data in the QR code and another device can act as Wallet which scans the QR code, it can extract the connection parameters and initiate a BLE connection with the advertising device.
URI Exchange and Establishing Connection
Verifier
The Verifier device generates a URI using the startAdvertisement() method and displays it as a QR code. Once the advertisement starts, the Verifier continuously advertises with a payload derived from the URI.
URI structure can be found in the . Currently the library doesnot support iOS as a verifier.But it can act as a wallet for android verifier.
The device that scans the QR code will extract the connection parameters from the QR code and set its connection parameters using the startConnection() method :
The connection param is a URI with a name & a key. The name is the client's name & the key is the verfier's public key.
The key part of the data is the same data that will be advertised by the verifier device but in hex-encoded form.
E.g: OVPMOSIP://connect:?name=<>&key=<verifier public key>
Once the connection is established, wallet app can send the data in a secured way to the Verifier. Note: At this moment, we currently support data transfer from Wallet to Verifier only.
and verifier app can acknowledge it.
The following sequence of actions should be performed to transfer data over BLE:
Verifier must start advertising by calling verifier.startAdvertisement(name) method
Subscribe to events using wallet.handleDataEvents
Initiate the secure connection using wallet.startConnection(uri)
Data received from other apps via BLE can be subscribed to using: Tuvali sends multiple events to propagate connection status, received data etc. These events can be subscribed to by calling:
on Wallet:
on Verifier:
Here are the different types of events that can be received
Events which are emitted by both Wallet and Verifier
ConnectedEvent
on BLE connection getting established between Wallet and Verifier
SecureChannelEstablishedEvent
DataSentEvent
on completion of Data transfer from the Wallet Side
VerificationStatusReceivedEvent
DataReceivedEvent
on receiving data from the Wallet Side
The device on which app is running can destroy the connection by calling disconnect() method:
The below diagram explains the series of handshakes between the Verifier and the Wallet device.
Version 0.11.0
Release Version: v0.11.0
Release Type: Developer Release
ReleaseDate: 2nd May, 2025
Inji Certify v0.11.0 brings major enhancements focused on improving security, standards compliance, and interoperability in verifiable credential issuance. This release expands cryptographic support, simplifies deployment, strengthens identity integration, and aligns closely with OpenID4VC and OpenID4VCI specifications. It also introduces initial support for third-party wallets and identity platforms, making Inji Certify more versatile and extensible in digital ID ecosystems.
Keycloak Integration: Seamless integration with Keycloak has been introduced, providing secure, standards-based authentication aor verifiable credential issuance.
Inji Mobile - Collab Guide
Welcome to the Inji Mobile Guide tailored specifically for our Collab Environment! This guide is designed to assist you in setting up and configuring the wallet app in our sandbox Collab environment. By following the steps outlined in this guide, you will be able to smoothly install and utilize the Inji Wallet app, empowering you to explore its features and functionalities effectively. Whether you're a Developer, System Integrator, or an enthusiast eager to dive into the world of digital identity, this guide will provide you with the necessary information to get started with Inji Wallet in our environment. Let's begin this journey of seamless setup and exploration!
Before you start with setting up Inji Mobile, ensure you have the following in place.
Inji Wallet APK File:
OpenID4VP
This library enables consumer applications (mobile wallet) to share users Verifiable Credentials with Verifiers who request them online. It adheres to the OpenID4VP draft version 23, which outlines the standards for requesting and presenting Verifiable Credentials.
Receives the Verifier's Authorization Request sent by the consumer application (mobile wallet).
Validates the received Authorization Request to check if the required details are present or not, and then returns the Authorization Request to the consumer application once all the validations are successful.
PixelPass
PixelPass is a versatile and easy-to-use library designed to simplify working with QR codes and data compression. It allows you to generate QR codes from any given data with just a single function. If you’re working with JSON, PixelPass can take that data, compress it, and convert it into a compact format using CBOR encoding, making it smaller and more efficient for QR code generation. The library can also decode this compressed data, turning CBOR back into the original JSON format. Additionally, for more complex use cases, PixelPass offers the ability to map your JSON data to a specific structure, compress it, and encode it into CBOR. Later, you can also reverse this process, decoding the CBOR back into its mapped JSON structure. With these capabilities, PixelPass makes managing, compressing, and encoding data for QR codes easy and efficient.
PixelPass has NPM, Kotlin, Swift and Java artifacts available.
Compresses data using zlib with the highest compression level (level 9).
BLE Verifier
This is the module built for verifiers to receive VC via BLE. This is a wrapper built on Tuvali with simplified APIs.
Add a dependency in package.json
Publishing npm module is WIP. Once it's published, it can be integrated as any other npm module.
Sunbird RC Certify Plugin: This plugin interacts with the Sunbird RC registry, a platform for managing learning resources and learner data. It retrieves relevant data from the Sunbird RC registry, such as academic records and certifications, and generates and issues VCs based on this retrieved information.
Data URL
format: data:image/imageformat base64 encoded image
eg: data:image/jpeg
vcImage
The image that is given in the VC
Data URL
format: data:image/imageformat base64 encoded image
eg: data:image/jpeg
Docker Compose is a tool for defining and running multi-container applications. It is the key to unlocking a streamlined and efficient development and deployment experience.
Helm helps you manage Kubernetes applications - helps define, install, and upgrade even the most complex Kubernetes application. Charts are easy to create, version, share, and publish — so start using Helm and stop the copy-and-paste.
Selective disclosure for privacy-preserving data sharing.
Offline verification via Bluetooth Low Energy (BLE).
OpenID4VP-based interoperability with verifiers.
Multi-issuer and multi-credential handling.
Highlights use cases in travel, employment, public service delivery and many more.
Showcases accessibility for users without smartphones or in assisted-use environments.
Credential Management: The workshop covers how credentials are stored, secured, and validated in both Web and Wallets, emphasizing security and compliance with standards.
Real-World Deployment and Integration: It discusses the roles of issuers and service providers in real-world deployments, the use of blockchain for security, and the potential for running AI agents for selective disclosure.
Docker Compose Setup: A Docker environment is set up to run the database, Inji Certify, Nginx, and Inji Web.
Demonstration: A farmer ID is entered, authenticated, and a verifiable credential is issued based on the retrieved data.
API Interactions: The session explains how Inji Wallet interacts with various APIs, including those for fetching issuer lists, obtaining access tokens, and binding wallets to relying parties.
Configuration: The webinar discusses the configuration aspects, such as setting up issuer information, defining VC templates, and configuring the connection to eSignet.
Development and Integration: The presentation provides insights into the development process, including the use of React Native for the mobile app, the integration of native modules, and the management of data storage.
Inji: A platform for managing the lifecycle of verifiable credentials.
Real-World Impact: Understand how eSignet and Inji provide secure and efficient digital experiences.
Inji Certify
Product Overview
Local Setup & Deployment using Docker Compose
Technical Deep Dive - Verifiable Credential Issuance
Inji Mobile Wallet
Product Overview
Inji Web Wallet
Product Overview
Local Setup Guide
Mimoto Setup
Inji Verify
Product Overview - Your Gateway to Trusted Verifiable Credential Verification
Technical Deep Dive
Inji Ecosystem Workshop
Note: The video resources listed below are earlier recordings from webinars held in 2024. While they are not being archived at this time, they remain available as they provide useful context and practical demonstrations that may still benefit viewers.
1. Comprehensive demonstration on Digital Identity Management and Credential Integration
2. Inji Certify Credential Issuance Workshop
3. Inji A Technical Deep Dive
4. Unlocking the Value of Integrations with Inji and eSignet
Database Script Correction – Shedlock table has been added to DB scripts to support distributed job scheduling and ensure reliable execution in production setups.
Enabled for Interoperability and Integration: Inji Certify now supports seamless interoperability with digital wallets that adhere to the OpenID for Verifiable Credentials (OpenID4VC) specification. Having gone through rigorous testing, Inji Certify now assures and attests that it can integrate effortlessly with any wallet designed to be interoperable and compliant with OpenID4VC standards and thereby enhancing its versatility and adoption in diverse ecosystems.
Expanded Cryptographic Algorithm Support in Inji Certify
Inji Certify now offers enhanced cryptographic flexibility through support for additional signing algorithms:
ECC K1 2019 Key Support: Inji Certify supports signing and verification using ECC K1 2019 keys, enabling compatibility with a broader range of secure systems and ensuring robust security for verifiable credentials.
Ed25519 Signing (2018 & 2020): Verifiable credential requests can now be signed using Ed25519 keys, compliant with both 2018 and 2020 specifications. This enhancement ensures interoperability with diverse ecosystems and aligns with modern cryptographic standards.
eSignet v1.5.1 Compatibility: Full support for eSignet 1.5.1.
OpenID4VCI Compliance Improvements: Docker Compose now supports redirection of the .well-known endpoint as per spec.
Simplified Setup: Dependency on Artifactory removed for streamlined deployment.
Improved cryptographic flexibility through support of ECC K1 2019 and Ed25519 key types.
Enhanced ecosystem integration by supporting Keycloak and eSignet 1.5.1.
Support for Talaos and Altme wallets expands adoption in OpenID4VC ecosystems.
Alignments made with OpenID4VCI specs to improve compatibility and standard adherence.
JIRA
Description
In docker compose, jar is still copied from one place to another place to continue with VC download
Spec compliance - Issues
Incorrect Required Claims in VC Issuance
Known Issues
Below is the list of known issues. To read in detail and view all the topics related to Inji Certify please click here
JIRA
Description
Esignet Oauth API is failing intermittently
The MOSIP UIN VC's created from reg-client are not verifiable from INJI-verify
Repositories
Tags Released
inji-certify
digital-credential-plugins
inji-config
The following table outlines the tested and certified compatibility of <release version> with other modules.
If you are using an Android smartphone, click here to get the Inji Mobile apk file for installation.
Transfer the apk file onto the smartphone on which it is to be installed.
Inji Wallet Test Flight Access:
If you are using an iOS device, click here get access to the Inji Wallet app on test flight.
Ensure you have get the test flight application from your app store.
UIN Credentials:
Issuance of UIN (Unique identification number) as a demo credential will allow you to explore Inji Mobile's capabilities and experience seamless VC sharing firsthand.
Now you can self generate your own UIN Credential using the Collab environment.
Click on the Get UIN button located at the top-right corner of the page. This will open the , Alternatively, you can simply click on this to self register. You need to duly fill the self registration form.
On successful registration the UIN is sent to you over the email you used for registration, For more details you follow the .
Note: Please use 111111 as the OTP, for any OTP based feature in Collab environment.
For sample Insurance Credentials, please provide the below details in the eSignet authentication page:
Policy id: 7070
Name: aswin
DOB: 19/02/2025
To effectively set up the Inji Mobile app and manage Verifiable Credentials (VCs), follow these detailed steps:
Step 1: Install the Inji Mobile App
For a step-by-step guide on how to install the Inji Mobile application, click here.
You can visit this section for more detailed instructions in the guide.
Step 2: Install the Inji Mobile App - To be used as Verifier App
Follow the same installation process mentioned above in step 1.
Setup another instance of the Inji Mobile app on an android device, which can serve as the Verifier app.
Step 3: Download National ID VC Using UIN/VID
Download your credential (VC) onto the app by using your demo UIN.
To learn how to download VCs using the Unique Identification Number (UIN) or Virtual ID (VID) feature, click here. Refer to the section titled Download credentials using UIN / VID feature in the guide .
Step 4: Download Insurance Credentials Using Policy Details
Refer to the sample insurance credentials under 'Prerequisites' section.
Click here for detailed information about Inji Wallet.
By following these instructions, you will be equipped to seamlessly set up the Inji Wallet application and effectively share your Verifiable Credentials.
If you require any assistance or encounter any issues during the testing and integration process, kindly reach out to us through the support mechanism provided below.
Provide a detailed description about the support you require or provide detailed information about the issue you have encountered, including steps to reproduce, error messages, logs and any other relevant details.
Receives the list of Verifiable Credentials from the consumer application which are selected by the consumer application end-user based on the credentials requested as part of Verifier Authorization request.
Constructs the vp_token without proof section and sends it back to the consumer application for generating Json Web Signature (JWS).
Receives the generated signature along with the other details and generates vp_token with proof section & presentation_submission.
Sends a POST request with generated vp_token and presentation_submission to the received Verifier's response_uri endpoint.
Below sections details on the steps for integrating the Kotlin and Swift packages into the app. Below sections details on the steps for integrating the Kotlin and Swift packages into the app.
Supported features
Feature
Supported values
Device flow
Cross device flow, Same device flow (only direct_post and direct_post.jwt supported)
Client id scheme
pre-registered, redirect_uri, did
Signed authorization request verification algorithms
In your swift application go to file > add package dependency > add the https://github.com/inji/inji-openid4vp-ios-swift in git search bar > add package.
Import the library and use.
The OpenID4VP library provides the following APIs for implementing the OpenID4VP flow:
API Method
Use Case
authenticateVerifier
Validate and decode the verifier's authorization request
constructUnsignedVPToken
Create unsigned VP tokens (V1 API) from verifiable credentials for signing by the wallet
constructUnsignedVPTokenV2
Create flattened list of unsigned VP tokens (V2 API) with signing metadata for simplified workflow
For detailed API reference including parameters, response structures, examples, and exceptions, refer to the Kotlin API Reference or Swift API Reference accordingly.
The below diagram shows the interactions between Inji Wallet, Verifier and OpenID4VP library.
Note: Currently, the vp_token uses the Ed25519Signature2020 type for digital signatures.
OpenID4VP - Online Sharing
Library Functionalities: Processing the Request from Decoding to Verifier Response
For JSON data, applies CBOR encoding/decoding to achieve additional size reduction.
With JSON and a Mapper provided, maps the JSON and then performs CBOR encoding/decoding to further shrink the data size.
As a node project:
npm i @mosip/pixelpass
As a Kotlin/Java dependency:
Gradle
implementation("io.mosip:pixelpass:0.5.0")
Maven
To include PixelPass in your Swift project, follow the below steps:
Clone the PixelPass library locally.
Create a new Swift project.
Add package dependency: PixelPass
Below are the APIs provided by the PixelPass library:
generateQRCode( data, ecc , header )
The generateQRCode takes a data, ECC (Error correction level) which when not passed defaults to L and header which defaults to empty string if not passed. Returns a base64 encoded PNG image.
data - Data needs to be compressed and encoded.
ecc - Error Correction Level for the QR generated. defaults to "L".
header - Data header need to be prepend to identify the encoded data. defaults to "".
generateQRData( data, header )
The generateQRData takes a valid JSON string and a header which when not passed defaults to an empty string. This API will return a base45 encoded string which is Compressed > CBOR Encoded > Base45 Encoded.
data - Data needs to be compressed and encoded.
header - Data header need to be prepend to identify the encoded data. defaults to "".
decode( data )
The decode will take a string as parameter and gives us decoded JSON string which is Base45 Decoded > CBOR Decoded > Decompressed.
data - Data needs to be decoded and decompressed without header.
decodeBinary( data )
The decodeBinary will take a UInt8ByteArray as parameter and gives us unzipped string. Currently only zip binary data is only supported.
data - Data needs to be decoded and decompressed without header.
getMappedData( jsonData, mapper, cborEnable )
The getMappedData takes 3 arguments a JSON and a map with which we will be creating a new map with keys and values mapped based on the mapper. The third parameter is an optional value to enable or disable CBOR encoding on the mapped data.
jsonData - A JSON data.
mapper - A Map which is used to map with the JSON.
cborEnable - A Boolean which is used to enable or disable CBOR encoding on mapped data. Defaults to false if not provided.
The example of a converted map would look like, { "1": "207", "2": "Jhon", "3": "Honay"}
decodeMappedData( data, mapper )
The decodeMappedData takes 2 arguments a string which is CBOR Encoded or a mapped JSON and a map with which we will be creating a JSON by mapping the keys and values. If the data provided is CBOR encoded string the API will do a CBOR decode first ad then proceed with re-mapping the data.
data - A CBOREncoded string or a mapped JSON.
mapper - A Map which is used to map with the JSON.
The example of the returned JSON would look like, {"name": "Jhon", "id": "207", "l_name": "Honay"}
Shall you encounter any errors while using the APIs, please refer to the below:
Cannot read properties of null (reading 'length') - This error denotes that the string passed to encode is null.
Cannot read properties of undefined (reading 'length') - This error denotes that the string passed to encode is undefined.
byteArrayArg is null or undefined. - This error denotes that the string passed to encode is null or undefined.
utf8StringArg is null or undefined. - This error denotes that the string passed to decode is null or undefined.
utf8StringArg has incorrect length. - This error denotes that the string passed to decode is of invalid length.
Invalid character at position X. - This error denotes that the string passed to decode is invalid with an unknown character then base45 character set. Also denotes the invalid character position.
incorrect data check - This error denotes that the string passed to decode is invalid.
The below diagram shows how Inji Wallet utilises PixelPass library.
The below diagram shows how Inji Verify utilises PixelPass library.
import { generateQRCode } from '@mosip/pixelpass';
const data = "Hello";
const qrCode = generateQRCode(data, ecc, header);
// ecc is Error Correction Level for the QR generated. defaults to "L".
// header defaults to empty string if not passed.
import { generateQRData } from '@mosip/pixelpass';
const jsonString = "{\"name\":\"Steve\",\"id\":\"1\",\"l_name\":\"jobs\"}";
const header = "jsonstring";
const encodedCBORData = generateQRData(jsonString, header);
// header defaults to empty string if not passed.
The following APIs are exposed to instantiate, start the transfer and stop the transfer
This API initializes the BLE module using the provided configuration. This initialization process allows for the sharing of configuration information for advertisement purposes. A new instance is created with each initialization.
It is recommended to use one instance per session and to initialize a new instance for each subsequent session.
The configuration passed to the constructor includes a parameter called deviceName. This name is included in the advertisement payload during the BLE advertisement. It is important to note that this field has a character limit of 11 characters.
Signature
Parameters
Name
Description
ConfigOptions
configOptions
device name used during advertisement
deviceName is the parameter
This API starts with advertisement for establishing the connection
Internally interacts with Tuvali to start advertisement
Update state to Advertising
Once the secure connection is established, navigate through to state to complete the transfer
Signature
This API has to be called explicitly to stop the connection
Connection can be stopped either after successful transfer or user wants to cancel the transfer
Once the connection is disconnected, state is updated to Idle
Signature
Idle
Advertising
Connected
Secure Connection Established
Requested
Received
Error
Disconnected
Transitions between states is shown below:
State diagram
Note: If either the sender or receiver decides to cancel the transfer at any stage, the state will transition to Disconnected and become Idle as a result.
Verifier App integration
Repository
Installation
API Specification
constructor(configOptions: ConfigOptions) {
Initialise verifier service with provided configuration
}
ConfigOptions {
deviceName: string;
}
startTransfer() {
Start Advertisement
Interact with tuvali to start advertisement
update state to Advertising
}
stopTransfer() {
disconnect the connection
update state to Idle
}
Constructor for initialization
API to start transfer
API to stop transfer
Types of states supported
Inji Wallet integration workflow with BLE Verifier SDK and Face Match SDK
Issuing VC with QR Code
Overview
The QR Code Embedded Verifiable Credential feature enhances the usability and privacy of digital identity by enabling Inji Certify to generate Verifiable Credentials (VCs) with embedded QR codes containing selectively disclosed identity attributes.
Each QR code encapsulates identity data encoded as a CBOR Web Token (CWT), aligned with Claim 169 specifications. This allows verifiers to scan a QR code and validate only the required attributes without accessing the complete Personally Identifiable Information (PII).
This feature is aligned with the W3C Verifiable Credentials Data Model and supports interoperable, privacy-preserving verification using standardized QR encoding mechanisms.
Why This Feature Matters
QR Code Embedded VC brings several advantages:
Privacy by Design: Enables selective disclosure, ensuring only required attributes are shared.
Improved User Experience: Simplifies verification through QR scanning without full credential sharing.
Offline Verification Support: QR codes enable verification even in low-connectivity environments.
Standards Compliance: Aligns with , CBOR, and CWT specifications.
Flexible Configuration: Issuers can define multiple QR codes with different attribute sets.
The following sequence describes how Inji Certify generates a Verifiable Credential with embedded QR codes.
During VC type onboarding, the issuer configures:
Number of QR codes
Attributes included in each QR
Label or purpose of each QR (e.g., Age Verification, Identity Verification)
These configurations are stored in the system and used during VC generation.
The wallet initiates a VC download request.
Certify:
Validates the request and authentication
Identifies the VC configuration, including QR settings
Certify retrieves identity data through the data provider plugin.
If required:
Face image is compressed and optimized
Converted into Base64 format for embedding
Based on configuration:
Certify selects the required attributes for each QR
Prepares structured data for QR generation
The data is passed for QR encoding.
The QR data is processed to:
Map attributes to Claim 169 numeric keys
Convert data into CBOR format
Encode the payload for secure transport
The encoded QR payload is:
Enriched with metadata such as issuer and expiry
Signed using the issuer’s configured algorithm
Converted into a CWT (CBOR Web Token)
Certify constructs the Verifiable Credential by:
Embedding QR codes (CWT values)
Adding identity attributes and metadata
Applying the configured template
The complete VC is digitally signed to ensure integrity and authenticity.
Supported formats include:
JSON-LD (W3C VC)
mDoc (ISO standards)
SD-JWT
JWT VC
The signed VC is sent to the wallet.
The resident can:
Store the VC
Use embedded QR codes for verification
Refer to the architecture and sequence diagrams for detailed flow of QR data preparation, encoding, signing, and embedding within the VC.
Selective Disclosure: Only configured attributes are shared via QR
Data Integrity: QR payload is signed as a CWT
Key Security: Private keys are securely managed
Supports embedding multiple QR codes in a single VC
Each QR represents a specific verification purpose
QR payload follows Claim 169 mapping
Attributes are mapped to numeric identifiers as per IANA registry
Issuers can define:
Attributes per QR
Attribute order
QR labels
Supports embedding biometric data (e.g., face image)
Image is compressed and Base64 encoded
QR version supported up to 23
Face image size should be within configured limits (recommended <1KB)
Aspect
Requirement
Revocation validation via QR is not supported
Claim 169 currently supports only English
Mapping of custom fields outside Claim 169 requires external handling
Offline mapping resolution is dependent on external mechanisms
Please refer to the relevant for detailed configuration, policy setup, and API‑level implementation details.
Test Report
Testing Scope
The scope of testing is to verify fitment to the specification from the perspective of
Functionality
Deployability
Configurability
Customizability
Verification is performed not only from the end user perspective but also from the System Integrator (SI) point of view. Hence Configurability and Extensibility of the software are also assessed. This ensures the readiness of software for use in multiple countries. Since MOSIP is an “API First” product platform.
The testing scope has been focused on the following features:
Docker compose testing for Insurance and Mock ID use case
Inji certify - Insurance use case using namespace
Inji certify - Mock IDA use case using namespace
Persona based approach has been adopted to perform the IV&V, by simulating test scenarios that resemble a real-time implementation.
A Persona is a fictional character/user profile created to represent a user type that might use a product/or a service in a similar way. Persona based testing is a software testing technique that puts software testers in the customer's shoes, assesses their needs from the software, and thereby determines use cases/scenarios that the customers will execute. The persona's needs may be addressed through any of the following.
Functionality
Deployability
Configurability
Customizability
The verification methods may differ based on how the need was addressed.
Verification is performed on configurations as mentioned below
Default configuration
English
Below are the test metrics by performing functional testing. The process followed was black box testing which based its test cases on the specifications of the software component under test. The functional test was performed in combination with individual module testing as well as integration testing. Test data were prepared in line with the user stories. Expected results were monitored by examining the user interface. The coverage includes GUI testing, System testing, End-To-End flows across multiple configurations. The testing cycle included the simulation of multiple identity schema and respective UI schema configurations.
Total
Passed
Failed
NA
Test Rate: 100%, With Pass Rate: 97% and Fail Rate: 3%
Below are the detailed test metrics by performing manual/automation testing. The project metrics are derived from Defect density, Test coverage, Test execution coverage, test tracking, and efficiency.
The various metrics that assist in test tracking and efficiency are as follows:
● Passed Test Cases Coverage: It measures the percentage of passed test cases. (Number of passed tests / Total number of tests executed) x 100
● Failed Test Case Coverage: It measures the percentage of all the failed test cases. (Number of failed tests / Total number of test cases executed) x 100
Module/Repo
Image
POM version
Dependent artifactID
Comments
The Github link for the xls file is
Version 0.9.1
Release Name: Inji Certify 0.9.1 (Patch)
Support: Developer Release
Release Date: 3rd October, 2024
Overview
This patch release 0.9.1 for Inji Certify focuses on upgrading critical components to ensure compatibility and enhanced performance across various plugins. The primary updates include upgrading the eSignet version to 1.4.1, the OIDC-UI pod version to 1.4.1, and now certify plugins are available as 0.2.1-SNAPSHOT. Additionally, the release introduces changes to the Artifactory configuration, ensuring seamless integration of Certify plugins for continued reliability.
Changes and Upgrades:
eSignet Version Upgrade:
The eSignet version has been upgraded to 1.4.1 for compatibility with different Certify plugins.
OIDC-UI Pod Version Bump:
The OIDC-UI pod version has been upgraded to 1.4.1.
Artifactory Changes:
The Artifactory being pointed to by the config map now comes from the Artifactory-ref-impl branch.
This will ensure the correct dependency versions of the Artifactory.
For detailed steps click here to view the file.
Setup: Configure InjiWeb and Mimoto in your local environment.
Issuer Configuration: Add an issuer in Mimoto with the authorization_endpoint, credential_endpoint, and .well-known properties pointing to the installed eSignet and Certify services.
Private Key Addition: Insert the private key from the OIDC client created in eSignet into the .p12 file in Mimoto.
Repositories
Tags: Released/Dependent
The following table outlines the tested and certified compatibility of Inji Certify 0.9.0 with other modules.
Module
Version
Below is the list of known issues. To read in detail and view all the topics related to Inji Certify please click .
Jira ID
Description
GenderMag
The GenderMag Methodology aims to analyze and mitigate gender biases in users’ problem-solving interactions with software. It underscores the importance of accounting for gender differences in human-computer interaction (HCI) during the software design process.
Process
We identified two personas based on their familiarity with technology and their ability to embrace technological progress. The personas are:
Abi, who is either Abigail or Abishek, is 45 years old. She works as a homemaker, is literate, but not very tech- savvy. Her internet connectivity is moderate, and she does not have a personal phone.
Test Report
The scope of testing is to verify fitment to the specification from the perspective of:
Functionality
Deployability
Configurability
Version 0.9.0
Release Name: Inji Certify 0.9.0
Support: Developer Release
Release Date: 22nd August, 2024
Inji Certify continues to innovate in the realm of verifiable credentials (VCs) with the release of version 0.9.0. This update introduces significant enhancements, improving the platform's flexibility, scalability, and ease of use. Designed to empower organizations to issue and manage VCs securely, Inji Certify 0.9.0 further strengthens its integration capabilities. With these new features, users can expect a more streamlined experience in credential issuance and management, ensuring compliance with industry standards while offering robust data control. Support for various plugins and microservices, allowing organizations to tailor the platform to their specific needs and existing systems.
Overview
Inji Mobile isn't just a wallet – it’s a gateway to digital trust, empowering every individual to carry their identity with dignity, privacy, and control.
— Inspired by the vision of open, inclusive digital identity ecosystems.
Inji Mobile is an open-source mobile wallet built to securely receive, store, manage, and share Verifiable Credentials (VCs), whether online or offline. Designed in line with global standards such as W3C VC Data Model, OpenID4VCI, OpenID4VP, ISO 18013-5 (mDL), and IETF SD-JWT, Inji Mobile enables individuals to carry digital identity, documents, certificates, etc., with full privacy, consent, and control.
Whether you're a citizen accessing government services, a developer building digital identity applications, or a verifier validating credentials, Inji Mobile offers a trusted, standards-compliant foundation for secure and privacy-preserving interactions. As a reference implementation, Inji Mobile is both a ready-to-use wallet and a modular solution; its SDKs, libraries, and components can be used independently or bundled into custom apps, depending on the adopter’s needs and specific use cases.
Workflow
This workflow describes how Inji Wallet downloads a Verifiable Credential (VC) from an issuing authority using the OpenID4VCI protocol.
Actors:
Inji Wallet: Orchestrates the process, interacts with VCI Client and Secure Keystore.
Secure Keystore: Signs cryptographic proofs.
Building Verifiable Credentials Wallet with Inji Libraries
This guide provides step-by-step documentation for building a Kotlin-based verifiable credential wallet from scratch using Inji stack libraries. The purpose of this guide is to demonstrate how developers can leverage the Inji ecosystem to securely download, verify, store, and present verifiable credentials (VCs). The guide is currently focused on Android-based implementations, but all the Inji libraries are also available in Swift for iOS.
This guide is aimed at developers who want to either create a custom wallet or enhance an existing application to support VC-based digital identity functionality.
Interoperability-First
Complies with major standards: OpenID4VCI, OpenID4VP, W3C Data Model, IETF SD-JWT, JWT VC, and ISO mDL/mDoc.
Offline Functionality
BLE-based VC sharing and offline face authentication, ensuring usability even in no-connectivity environments.
User Sovereignty
Credentials are held entirely by the user, with granular consent-driven sharing.
Modular Security Architecture
Combines robust cryptography with flexible authentication mechanisms and strong privacy guarantees.
Cross-Platform Native Implementation
Built in React Native with Kotlin (Android) and Swift (iOS) integrations for native performance.
Inji Wallet is designed for interoperability and flexibility by supporting a wide range of credential formats:
W3C Verifiable Credentials (JSON-LD VCs) Data Model 1.1 and Data Model 2.0
Standards-based credential format is widely adopted across ecosystems.
Suitable for general-purpose credential issuance and verification.
ISO 18013-5 (mDL)
Mobile Driving License and Mobile Document specification.
Supports use cases like identity verification in transport, law enforcement, and service access.
IETF SD-JWT
IETFSD-JWT Verifiable Credentials: Enables holders to download and share credentials in IETF SD-JWT format. This allows users to share only the necessary attributes while keeping other data private, ensuring privacy-preserving credential sharing.
Allows users to share only the required claims with verifiers via the OpenIDVP flow, where these selectively disclosable claims can be shared as per the user's need.
This multi-format support allows Inji Wallet to work seamlessly across different ecosystems, ensuring compatibility, security, and user privacy.
Digitally signed credentials from trusted issuers
Encrypted and integrity-verified local storage.
Supports multiple credential formats including W3C JSON-LD VCs, ISO mDL/mDoc, and IETF SD-JWT.
Online presentation using QR-code SSO and OpenID4VP
Supports same-device and cross-device interactions
Offline face match verification to authenticate the user during VC sharing
Device-level biometric/passcode unlock for app access
Tap-to-login via QR code scanning
Smart redirection to service post-verification
Works across any OpenID4VP-compliant verifier
Download credentials via pre-authorized flow
Supports various credential types: national IDs, driver's licenses, health cards, academic degrees, etc.
Inji Mobile supports Selective Disclosure JWT (SD-JWT) credentials.
Enables privacy-preserving presentations, where users can share only the specific attributes required by a verifier, rather than the entire credential.
Fully compliant with the OpenID for Verifiable Presentations Draft 23 (OpenID4VP) specification for SD-JWT.
Improves compatibility with ecosystems adopting SD-JWT and OpenID-based verifiable presentation.
Introduces support for SVG templates via the Inji VC Renderer library.
Allows credentials to be rendered in a visually rich, scalable, and customizable format.
Enables dynamic layouts, inclusion of logos, photos, and design elements, while staying aligned with the W3C VC Data Model 2.0.
Improves on-screen display and print-ready credential rendering experience.
Automatically checks if a card is still valid by reading the issuer’s revocation list whenever a credential is downloaded or refreshed.
Uses W3C Bitstring Status List, ensuring global, standards-based detection of revoked.
Shows clear status indicators (Valid, Revoked, Pending) so users immediately know whether a card can be safely shared.
Supports manual status checks
Inji Mobile supports Presentation During Issuance (PDI) a secure flow where users can prove eligibility using an existing credential before receiving a new one.
Instead of repeating identity checks or submitting documents again, the wallet can present a Verifiable Presentation (VP) of an already stored credential to the issuer during the issuance process.
Example: Present your National ID credential → Receive a Driving License or Health Card
Receive new credentials faster without repeating onboarding steps
Reuse trusted credentials already stored in the wallet
Approve exactly what information is shared before issuance
Inji Mobile supports Claim-169 QR Codes, a standardized QR format used to support receiving and using Verifiable Credentials (VCs) that contain Claim 169–formatted QR code blocks, issued as CBOR-based CWT (CBOR Web Tokens) inside the credential.
This ensures secure, compact, and privacy-preserving QR sharing ideally suited for offline or quick verification scenarios.
The goal of this feature is to allow the wallet to:
Download credentials containing embedded Claim 169 QR blocks
Store and render these QR blocks for display
Allow users to present the QR-based identity data when required
Ensure proper validation and security checks (size, format, signature, structure)
Credential Download
Users can obtain VCs using their unique identifiers (UIN/VID or other methods), authenticate via OTP, and securely store them.
Credential Storage
All credentials are stored encrypted, verified using the issuer’s digital signature, and integrity is validated via a unique HASH. In addition to standard VC formats, Inji Mobile supports JSON-LD, ISO mDL/mDoc and IETF SD-JWT credentials, ensuring the privacy-preserving selective disclosure of claims during verification.
Sharing Credentials
Users can share credentials:
Offline using BLE
Online by scanning QR codes via OpenID4VP
Simple Upload and Scan of QR codes
Face Verification
Optional offline face authentication ensures the right holder is presenting credentials during in-person verifications.
Consent & Privacy
Credential sharing is consent-based, giving users full control over what data is shared and with whom.
Additionally, it utilises eSignet APIs to enable seamless online login for users.
Inji Mobile is more than just a credential wallet; it’s a reference implementation for inclusive, offline-capable, standards-compliant digital identity. With full support for online and offline VC flows, strong cryptographic safeguards, and a user-first design, it provides a powerful tool for citizens, developers, and governments alike. Inji Mobile gives you the interoperable building blocks you need.
The updated Certify plugins are now available as 0.2.1-SNAPSHOT versions.
Verification: The configured issuer should now appear on the InjiWeb homepage, allowing you to download the credential.
Plugin Compatibility: For this release, ensure that the eSignet image version in Docker Compose (currently 1.4.1) is consistent with the Mock plugin dependencies in Artifactory. This alignment is crucial due to shared Redis cache dependencies resolving serialization issues.
Artifactory Server
Commons
Inji Certify : VC download is failing with signature alg (ES256) supported values mentioned in well-known response
Inji Certify : Response of Mock VC is having extra attribute with null value
Inji Certify : VC download is failing with credential type "LifeInsuranceCredential"
Inji Certify :Extra credential type is coming in VC response for insurance usecase
Inji Certify : Not able to download VC with few of the registries from InjiWeb, certify issuer
Tim, who is either Timothy or Timara, a 24-year-old financial consultant, is literate, tech-savvy, and boasts excellent internet connectivity. Additionally, he owns the latest phone.
Examine the feature, systematically walk through the process, assess their information handling, and pinpoint any problems.
During the walkthrough, we pinpointed inclusivity concerns in the Inji Wallet app’s user interface and experience. Subsequently, we took steps to mitigate these issues, aiming to eliminate digital entry barriers.
As part of Phase1, below P1 items are fixed in the v0.11.0-Inji Wallet release:
Sl No
Problem statement
Solution
Jira number
1
The term “scan” can be ambiguous because scanning a QR code within an app might result in a money transfer from a bank account. This perception could be influenced by cultural factors. Abi, instead of directly clicking on the “Scan” option, prefers to select her card and then look for a “Share” option. Unless external assistance is available, Abi will avoid using the “Scan” feature.
Without external assistance, unless there are instructions visibly posted on the wall, she might find it challenging to comprehend whether she needs to select the “scan” option.
The Scan Button in the Navigation Bar can now be referred to as “Share”.
2
As part of Phase2, below P1, P2 items are fixed in the v0.12.0 release of Inji Wallet:
Sl No
Problem Statement
Solution
Jira number
1
Screen name: Retrieve your UIN/VID on clicking link
It is confusing for Abi as she has to walk through a lot of steps to get her card. Though it is mentioned as AID, she would be happy but may / may not move forward as it is going to get UIN but not a card.
Update screen name to "Get your UIN/VID." instead of Retrieve your UIN/VID
2
What is GenderMag?
Customizability
Verification is performed not only from the end user perspective but also from the System Integrator (SI) point of view. Hence Configurability and Extensibility of the software is also assessed. This ensures readiness of software for use in multiple countries. Since MOSIP is an "API First" product platform.
Testing scope has been focused around the below features:
Docker compose testing for Mock Data Provider plugin (csv), Farmer use case - 1.1 & 2.0 VC
Inji certify - Insurance use case using namespace (VC issuance plugin) - 1.1 VC
Inji certify - Mock IDA use case using namespace (Data provider plugin(Postgres)) - 1.1 & 2.0 VC
Inji certify - MOSIP ID use case using namespace (VC issuance plugin) - 1.1 VC
Integration with INJI Web - Limited to download only 1.1 VC
Persona based approach has been adopted to perform the IV&V, by simulating test scenarios that resemble a real-time implementation.
A Persona is a fictional character/user profile created to represent a user type that might use a product/or a service in a similar way. Persona based testing is a software testing technique that puts software testers in the customer's shoes, assesses their needs from the software and thereby determines use cases/scenarios that the customers will execute. The persona needs may be addressed through any of the following.
Functionality
Deployability
Configurability
Customizability
The verification methods may differ based on how the need was addressed.
Verification is performed on configurations as mentioned below
Default configuration
English
Below are the test metrics by performing functional testing. The process followed was black box testing which based its test cases on the specifications of the software component under test. Functional test was performed in combination of individual module testing as well as integration testing. Test data were prepared in line with the user stories. Expected results were monitored by examining the user interface. The coverage includes GUI testing, System testing, End-To-End flows across multiple configurations. The testing cycle included simulation of multiple identity schema and respective UI schema configurations.
Total
Passed
Failed
NA
565
527
34
4
Test Rate: 100%, With Pass Rate: 93% and Fail Rate: 6%
Sunbird Use Case
Total
Passed
Failed
Ignored
129
53
5
71
Test Rate: 100%, With Pass Rate: 96% and Fail Rate: 3.8%
5 Failures are known issues can be tracked in INJICERT-681
Mock Use Case
Total
Passed
Failed
Ignored
129
41
0
88
Test Rate: 100%, With Pass Rate: 100% and Fail Rate: 0%
Ignored scenarios are Not related to particular use case
Mosipid Use Case
Total
Passed
Failed
Ignored
129
26
0
103
Test Rate: 100%, With Pass Rate: 100% and Fail Rate: 0%
Ignored scenarios are Not related to particular use case
Below are the detailed test metrics by performing manual/automation testing. The project metrics are derived from Defect density, Test coverage, Test execution coverage, test tracking and efficiency.
The various metrics that assist in test tracking and efficiency are as follows:
Passed Test Cases Coverage: It measures the percentage of passed test cases. (Number of passed tests / Total number of tests executed) x 100
Failed Test Case Coverage: It measures the percentage of all the failed test cases. (Number of failed tests / Total number of test cases executed) x 100
Module/Repo
Image
POM version
Dependent artifactID
Comments
Inji-certify-mosipid
mosipqa/inji-certify:0.10.x
Digital-credential-plugin - 0.3.0
Testing Scope
Test Approach
Verified configuration
Feature Health
Note:
Docker setup - Authorization endpoints pointing to collab.mosip.net
Postgres plugin
Test execution statistics
Functional test results
Automation Statistics
Detailed Test metrics
Tested with Components
Enhanced Verifiable Credential Issuance:
National Identity Plugin: Integration with MOSIP for identity verification, enabling secure and reliable credential issuance.
Insurance Plugin: Seamless integration with Sunbird services to facilitate the issuance and management of VCs.
Mock IDA Plugin: Introduced for testing and development purposes, providing a controlled environment to simulate credential issuance.
Segregation of eSignet VCI Component:
The eSignet VCI component is now separated from eSignet services and migrated to the core Inji Certify system, optimizing functionality and scalability, and allowing for more modular deployments.
Support for VC Formats:
JSON-LD Compliance: Ensures adherence to W3C VC v1.1 standards promoting interoperability and industry compliance.
Credential Schema Configuration: Issuers can now configure custom credential schemas for various types of certificates, enhancing flexibility in credential design and issuance.
Ease of Installation and Deployment:
Docker-compose Support: Quick and easy deployment using Docker-compose, allowing for rapid local setup and scaling. Click here to learn more!
Inji-config Repository:
Configuration Management: Introduction of the inji-config repository to maintain all configurations related to the Inji Certify, streamlining configuration management and consistency across deployments.
Support for Mock and Insurance Credential Use Cases:
Mock Credential Use Case: Provides a predefined setup for mock credentials, useful for testing and development.
Insurance Credential Use Case: A specialized setup for issuing insurance-related credentials, offering a targeted solution for the insurance sector.
For detailed steps click here to view the ReadMe file.
Setup: Configure InjiWeb and Mimoto in your local environment.
Issuer Configuration: Add an issuer in Mimoto with the authorization_endpoint, credential_endpoint and .well-known properties pointing to the installed eSignet and Certify services.
Private Key Addition: Insert the private key from the OIDC client created in eSignet into the .p12 file in Mimoto.
Verification: The configured issuer should now appear on the InjiWeb homepage, allowing you to download the credential.
Plugin Compatibility: For this release, ensure that the eSignet image version in Docker Compose (currently 1.4.0) is consistent with the Mock plugin dependencies in Artifactory. This alignment is crucial due to shared Redis cache dependencies resolving serialization issues.
Repositories
Tags: Released/Dependent
Inji Certify
inji-config
Digital Credential Plugin
The following table outlines the tested and certified compatibility of Inji Certify 0.9.0 with other modules.
Module
Version
eSignet
Sunbird C
Key Manager
Below is the list of known issues. To read in detail and view all the topics related to Inji Verify please click here.
Jira ID
Description
Getting response for well known endpoint when random value is specified in version query param
Inji Certify: VC download is failing with signature alg (ES256) supported values mentioned in well-known response
Inji Certify: Response of Mock VC is having extra attribute with null value
Below is the list of fixes as part of the 0.9.0 release:
Jira ID
Description
Inji Certify: /authorization/v2/oauth-details API is failing with error ""invalid_client_id"
Inji Certify: VC verification is failing for insurance VC
Inji Certify: Fetching of credential list from issuer " National Identity Department (Certify)" is failing
Inji Certify 0.9.0 represents a significant milestone in the evolution of the module offering users enhanced capabilities for issuing, managing, and integrating verifiable credentials. With a focus on scalability, interoperability, and ease of use, this release empowers organizations to leverage the full potential of VCs securely and efficiently.
VCI Client: Manages OpenID4VCI communication with the Issuing Authority.
Authorization Server: Authenticates the user (e.g., eSignet).
Issuing Authority: Issues the VC.
VC Verifier: Verifies credential authenticity.
Pixelpass: Handles QR code generation and encoding.
Workflow Steps:
Key Pair Generation:
On first use, Inji Wallet generates and securely stores a cryptographic key pair via the Secure Keystore.
VC Download Request:
User initiates VC download (via UIN/VID or KBI). Wallet instructs VCI Client to start the OpenID4VCI issuance flow.
User Authentication:
VCI Client redirects the user to the Authorization Server. User authenticates (OTP, KBI, etc.). Authorization Server returns an auth code.
Token Exchange:
Wallet exchanges the auth code for an access token and nonce from the Authorization Server.
Proof Construction:
Wallet creates a proof JWT with the nonce, sends it to Secure Keystore for signing, and receives the signed proof JWT.
Credential Issuance Request:
VCI Client sends the signed proof JWT to the Issuing Authority. Issuer returns the VC.
Credential Verification:
Wallet verifies the VC with the VC Verifier (checks signature and schema). If verification fails, an error is shown.
VC Storage and Rendering:
Verified credentials are securely stored. For some credentials, a QR code is cached for offline use.
This workflow explains how Inji Wallet shares selected VCs with a verifier (Relying Party) using the OpenID4VP protocol.
Actors:
User: Selects credentials and provides consent.
Inji Wallet: Manages the process, interacts with OpenID4VP Module and Secure Keystore.
Secure Keystore: Signs VP tokens.
OpenID4VP Module: Validates requests and structures the VP token.
Relying Party (Verifier): Requests and validates credentials.
Workflow Steps:
QR Code Creation:
The verifier generates a QR code containing the authentication request.
QR Code Scan:
User scans the QR code in Inji Wallet, which extracts the auth request.
Auth Request Validation:
Wallet passes the request to the OpenID4VP Module for validation (issuer, signature, expiry, audience).
Display Matching VCs & User Consent:
Wallet finds matching credentials, displays them, and the user selects which to share and gives consent.
Construct Unsigned VP Token:
Wallet sends selected VCs and metadata to the OpenID4VP Module, which constructs the VP token (unsigned).
Sign VP Token:
OpenID4VP Module sends the unsigned VP token to Secure Keystore for signing. The signed VP token is returned.
Send Auth Response to Verifier:
Wallet sends the signed VP token and presentation_submission to the verifier. The verifier validates the response and, if successful, completes the transaction.
This document delineates the workflow for essential functionalities of Inji Wallet.
After installing the application for the first time, the user will be asked to set up unlock method for it. The app supports biometric or PIN-based locks. For more details, refer to the End User Guide.
Residents have the ability to download a Verifiable Credential (VC) for themselves, their family members, or friends using a single mobile device. This can be done through two methods:
While downloading the VCs, the credentials are validated and verified for the authenticity of the issuer using the signature and the proof type provided in the VC.
Downloading VC using OpenID for VC Issuance Flow (eSignet)
Below sections are going to detail as how Inji Wallet as an OIDC client to OpenID4VCI method of downloading a VC and illustrated implementations.
Download credentials using UIN / VID:
This method of VC download illustrates the OpenID4VCI method of download using UIN / VID issued to the resident. In this, eSignet plays the authentication and authorisation end point to connect to the credential provider (Reference Implementation: MOSIP). To understand more about Onboarding Mimoto (Inji BFF) as an OIDC client to support credential issuance from any issuer who support OpenID4VCI protocol refer here.
Download credentials using Knowledge Based Identification (KBI)
This method of VC download illustrates the OpenID4VCI method of download using KBI (Knowledge Based Identification). In this, eSignet plays the authentication, authorisation and credential issuance end point to connect to the credential provider. To understand more about Onboarding Mimoto (Inji BFF) as an OIDC client to support credential issuance from any issuer who supports OpenID4VCI protocol, refer here.
Appendix:
The term “identifier” in the architecture diagram refers to the unique identifier which can be used to download the credential on the esignet login Page
eSignet supports Various types of authorizations, ACR value is configured based on the Issuers' need to include the authorization mode in the authorization page
Types of Authorization Supported for Credential Download by eSignet are:
Login With OTP: Credential download using OTP Based authentication to authorize the user
Illustrated Implementation: National ID credentials download
Login With KBI: Credential download using KBI to authorize the user. The knowledge (as described by the credential issuer to authorize) is exposed to eSignet from Registry (Issuer) through eSignet Issuance Plugins
Illustrated Implementation: Insurance ID credentials download
The credentials are shared in a peer-to-peer model with the verifier application. The data exchange between devices is done using the BLE Protocol. For more information, refer to Tuvali documentation.
Residents can use Inji Wallet to log in to any service provider app (integrated with e-Signet) by just scanning a QR code from their portal.
The app performs offline face auth after scanning the QR code to verify the user's presence.
Once the presence is verified, the resident is given the option to choose the optional information to be shared with the service provider portal.
After consent is provided, the app sends a WLA (Wallet local auth) token which is a JWT token to the relying party.
The resident is then given the access to the portal after the token verification.
From Settings screen, users can access Backup settings screen. In Backup settings screen, users can configure their preferences for data backup. The setting, configured once during the application's lifecycle, determines whether Google Drive or iCloud will be utilized based on the device platform. To restore backup data to the mobile wallet, users must log in to the same account and configure settings within the app accordingly. Additionally, restored Verifiable Credentials (VCs) should be re-activated to enable QR Code login functionality.
End-to-End Workflow for Inji Mobile Wallet
Credential Download via OpenID4VCI Flow
Verifiable Presentation (VP) Sharing via OpenID4VP Flow
Features Flow
1. First App Launch
Launch with passcode unlock method
Launch with biometric unlock method
2. Downloading, Verifying and storing credentials
Download via eSignet
3. Sharing of credentials
4. QR code login process
Step 1: VC activation process
Step 2: QR code login
5. Data backup and restore
Download credentials from trusted issuers
Verify the authenticity of credentials
Store and display credentials to end users
Optionally present credentials via QR code
By following this “build your own digital credentials wallet” flow, your application achieves:
Secure Key Management
Hardware-backed RS256/ES256 keys, safely managed by Secure Keystore.
End-to-End Credential Issuance
Complete flow from user authentication to credential download.
Credential Verification
Ensures authenticity with cryptographic checks and expiry validation.
Secure Storage & Display
Verified credentials are saved in the app and rendered as cards for users.
Issuer Management
Supports multiple trusted issuers and their metadata.
Credential Presentation
Option to present credentials via QR code (Pixelpass).
Extensible Architecture
Modular libraries allow developers to extend or replace parts of the flow.
For the detailed feature list of Inji Mobile Wallet, referhere!
Before starting, ensure you have:
Android Studio (latest stable version)
Kotlin (with Gradle support)
Internet access for API calls to the Authorization Server and Issuing Authority
Trusted Issuer configuration (issuer metadata like client_id, credential_configuration_id, redirect_uri, etc.)
The custom wallet application integrates several Inji stack libraries, which provide ready-made methods for credential flows.
Component
Library
Primary Function
Secure Keystore
Generates and stores cryptographic key pairs (RS256 / ES256). Used to create Proof JWT.
VCI Client
Handles the credential issuance protocol: authorization, token exchange, proof generation, and downloading the credential.
Create Activity
In Android Studio, create a new project with an empty activity.
Add Dependencies
Open app/build.gradle and add the required dependencies for the Inji libraries:
Verification result returned (True/False with message).
If valid, the wallet stores credentials and renders as a card view.
Wallet calls Pixelpass to generate QR code.
Pixelpass returns a QR image for displaying to the verifier.
Overview
Note:
The terms “custom wallet” and “verifiable credentials wallet” are used interchangeably throughout this document. Both refer to a wallet application built using Inji libraries to securely download, verify, store, and present verifiable credentials (VCs).
Key Features of the Custom Wallet
Prerequisites for Building a Custom Wallet
Inji Libraries Used for Building a Custom Wallet
Setup
Step-by-step guide:
Step 1: Initialization & Key Generation
Step 2: User Authorization
Step 3: Token Exchange
Step 4: Proof Generation & Credential Download
Step 5: Verification & Storage
Optional Step: Credential Presentation
Using Inji libraries and SDKs, which are built on open standards, developers can build their own custom wallets or integrate these libraries into existing applications, effectively transforming them into VC-based wallets.\
Obtaining authorization request
- By value : both signed (via request param) and unsigned (via URL encoded parameters)
- By reference ( via request_uri method)
Note: The use of signed or unsigned requests, is determined by the client_id_scheme associated with the client.
Obtaining presentation definition in authorization request
By value, By reference (via presentation_definition_uri)
direct_post, direct_post.jwt (with encrypted & unsigned responses) and iar-post (unencrypted response), iar-post.jwt (Encrypted and unsigned response)
Authorization Response type
vp_token
constructVPResponse
Construct the VP response (V1 API) with signed tokens ready to be sent to the verifier
constructVPResponseV2
Construct the VP response (V2 API) from simplified signing results
sendVPResponseToVerifier
Construct VP response and send it to the verifier via HTTP POST
constructErrorInfo
Construct an authorization error response as per OpenID4VP specification
sendErrorInfoToVerifier
Construct and send error response to the verifier via HTTP POST
Components
Inji Wallet utilizes multiple libraries to provide a seamless experience.
These library are accessible as AAR for Android app and SPM(Swift Package Manager) for iOS App. Android libraries are written in Kotlin and can be easily integrated with cross platform applications like React Native or Flutter. This helps with seamless integration with other mobile wallets.
The libraries are as follows:
Secure Keystore SDK
VCI Client SDK
PixelPass SDK
Tuvali - Sharing via BLE SDK
OpenID4VP - Online Sharing SDK
Face Match SDK
Telemetry SDK(coming soon)
This library facilitates the transfer of downloaded Verifiable Credential from the Wallet to Verifier.
Tuvali enables offline VC transfer between mobile devices via Bluetooth Low Energy (BLE). The below table represents the supported roles for Android and iOS devices.
Wallet
Verifier
VC transfer support
Tuvali is actively developed and maintained by MOSIP.
The face matcher SDK internally implements native functionalities for Android and iOS, utilizing and to identify faces.
This SDK internally employs a tflite model, which is now bundled within the app. The face matcher functionality is also available via the NPM module, which is already integrated for offline face authentication in Inji Wallet.
The SDK is employed in two scenarios: During Both Offline and Online VC Sharing: Residents can perform selfie authentication before sharing the VC with the relying party. The app opens the camera, allowing residents to take a selfie, which is then validated against the VC image to verify the resident's presence. This process is supported for both offline VC sharing (e.g., via BLE) and online login (e.g., scanning a QR code from the relying party portal and logging in using Inji Wallet). Refer to check the API specifications for the face matcher model.
The secure-keystore library is designed for creating and storing key pairs in the hardware keystore of devices. The library supports encryption, decryption, HMAC calculation, and signing with aliases created during key pair generation.
This library is available for both Android and iOS platforms:
For Android: Refer to the .
For iOS: Refer to the .
Inji Wallet integrates with the secure-keystore library to ensure secure key management. To optimize the key size during credential download requests, Inji Wallet uses RSA-2048, ECR1, ECK1, ED25519 keys.
To check all the APIs supported by this module, refer .
The PixelPass library offers a powerful solution for creating and decoding QR codes for Verifiable Credentials (VCs). It is designed to optimize the size of the data encoded within a QR code, making it easier to store and share credential information. The library achieves this by utilizing advanced compression and encoding techniques, ensuring smaller QR codes that maintain the integrity and security of the data.
PixelPass uses zlib compression with a level 9 setting, which significantly reduces the data size before encoding. It then applies base45 encoding to further compress the data into a QR code-friendly format. Additionally, the library can decode any QR code data previously encoded using its own compression and encoding algorithms, ensuring seamless interoperability.
Additionally, for a JSON data, the library employs CBOR encoding and decoding to minimize the size even further. When a JSON Mapper similar to is provided, PixelPass maps the data, applies CBOR encoding/decoding, and compresses the data, achieving maximum size reduction. Developed and maintained by MOSIP, PixelPass is continually updated to provide reliable and efficient QR code generation and decoding capabilities.
VCI-Client library carries out the credential request from the consumer application (mobile wallet or web) and redirects the issuance/issuer. The library creates a request with the credential format, jwtproof of the wallet, issuer metadata and the access token received for authorization and provides VC as the response back to the consumer application for storage.
This OpenID4VP library enables consumer applications (mobile wallet) to share users Verifiable Credentials with Verifiers who request them online. It adheres to the OpenID4VP specification which outlines the standards for requesting and presenting Verifiable Credentials.
Receives the Verifier's Authorization Request sent by the consumer application (mobile wallet).
Validates the received Authorization Request to check if the required details are present or not and then returns the Authorization Request to the consumer application once all the validations are successful.
Receives the list of Verifiable Credentials from the consumer application which are selected by the consumer application end-user based on the credentials requested as part of Verifier Authorization request.
The module is derived from the module. It is responsible for generating events that can provide valuable analytics.
Note: The publication of this project is currently a work in progress and has not been released yet. Stay tuned for further announcements!
Inji Certify v0.14.0 introduces key enhancements to credential issuance workflows, interoperability, and user experience. This release focuses on strengthening OpenID4VCI flows, expanding support for emerging credential formats, and improving system usability and integration capabilities.
Major updates include support for presentation during issuance, mDoc/mDL credentials, Pre-Authorized Code flow, enhanced error handling, QR code embedding in credentials, and seamless integration with MOSIP for data-driven credential generation.
Version 0.13.0
Release Version 0.13.0
Release Type: Developer Release
Release Date: 28th November, 2025
Inji Certify v0.13.0 introduces major advances in credential issuance and lifecycle management and this includes the following:
A full implementation of the Revocation Flow enabling issuers to mark credentials as revoked and track them with a ledger.
Test Report
The scope of testing is to verify fitment to the specification from the perspective of
Functionality
Deployability
Configurability
Test Report
The scope of testing is to verify fitment to the specification from the perspective of
Functionality
Deployability
Configurability
Features
Inji Mobile is an open-source digital wallet designed to enable individuals to receive, store, and present Verifiable Credentials (VCs) securely, both online and offline. Purpose-built to align with global standards like W3C VC, OpenID4VCI, OpenID4VP, IETF SD-JWT, and ISO 18013-5 (mDL), it brings interoperability, user autonomy, and strong cryptographic guarantees to digital identity ecosystems.
Inji Wallet is designed for interoperability and flexibility by supporting a wide range of credential formats:
W3C Verifiable Credentials (JSON-LD VCs) Data Model 1.1
Standards-based credential format is widely adopted across ecosystems.
On the "Retrieve your ID" screen, instead of using "VID auto population," consider using "Download ID." This change will help avoid confusion for Abi, who might expect an explanation of what VID / UIN IDs are.
On the "Home with cards view," Abi might wonder why her card displays "Activation Pending," while the other card shows Activated for online login".
In the FAQ or Help section, provide information about the various types of IDs, their locations, and instructions on how to download them using different ID methods.
Provide additional information related to "Activation Pending," and ensure clear icon translations for "Activation Done" versus "Activation Pending".
When the user clicks on the "Add" button, the options "Generate your card" or "Retrieve your ID" might be confusing.
The description should also include an explanation of why the verification process is necessary.
When the user glances at the screen, the "AID" is not immediately evident.
Update main screen name to "Download your card".
Update main screen description to "Select ID type and enter the MOSIP provided UIN or VID you wish to download." (Also, with a reference to upcoming OTP screen).
Enhance the text to provide a heads up about the upcoming step of OTP verification, so that user is prepared to receive and enter the OTP.
Update bottom line text to "Don't have UIN / VID? Get it now using your AID."
Though Tim is tech savvy, Tim will be sort of puzzled why the app needs location access as well despite a lot of other permissions provided. Tim will be unhappy and question why they are required to provide location access in order to scan a QR code.
Description can be more indicative of the specific purpose of seeking location access.
Abi is not so familiar with tech, when the app says share a selfie, they might not know, face auth using her photo, is going in the background. she might think it will break her privacy.
Abi might be confused, as she cannot understand what is the next action to be done, from the instruction. it does not mention whether she has to click on the shutter button or it will take a picture automatically although she would perform the subgoal. Will it automatically click the selfie or do Abi need to click on the button?
For problem statement 1:
Provide assurance wrt Privacy
Terminology update: Face Authentication to Face Verification
Acquaint user with text about "Share with selfie" feature, informing user about face authentication - Through FAQs
Avoid usage of slang jargons like selfie → need confirmation from the product team on the alternative <Sasi>: Let us retain the word as that is more relatable to all.
For problem statement 2:
Enhance text: In the Face Verification screen, the text should be enhanced as "Hold the phone steady, keep your face focused in the centre and click on Capture" below the camera placeholder.
The description in the camera screen is not explaining about the sharing credential. Text near the scanner can mention about the “Hold the phone steady and scan the QR code to share your credential”.
Enhance text in Share page while scanning QR code. Text near the scanner can mention about the “Hold the phone steady and scan the QR code to share your card."
Abi would be stressed if she doesn’t remember the passcode. As there is nothing on the screen to get help. She might not know what to do because she is risk averse.
Add text: Tap on the button to unlock you app with the PIN or biometrics - Text to be enhanced in the unlock screen to clearly call out on other options.
“To unlock the app securely, you can set up either biometric authentication, such as fingerprint or facial recognition or opt for a 6-digit Passcode for quick access.
Choose 'Use Biometrics' to enable biometric authentication or 'I'll Do Later' to set up a 6-digit passcode.”
During the VC sharing, the successful transfer screen closes in a split second leaving the user clueless on the action status. The transition was quick, and no document is shown after the successful transfer. hence Abi is not clear if the sharing is successful or not.
Consider having an Error screen with CTA, clearly indicating the next expected action > Retry
No Information related to the selfie captured process was not conveyed to the users, even in the end screen. Selfie capture process does not relate back to the ID sharing process. No message regarding what happened with the selfie clicked.
Post face capture and before initiating the sharing process, inform users about successful face verification/match - But without any CTA.
Authority from which the final credential (VC) is issued and downloaded.
Authorization Server (AS)
(External)
Service where users authenticate to get authorization codes. In case of Inji eSignet can also be used as authorization server as it is a MOSIP product so both are compatible.
Presentation during Issuance: Introduced a new issuance mode enabling residents to present an existing Verifiable Credential to obtain another credential.
Pre-Authorized Code Flow: Enabled a simplified issuance flow where users can securely download credentials using a pre-authorized and transaction code.
Support to upload Externally-signed CA Certificates into the key-management workflow, allowing organizations to use their own PKI for signing credentials.
Full implementation of the SD-JWT - Selective Disclosure JWT issuance feature.
Updated Docker-Compose support that aligns with the latest versions of the associated modules (Inji Web & Mimoto).
The Revocation feature is now fully functional, issuers can revoke VCs, and the ledger can be configured for indexing to support efficient search for revocation lookup.
You can now Issue Credentials in SD-JWT - Selective Disclosure JWT format, offering issuers selective disclosure capabilities and enhanced privacy options.
Revocation Implementation
The Revocation feature is now fully functional, issuers can revoke VCs, and the ledger can be configured for indexing to support efficient search for revocation lookup.
Upload the CA certificate via the upload-ca-certificate endpoint.
Upload the signed certificate via the uploadCertificate endpoint.
Once configured, the system’s key manager uses these externally signed certificates to generate keys and sign VCs.
SD-JWT Implementation
You can now Issue Credentials in format, offering issuers selective disclosure capabilities and enhanced privacy options.
Docker-Compose Upgrade
We have now Updated The docker-compose.yml definitions to reference latest versions of Inji Web and Mimoto, helping streamline environment setup, testing, and CI/CD workflows.
Feature
Description
JIRA
Revocation of VC
Searching VC to be revoked
Enabling revocation through configuration using API
Below are a few key bugs that have been addressed as part of this release. Please click here to learn more about the issues that have been resolved:
JIRA
Description
Incorrect x5c Field in JWT Header – Certificate Passed Instead of Full Trust Chain
Issue while fetching VC from inji mobile with signed using RSA signature
Issues in Credential config APIs
Below is the list of known issues related to the release v0.13.0. To access all known issues related to Inji Certify please click here.
Upload ca cert for ecck1 signalgo is failing
Authenticate user API failing with test automation
Verification is performed not only from the end user perspective but also from the System Integrator (SI) point of view. Hence Configurability and Extensibility of the software is also assessed. This ensures readiness of software for use in multiple countries. Since MOSIP is an “API First” product platform.
Testing scope has been focused on the following features:
Automation (Mospid, Mock, Sunbird, Landregistry use cases)
Persona based approach has been adopted to perform the IV&V, by simulating test scenarios that resemble real-time implementation.
A Persona is a fictional character/user profile created to represent a user type that might use a product/or a service in a similar way. Persona based testing is a software testing technique that puts software testers in the customer's shoes, assesses their needs from the software and thereby determines use cases/scenarios that the customers will execute. The persona needs may be addressed through any of the following.
Functionality
Deployability
Configurability
Customizability
The verification methods may differ based on how the need was addressed.
Verification is performed on configurations as mentioned below
Default configuration
English
Note:
For Esignet compatibility
eSignet 1.6.2 from released env
Below are the test metrics by performing functional testing. The process followed was black box testing which based its test cases on the specifications of the software component under test. Functional test was performed in combination of individual module testing as well as integration testing. Test data were prepared in line with the user stories. Expected results were monitored by examining the user interface. The coverage includes GUI testing, System testing, and End-To-End flows across multiple configurations. The testing cycle included simulation of multiple identity schema and respective UI schema configurations.
Total
Passed
Failed
NA
783
772
9
0
Test Rate: 100%, With Pass Rate: 98.5% and Fail Rate: 2%
Automation Statistics
Sunbird use case
Total
Passed
Failed
Ignored
Known issues
560
72
0
453
35
Mock Use case
Total
Passed
Failed
Ignored
Known issues
560
50
0
475
35
Mock (Data provider) Landregistry Use case
Total
Passed
Failed
Ignored
Known Issues
560
199
0
199
35
MosipId Use case
Total
Passed
Failed
Ignored
Known Issues
560
64
0
461
35
Note - Ignored scenarios are not related to particular use cases and 35 scenarios are known issues can be tracked from INJICERT-681, INJICERT-1118, INJICERT-1176
Below are the detailed test metrics by performing manual/automation testing. The project metrics are derived from Defect density, Test coverage, Test execution coverage, test tracking and efficiency.
The various metrics that assist in test tracking and efficiency are as follows:
Passed Test Cases Coverage: It measures the percentage of passed test cases. (Number of tests passed / Total number of tests executed) x 100
Failed Test Case Coverage: It measures the percentage of all the failed test cases. (Number of failed tests / Total number of test cases executed) x 100
Module/Repo
Image
POM version
Dependent artifactID
Comments
Inji-certify-mosipid
mosipqa/inji-certify-with-plugins:0.13.x
Refer to the github link for more on reports here.
Testing Scope
Test Approach
Verified configuration
Feature Health
Test execution statistics
Functional test results
Detailed Test Metrics
Tested with Components
Customizability
Verification is performed not only from the end user perspective but also from the System Integrator (SI) point of view. Hence Configurability and Extensibility of the software is also assessed. This ensures readiness of software for use in multiple countries. Since MOSIP is an “API First” product platform.
Testing scope has been focused on the following features:
Insurance, MosipId and Mock (Issuance and Data provider (Postgres plugin)), which covered Land registry, school and Framer use case
Integration with Inji Web and Inji verify
DB upgrade scripts testing, Backward compatibility - from Docker setup
Sd_jwt format
Revocation feature
CSR certificate(generate, upload and fetch)
Multi language support for VC
Svg render method
Persona based approach has been adopted to perform the IV&V, by simulating test scenarios that resemble real-time implementation.
A Persona is a fictional character/user profile created to represent a user type that might use a product/or a service in a similar way. Persona based testing is a software testing technique that puts software testers in the customer's shoes, assesses their needs from the software and thereby determines use cases/scenarios that the customers will execute. The persona needs may be addressed through any of the following.
Functionality
Deployability
Configurability
Customizability
The verification methods may differ based on how the need was addressed.
Verification is performed on configurations as mentioned below
Default configuration
English
Supported multi language according to configuration
Note: For Esignet compatibility
eSignet 1.6.2 from released env
Docker compose testing – esignet from collab env by default
Below are the test metrics by performing functional testing. The process followed was black box testing which based its test cases on the specifications of the software component under test. Functional test was performed in combination of individual module testing as well as integration testing. Test data were prepared in line with the user stories. Expected results were monitored by examining the user interface. The coverage includes GUI testing, System testing, and End-To-End flows across multiple configurations. The testing cycle included simulation of multiple identity schema and respective UI schema configurations.
Total
Passed
Failed
NA
783
772
9
0
Test Rate: 100%, With Pass Rate: 98.5% and Fail Rate: 2%
Automation Statistics
Sunbird use case
Total
Passed
Failed
Ignored
Known issues
560
72
0
453
35
Mock Use case
Total
Passed
Failed
Ignored
Known issues
560
50
0
475
35
Mock (Data provider) Landregistry Use case
Total
Passed
Failed
Ignored
Known Issues
560
199
0
199
35
MosipId Use case
Note - Ignored scenarios are not related to particular use cases and 35 scenarios are known issues can be tracked from INJICERT-681, INJICERT-1118, INJICERT-1176
Below are the detailed test metrics by performing manual/automation testing. The project metrics are derived from Defect density, Test coverage, Test execution coverage, test tracking and efficiency.
The various metrics that assist in test tracking and efficiency are as follows:
Passed Test Cases Coverage: It measures the percentage of passed test cases. (Number of tests passed / Total number of tests executed) x 100
Failed Test Case Coverage: It measures the percentage of all the failed test cases. (Number of failed tests / Total number of test cases executed) x 100
Module/Repo
Image
POM version
Dependent artifactID
Comments
Inji-certify-mosipid
mosipqa/inji-certify-with-plugins:0.13.x
Digital-credential-plugin - 0.5.0
Testing Scope
Test Approach
Verified configuration
Feature Health
Test execution statistics
Functional test results
Detailed Test Metrics
Tested with Components
Suitable for general-purpose credential issuance and verification.
ISO 18013-5 (mDL)
Mobile Driving License and Mobile Document specification.
Supports use cases like identity verification in transport, law enforcement, and service access.
IETF SD-JWT
IETFSD-JWT Verifiable Credentials: Enables holders to download and share credentials in IETF SD-JWT format. This allows users to share only the necessary attributes while keeping other data private, ensuring privacy-preserving credential sharing.
Allows users to share only the required claims with verifiers via the OpenIDVP flow, where these selectively disclosable claims can be shared as per the user's need.
This multi-format support allows Inji Wallet to work seamlessly across different ecosystems, ensuring compatibility, security, and user privacy.
Inji Wallet makes it easy and secure for residents to manage their digital identity and credentials. From downloading and verifying to sharing and backing up Verifiable Credentials (VCs), this guide outlines all key features and workflows available in the wallet.
Residents can download VCs from trusted issuers integrated with OpenID for the VCI protocol.
Example Issuers:
Republic of Veridonia National ID Department - National ID
StayProtected Insurance - Insurance Credentials
Republic of Veridonia Tax Department - Tax ID
AgroVeritas Property & Land Registry - Land Record
Veridonia Department of Motor Vehicles - mDoc
Users download credentials directly using a credential_offer URI
No login required; pre-auth code embedded in the offer
Used in mass issuance or public campaigns (e.g., vaccination certificates, offline cards)
Adds a one-time transaction code (OTP / claim code) to bind issuance to the user
User enters code in-app to retrieve VC securely
Ideal for privacy-sensitive issuance (e.g., mDL, insurance)
Enables users to present an existing credential before receiving a new one, reducing repeated verification steps.
Allows issuers to verify eligibility securely using Verifiable Presentations (VPs).
Improves user experience with consent-based sharing directly from the wallet.
Built on OpenID4VCI and OpenID4VP standards for interoperable issuance flows.
Helps prevent fraud and ensures credentials are issued only to eligible users.
Supports standardized QR codes for initiating credential download and sharing flows.
Download credentials containing embedded Claim 169 QR blocks
Store and render these QR blocks for display
Allow users to present the QR-based identity data when required
Ensure proper validation and security checks (size, format, signature, structure)
Inji Mobile Wallet uses robust cryptographic libraries to verify that the VC is:
Digitally signed by a trusted issuer, ensuring the credential originates from a valid and recognized entity.
Cryptographically valid based on proof type verifying the integrity of the data using the appropriate proof mechanisms (e.g., JSON-LD proof, JWT, IETF SD-JWT, etc.).
Not revoked or expired performing revocation status checks using status lists, revocation registries, or endpoints defined in the VC metadata.
Untampered confirming that no field or claim in the credential has been altered since issuance.
Bound to the correct holder (where applicable) verifying holder binding in cases where the VC includes a subject proof (e.g., via DID or SD-JWT binding).
Inji Wallet supports secure sharing of Verifiable Credentials (VCs) in multiple ways — both online and offline — with strong privacy and authentication.
Method
Description
Connectivity
User Control / Notes
QR Code Sharing
Generate QR using PixelPass. Scan or upload on verifier portal.
Online
Quick and compact
BLE (Bluetooth) Sharing
Note: All methods include user consent and privacy-by-design to ensure secure, context-aware interactions.
Inji Wallet now supports SVG-based credential rendering for Data Model 2.0 VCs.
This allows credentials issued under the Data Model 2.0 schema to be displayed as secure, dynamic SVG visuals within the wallet.
The rendering ensures that displayed information (such as name, ID, issuer, and other attributes) directly corresponds to the cryptographically verified credential data.
This enhancement improves readability, user trust, and consistency while maintaining alignment with the underlying verifiable data.
Support for SVG rendering for other data models may be added in future versions.
Automatic Status Check – The wallet automatically checks if a card is valid, revoked, or pending when it is downloaded.
Manual Recheck Anytime – Users can recheck a card’s status whenever needed, with clear results shown instantly.
Easy-to-Understand Status Labels – Cards clearly show one of three states: Valid, Revoked, Expired and Pending.
History Tracking – Whenever there is a change in status, it reflects in the user’s History for easy tracking and transparency.
Inji Wallet includes a secure, one-time backup setup based on the platform:
Platform
Backup Option
Notes
Android
Google Drive
Select Google account
iOS
iCloud
Uses logged-in Apple account
Ideal for:
Phone upgrades
App crashes or resets
Designed for ease of use with intuitive UI components:
Multiple VC Views: Mini cards to full detail
Separation of Downloaded vs. Received VCs
Quick Access Menu: Share, Share with Selfie via the kebab menu (⋮) on card
Select from a list of credential types offered by the issuer.
Choose only the VCs they want to download, ensuring relevance and control.
VCs grouped by type (ID, insurance, education)
Recent VCs shown first
Biometric / Passcode Access
App requires authentication on every open or session timeout
Supports Android biometrics and Apple Face ID / Touch ID
Private Key Storage in Secure Enclave
Private keys are stored using Android Keystore / iOS Secure Enclave
GET /residentmobileapp/issuers HTTP/1.1
Host: api.collab.mosip.net
Accept: */*
200
OK
{
"id": "mosip.resident.vid",
"version": "v1",
"str": null,
"responsetime": "2022-10-31T05:08:14.846Z",
"metadata": null,
"response": {
"issuers": [
{
"credential_issuer": "MOSIPInsurance",
"protocol": "OpenId4VCI",
"display": [
{
"name": "MOSIP Insurance",
"logo": {
"url": "https://api.collab.mosip.net/inji/mosip-logo.png",
"alt_text": "MOSIP-Logo"
},
"title": "Download via LIC",
"description": "Enter your policy number to download your card.",
"language": "en"
}
],
"client_id": "3yz7-j3xRzU3SODdoNgSGvO_cD8UijH3AIWRDAg1x-M",
".well-known": "http://localhost:8088/.well-known/openid-credential-issuer"
},
{
"credential_issuer": "MOSIPNationalID",
"protocol": "OpenId4VCI",
"display": [
{
"name": "MOSIP National ID",
"logo": {
"url": "https://api.collab.mosip.net/inji/mosip-logo.png",
"alt_text": "MOSIP-Logo"
},
"title": "Download via LIC",
"description": "Enter your policy number to download your card.",
"language": "en"
}
],
"client_id": "3yz7-j3xRzU3SODdoNgSGvO_cD8UijH3AIWRDAg1x-M",
".well-known": "http://localhost:8088/.well-known/openid-credential-issuer"
}
]
}
}
get/issuers/{issuer-id}
GET /residentmobileapp/issuers/{issuer-id} HTTP/1.1
Host: api.collab.mosip.net
Accept: */*
200
OK
Wallet Binding - Generate Otp
Wallet Binding - Bind Credential with wallet
Version 0.12.0
Release Version: 0.12.0
Release Type: Developer Release
Release Date: 26th August, 2025
Overview
Inji Certify v0.12.0, brings significant enhancements in credential issuance, revocation, and cryptographic support. This release continues our commitment to aligning with emerging standards while providing issuers with flexible configuration and integration capabilities.
Major Highlights/ Features
Credential Formats – Draft Implementation
SD-JWT and JWT support: Draft implementation enabling issuers to issue credentials in Selective Disclosure JWT (SD-JWT) format, expanding interoperability across wallets. Refer to to know more about this feature
VC Configuration & Binding
Configurable VC Type: Issuers can now configure the VC Type dynamically, providing greater flexibility for different issuance use cases. Refer to for more details.
DID Binding with did key🔑 Added support for binding credentials to did:key, enhancing decentralization and cryptographic agility.
Revocation – Draft Implementation
VC Revocation: Initial draft implementation of revocation capabilities, allowing issuers to mark credentials as revoked and support verifiers in checking credential status. Refer to for more details.
Cryptography & Data Integrity
Data Integrity Support: Added support for W3C Data Integrity Proofs, providing a standards-based mechanism for ensuring verifiability of issued credentials.
ECC R1 Curve Support: Extended cryptographic suite with support for Elliptic Curve secp256r1 (P-256), enabling broader adoption and compliance. Refer to for more details.
Feature
Description
JIRA
JIRA
Description
Below is the list of known issues related to the release v0.12.0. To access all known issues related to Inji Certify please click
JIRA
Description
Repositories
Tags Released
The following table outlines the tested and certified compatibility of <release version> with other modules.
Modules
Version (with tag links)
Test Report
Testing Scope
The scope of testing is to verify fitment to the specification from the perspective of
Functionality
Deployability
Configurability
Customizability
Verification is performed not only from the end user perspective but also from the System Integrator (SI) point of view. Hence Configurability and Extensibility of the software is also assessed. This ensures readiness of software for use in multiple countries. Since MOSIP is an “API First” product platform.
Testing scope has been focused on the following features:\
Inji certify Docker compose testing (Removal of artifactory dependency – Data provider CSV plugin and mdoc plugin) which covered Farmer Use case
Esignet compatibility with 1.5.1 version and 1.4.1 version
Insurance, Mock (Issuance and Data provider (Postgres plugin)), MosipId which covered Land registry, school use case also
Persona based approach has been adopted to perform the IV&V, by simulating test scenarios that resemble real-time implementation.
A Persona is a fictional character/user profile created to represent a user type that might use a product/or a service in a similar way. Persona based testing is a software testing technique that puts software testers in the customer's shoes, assesses their needs from the software and thereby determines use cases/scenarios that the customers will execute. The persona needs may be addressed through any of the following.
Functionality
Deployability
Configurability
Customizability
The verification methods may differ based on how the need was addressed.
Verification is performed on configurations as mentioned below
Default configuration
English
Note:
For keycloak integration – keycloak is pointing to dev2 env
For Esignet compatibility
eSignet 1.5.1 from dev2 env
Below are the test metrics by performing functional testing. The process followed was black box testing which based its test cases on the specifications of the software component under test. Functional test was performed in combination of individual module testing as well as integration testing. Test data were prepared in line with the user stories. Expected results were monitored by examining the user interface. The coverage includes GUI testing, System testing, and End-To-End flows across multiple configurations. The testing cycle included simulation of multiple identity schema and respective UI schema configurations.
Automation Statistics
Sunbird use case
Mock Use case
Mock (Data provider) Use case
Below are the detailed test metrics by performing manual/automation testing. The project metrics are derived from Defect density, Test coverage, Test execution coverage, test tracking and efficiency.
The various metrics that assist in test tracking and efficiency are as follows:
Passed Test Cases Coverage: It measures the percentage of passed test cases. (Number of tests passed / Total number of tests executed) x 100
Failed Test Case Coverage: It measures the percentage of all the failed test cases. (Number of failed tests / Total number of test cases executed) x 100
Test Report
Testing Scope
The scope of testing is to verify fitment to the specification from the perspective of
Functionality
Deployability
Configurability
Customizability
Verification is performed not only from the end user perspective but also from the System Integrator (SI) point of view. Hence Configurability and Extensibility of the software is also assessed. This ensures readiness of software for use in multiple countries. Since MOSIP is an “API First” product platform.
Testing scope has been focused on the following features:
Insurance, MosipId and Mock (Issuance and Data provider (Postgres plugin)), which covered Land registry use case
Integration with Inji Web and Inji verify
Persona based approach has been adopted to perform the IV&V, by simulating test scenarios that resemble real-time implementation.
A Persona is a fictional character/user profile created to represent a user type that might use a product/or a service in a similar way. Persona based testing is a software testing technique that puts software testers in the customer's shoes, assesses their needs from the software and thereby determines use cases/scenarios that the customers will execute. The persona needs may be addressed through any of the following.
Functionality
Deployability
Configurability
Customizability
The verification methods may differ based on how the need was addressed.
Verification is performed on configurations as mentioned below
Default configuration
English
Below are the test metrics by performing functional testing. The process followed was black box testing which based its test cases on the specifications of the software component under test. Functional test was performed in combination of individual module testing as well as integration testing. Test data were prepared in line with the user stories. Expected results were monitored by examining the user interface. The coverage includes GUI testing, System testing, and End-To-End flows across multiple configurations. The testing cycle included simulation of multiple identity schema and respective UI schema configurations.
Total
Passed
Automation Statistics
Sunbird use case
Total
Passed
Failed
Ignored
Known issues
Mock Use case
- Mock (Data provider) Landregistry Use case
MosipId Use case
Below are the detailed test metrics by performing manual/automation testing. The project metrics are derived from Defect density, Test coverage, Test execution coverage, test tracking and efficiency.
The various metrics that assist in test tracking and efficiency are as follows:
Passed Test Cases Coverage: It measures the percentage of passed test cases. (Number of tests passed / Total number of tests executed) x 100
Failed Test Case Coverage: It measures the percentage of all the failed test cases. (Number of failed tests / Total number of test cases executed) x 100
Module/Repo
Image
POM version
Dependent artifactID
Comments
Refer to the github link for more on reports .
Test Report
Testing Scope
The scope of testing is to verify fitment to the specification from the perspective of
Functionality
Deployability
Configurability
Customizability
Verification is performed not only from the end user perspective but also from the System Integrator (SI) point of view. Hence Configurability and Extensibility of the software is also assessed. This ensures readiness of software for use in multiple countries. Since MOSIP is an “API First” product platform.
Testing scope has been focused on the following features:
Insurance, MosipId and Mock (Issuance and Data provider (Postgres plugin)), which covered Land registry use case
Integration with Inji Web and Inji verify
Persona based approach has been adopted to perform the IV&V, by simulating test scenarios that resemble real-time implementation.
A Persona is a fictional character/user profile created to represent a user type that might use a product/or a service in a similar way. Persona based testing is a software testing technique that puts software testers in the customer's shoes, assesses their needs from the software and thereby determines use cases/scenarios that the customers will execute. The persona needs may be addressed through any of the following:
Functionality
Deployability
Configurability
Customizability
The verification methods may differ based on how the need was addressed.
Verification is performed on configurations as mentioned below
Default configuration:
English
Below are the test metrics by performing functional testing. The process followed was black box testing which based its test cases on the specifications of the software component under test. Functional test was performed in combination of individual module testing as well as integration testing. Test data were prepared in line with the user stories. Expected results were monitored by examining the user interface. The coverage includes GUI testing, System testing, and End-To-End flows across multiple configurations. The testing cycle included simulation of multiple identity schema and respective UI schema configurations.
Test Rate: 100%, With Pass Rate: 97% and Fail Rate: 3%
Sunbird use case
Test Rate: 100%, With Pass Rate: 90% and Fail Rate: 10%
Mock Use case
Test Rate: 100%, With Pass Rate: 94.4% and Fail Rate: 5.6%
Mock (Data provider) Landregistry Use case
Test Rate: 100%, With Pass Rate: 94.6% and Fail Rate: 5.4%
MosipId Use case
Test Rate: 100%, With Pass Rate: 85.3% and Fail Rate: 14.7%
Below are the detailed test metrics by performing manual/automation testing. The project metrics are derived from Defect density, Test coverage, Test execution coverage, test tracking and efficiency.
The various metrics that assist in test tracking and efficiency are as follows:
Passed Test Cases Coverage: It measures the percentage of passed test cases. (Number of tests passed / Total number of tests executed) x 100
Failed Test Case Coverage: It measures the percentage of all the failed test cases. (Number of failed tests / Total number of test cases executed) x 100
The scope of testing is to verify fitment to the specification from the perspective of
Functionality
Deployability
Configurability
Features
Inji Certify comes with a comprehensive suite of features designed to make credential issuance seamless, secure, and standards-compliant. Key features include:
Inji Certify is built to issue digital credentials that are fully compliant with globally recognized standards, ensuring interoperability across systems and jurisdictions. It:
Supports W3C Verifiable Credentials Data Model (versions 1.1 and 2.0) for secure, portable, and verifiable documents
Implements OpenID for Verifiable Credential Issuance (OpenID4VCI) for seamless and secure delivery of credentials to digital wallets
Share VCs offline using Bluetooth Low Energy.
Offline
Peer-to-peer; face match supported
SSO via QR Code
Scan QR on service portal → share selected VCs after user consent.
Online
Fine-grained VC selection and SSO login
OpenID4VP – Cross-Device
Scan verifier’s QR from another device → present VCs post face verification.
Example: Sharing of JSON-LD,mDoc VCs etc
Online
Secure, decentralized VC presentation
OpenID4VP – Same Device
Tap QR on browser → deep-link opens wallet → share credentials.
Example: Sharing of JSON-LD,mDoc VCs etc
Online
Seamless redirect
SD-JWT Verifiable Presentation (VP) Support
Inji Wallet supports OpenID for Verifiable Presentations (OpenID4VP) flow for credentials in the IETF SD-JWT format.
Holders can selectively disclose specific claims while keeping other attributes private.
This ensures privacy-preserving credential sharing with verifiers, aligning with IETF SD-JWT and OpenID4VP standards.
The wallet validates signed authorization requests and presents only the chosen claims, ensuring security and consent-driven sharing.
{
"id": "mosip.mimoto.issuers",
"version": "v1",
"str": null,
"responsetime": "2024-04-25T05:56:55.890Z",
"metadata": null,
"response": {
"credential_issuer": "ESignet",
"protocol": "OpenId4VCI",
"display": [
{
"name": "e-Signet",
"logo": {
"url": "https://api.collab.mosip.net/inji/mosip-logo.png",
"alt_text": "mosip-logo"
},
"title": "Download MOSIP Credentials",
"description": "Download credentials by providing UIN or VID",
"language": "en"
},
{
"name": "e-Signet",
"logo": {
"url": "https://api.collab.mosip.net/inji/mosip-logo.png",
"alt_text": "شعار موسيب"
},
"title": "قم بتنزيل بيانات اعتماد MOSIP",
"description": "توفير UIN أو VIDقم بتنزيل بيانات الاعتماد عن طريق",
"language": "ar"
},
{
"name": "e-Signet",
"logo": {
"url": "https://api.collab.mosip.net/inji/mosip-logo.png",
"alt_text": "मोसिप लोगो"
},
"title": "MOSIP क्रेडेंशियल डाउनलोड करेंं",
"description": "यूआईएन या वीआईडी प्रदान करके क्रेडेंशियल डाउनलोड करें",
"language": "hi"
},
{
"name": "e-Signet",
"logo": {
"url": "https://api.collab.mosip.net/inji/mosip-logo.png",
"alt_text": "mosip ಲೋಗೋ"
},
"title": "MOSIP ರುಜುವಾತುಗಳನ್ನು ಡೌನ್ಲೋಡ್ ಮಾಡಿ",
"description": "UIN ಅಥವಾ VID ಒದಗಿಸುವ ಮೂಲಕ ರುಜುವಾತುಗಳನ್ನು ಡೌನ್ಲೋಡ್ ಮಾಡಿ",
"language": "kn"
},
{
"name": "e-Signet",
"logo": {
"url": "https://api.collab.mosip.net/inji/mosip-logo.png",
"alt_text": "mosip லோகோ"
},
"title": "MOSIP சான்றுகளைப் பதிவிறக்கவும்",
"description": "UIN அல்லது VIDஐ வழங்குவதன் மூலம் நற்சான்றிதழ்களைப் பதிவிறக்கவும்",
"language": "ta"
},
{
"name": "e-Signet",
"logo": {
"url": "https://api.collab.mosip.net/inji/mosip-logo.png",
"alt_text": "logo ng mosip"
},
"title": "I-download ang Mga Kredensyal ng MOSIP",
"description": "Mag-download ng mga kredensyal sa pamamagitan ng pagbibigay ng UIN o VID",
"language": "fil"
}
],
"client_id": "DEqVWfdKe9cQWikLdjak3vlDF0Pq7jtnwTcGdEXoT1I",
"redirect_uri": "io.mosip.residentapp.inji://oauthredirect",
"scopes_supported": [
"mosip_identity_vc_ldp"
],
"authorization_endpoint": "https://esignet.collab.mosip.net/authorize",
"authorization_audience": "https://esignet.collab.mosip.net/v1/esignet/oauth/v2/token",
"token_endpoint": "https://api.collab.mosip.net/residentmobileapp/get-token/ESignet",
"proxy_token_endpoint": "https://esignet.collab.mosip.net/v1/esignet/oauth/v2/token",
"credential_endpoint": "https://esignet.collab.mosip.net/v1/esignet/vci/credential",
"credential_type": [
"VerifiableCredential",
"MOSIPVerifiableCredential"
],
"credential_audience": "https://esignet.collab.mosip.net",
"client_alias": "mpartner-default-mimotooidc",
"additional_headers": {
"Accept": "application/json"
},
".well-known": "https://esignet.collab.mosip.net/.well-known/openid-credential-issuer"
},
"errors": []
}
DID Binding with did:web for kid generation: Introduced support for did:web and automated key ID (kid) generation to enable smooth VC issuance in SD-JWT format.
Revocation of VC
Searching VC to be revoked
Revoking VC through API
Support for VC Issuance with SD-JWT format
Enable Trust Element in VC Format (SD-JWT) Using did:web in iss Attribute
Issuing VC in SD-JWT Format
Enabling key manager to support did:web binding for VC signing
Data Integrity Proof
Support for W3C Data Integrity Proofs
Code Refactoring
Refactoring code to enhance the code quality of the application
Signing VC with ECC R1 Algorithm
Extending application’s capability of VC signing and providing support to sign with ECC R1 algorithm
DID integration for VC
Allows credentials to be cryptographically bound to a DID, ensuring stronger identity association and verifiability
Issue related to deploying Inji Certify with docker resolved
resolved issue related to VC issuance post the DB changes introduced as part of the new feature change
When credential config APIs used to add new credential type, we need to still update signature in git properties
aud in Access Token Uses containsAll Instead of contains
Certify doesn't give the @context of the VC it's downloading
VC download is failing with credential type "LifeInsuranceCredential"
VC download is failing with signature alg (ES256) supported values mentioned in well-known response
Incorrect representation of x5c field in JWT header
key manager
commons
esignet-mock-services
Addition/Configuration of Verifiable Credential Type via API post onboarding
Enabling issuer configure new VC types based on the requirement at any time
When configuring the VC type, ensure that the didUrl value in the config file matches the value sent through the API; otherwise, VC issuance will fail.
The VC Revocation feature is enabled by default for all VCs configured in Inji Certify. Configuration options to customise this will be introduced in an upcoming release.
VC Revocation and SD-JWT support are released as draft features. They are marked as draft since additional enhancements are still in progress to enable the complete end-to-end flow and to complete comprehensive regression testing.
Ed25519 signing of VC request – Scope from automation
Support of ECC k1 verification signature
eSignet 1.4.1 from released env
Test Rate: 100%, With Pass Rate: 96% and Fail Rate: 4%
Test Rate: 100%, With Pass Rate: 96% and Fail Rate: 4%
Test Rate: 100%, With Pass Rate: 96% and Fail Rate: 4%
Inji-certify-mock
mosipqa/inji-certify-with-plugins:0.11.x
Digital-credential-plugin - 0.4.0
Inji-certify-Insurance
mosipqa/inji-certify-with-plugins:0.11.x
Digital-credential-plugin - 0.4.0
Inji-certify- landregistry
mosipqa/inji-certify-with-plugins:0.11.x
Digital-credential-plugin - 0.4.0
Inji-certify- academic
mosipqa/inji-certify-with-plugins:0.11.x
Digital-credential-plugin - 0.4.0
Mdoc-mdl
mosipqa/inji-certify-with-plugins:0.11.x
Digital-credential-plugin - 0.4.0
Inji-config
Releasing from release-0.8.x branch
Digital-credential-plugin - 0.4.0
Keymanager
1.3.0-beta.2
Will be released as 1.3.0-beta.2
eSignet
eSignet-1.4.1
eSignet-1.5.1
1.5.1 eSignet from dev2 env
1.4.1 eSignet from released env
Total
Passed
Failed
NA
643
612
28
2
Total
Passed
Failed
Ignored
Known issues
225
61
0
155
Total
Passed
Failed
Ignored
Known issues
225
47
0
169
Total
Passed
Failed
Ignored
Known Issues
225
79
0
137
Module/Repo
Image
POM version
Dependent artifactID
Comments
Inji-certify-mosipid
mosipqa/inji-certify-with-plugins:0.11.x
Digital-credential-plugin - 0.4.0
Test Approach
Verified configuration
Feature Health
Test execution statistics
Functional test results
Note - Ignored scenarios are Not related to particular use case and 9 scenarios are known issues can be tracked from INJICERT-681, Mosip id use case is being ignored from Automation for the current release.
Detailed Test Metrics
Tested with Components
Test Rate: 99%, With Pass Rate: 95% and Fail Rate: 4.35%
9
9
9
ECCR1 signing of VC request
Did:key signing – scope from automation
Credential config APIs
DB upgrade scripts testing, Backward complatibility - from Docker setup
Sd_jwt format (Draft implementation)
Revocation feature (Draft implementation)
Test Rate: 100%, With Pass Rate: 90% and Fail Rate: 10%
Test Rate: 100%, With Pass Rate: 94.4% and Fail Rate: 5.6%
Test Rate: 100%, With Pass Rate: 94.6% and Fail Rate: 5.4%
Test Rate: 100%, With Pass Rate: 85.3% and Fail Rate: 14.7%
Inji-certify-mock
mosipqa/inji-certify-with-plugins:0.12.x
Digital-credential-plugin - 0.5.0
Inji-certify-Insurance
mosipqa/inji-certify-with-plugins:0.12.x
Digital-credential-plugin - 0.5.0
Inji-certify- landregistry
mosipqa/inji-certify-with-plugins:0.12.x
Digital-credential-plugin - 0.5.0
Mdoc-mdl
mosipqa/inji-certify-with-plugins:0.12.x
Digital-credential-plugin - 0.5.0
Inji-config
Releasing from release-0.10.x branch
Digital-credential-plugin - 0.5.0
eSignet
eSignet-1.5.1
Keymanager
As a library
1.3.0-beta.4(1.3.0-SNAPSHOT)
Getting release with branch name release-1.3.x
747
723
21
2
Test Rate: 99%, With Pass Rate: 97% and Fail Rate: 3%
442
72
0
336
34
Total
Passed
Failed
Ignored
Known issues
442
50
0
358
Total
Passed
Failed
Ignored
Known Issues
442
209
0
199
Total
Passed
Failed
Ignored
Known Issues
442
64
0
344
Inji-certify-mosipid
mosipqa/inji-certify-with-plugins:0.12.x
Digital-credential-plugin - 0.5.0
Test Approach
Verified configuration
Feature Health
Note:
For Esignet compatibility
eSignet 1.5.1 from released env
Docker compose testing – esignet from collab env by default
Test execution statistics
Functional test results
Note: Ignored scenarios are not related to particular use cases and 34 scenarios are known issues can be tracked from INJICERT-681, INJICERT-1118, INJICERT-1176
CSR generation for appid and refid to enable external CA signing and certificate upload to certify (except ES256K signature)
Postman readme changes in Docs (Docker compose)
Enabling of shedlock table
Inji-certify-mock
mosipqa/inji-certify-with-plugins:0.12.x
Digital-credential-plugin - 0.5.0
Inji-certify-Insurance
mosipqa/inji-certify-with-plugins:0.12.x
Digital-credential-plugin - 0.5.0
Inji-certify- landregistry
mosipqa/inji-certify-with-plugins:0.12.x
Digital-credential-plugin - 0.5.0
Mdoc-mdl
mosipqa/inji-certify-with-plugins:0.12.x
Digital-credential-plugin - 0.5.0
Inji-config
Releasing from release-0.10.x branch
Digital-credential-plugin - 0.5.0
eSignet
eSignet-1.6.1
Keymanager
As a library
1.3.0-beta.4(1.3.0-SNAPSHOT)
Total
Passed
Failed
NA
769
744
22
0
Total
Passed
Failed
Ignored
Known issues
442
72
0
336
Total
Passed
Failed
Ignored
Known issues
442
50
0
358
Total
Passed
Failed
Ignored
Known Issues
442
209
0
199
Total
Passed
Failed
Ignored
Known Issues
442
64
0
344
Module/Repo
Image
POM version
Dependent artifactID
Comments
Inji-certify-mosipid
mosipqa/inji-certify-with-plugins:0.12.x
Digital-credential-plugin - 0.5.0
Test Approach
Verified Configuration
Note:
Ignored scenarios are not related to particular use cases and 34 scenarios are known issues can be tracked from INJICERT-681, INJICERT-1118, INJICERT-1176
Functional Test Results
Automation Statistics
Note:
Ignored scenarios are not related to particular use cases and 34 scenarios are known issues can be tracked from INJICERT-681, INJICERT-1118, INJICERT-1176
Verification is performed not only from the end user perspective but also from the System Integrator (SI) point of view. Hence Configurability and Extensibility of the software are also assessed. This ensures the readiness of software for use in multiple countries. Since MOSIP is an “API First” product platform.
Testing scope has been focused on the below features:
Persona based approach has been adopted to perform the IV&V, by simulating test scenarios that resemble a real-time implementation.
A Persona is a fictional character/user profile created to represent a user type that might use a product/or a service in a similar way. Persona based testing is a software testing technique that puts software testers in the customer's shoes, assesses their needs from the software, and thereby determines use cases/scenarios that the customers will execute. The persona's needs may be addressed through any of the following.
Functionality
Deployability
Configurability
Customizability
The verification methods may differ based on how the need was addressed.
Verification is performed on configurations as mentioned below
Default configuration
English
Below are the test metrics by performing functional testing. The process followed was black box testing which based its test cases on the specifications of the software component under test. The functional test was performed in combination with individual module testing as well as integration testing. Test data were prepared in line with the user stories. Expected results were monitored by examining the user interface. The coverage includes GUI testing, System testing, End-To-End flows across multiple configurations. The testing cycle included the simulation of multiple identity schema and respective UI schema configurations.
Total
Passed
Failed
NA
311
303
6
0
Below are the detailed test metrics by performing manual/automation testing. The project metrics are derived from Defect density, Test coverage, Test execution coverage, test tracking, and efficiency.
The various metrics that assist in test tracking and efficiency are as follows:
Passed Test Cases Coverage: It measures the percentage of passed test cases. (Number of passed tests / Total number of tests executed) x 100
Failed Test Case Coverage: It measures the percentage of all the failed test cases. (Number of failed tests / Total number of test cases executed) x 100
UIN’s/VID’s generated with ID Repo were only used in verifying MOSIP ID, Reg-Client UIN were not verified.
The Sunbird registry was pointing to Sunbird dev.
Test execution statistics
Functional test results
Detailed Test metrics
Stories Tested
API + Docker compose testing
Tested with Components
Browser Versions Used For Testing
Ensures interoperability across systems and jurisdictions
Inji Certify allows a single issuer to manage and issue multiple types of verifiable credentials within the same ecosystem. This is especially useful for organizations running diverse programs or services under one authority.
Example scenarios:
A Transport Authority issuing both Driver's Licenses and Commercial Vehicle Permits
A University issuing Student ID Cards, Degree Certificates, and Transcript Credentials
A Health Department issuing Vaccination Certificates and Medical Practitioner Licenses
A Border Control Agency issuing Cross-Border Transport Passes and Work Permits
This flexibility ensures that one issuer can cater to multiple credentialing needs without managing separate systems or infrastructures.
Inji Certify enables issuers to expand their credential portfolio even after the initial onboarding, ensuring they can respond quickly to evolving program or policy needs. Through secure APIs, issuers can create and configure new credential types without system downtime or complex redeployments.
Key capabilities include:
Post-onboarding expansion of credential types to support new use cases
API-driven setup for fast and seamless integration into existing workflows
No infrastructure changes required, minimizing operational overhead
Access to comprehensive documentation and guidelines — (refer to thislinkfor details on configuring VC types).
Inji Certify provides issuers with the capability to generate verifiable credentials in multiple industry-accepted formats, ensuring broad interoperability across ecosystems, wallets, and verification systems. This flexibility makes it easier for organizations to adopt digital credentials without being locked into a single standard.
Currently supported formats:
JSON-LD Credentials — Standards-based credentials using Linked Data Proofs, widely adopted in decentralized identity ecosystems for interoperability and verifiability
Signed JWT (JWS) — Compact, JSON-based credentials that enable efficient transmission and verification across web and enterprise systems
SD-JWT (Selective Disclosure JWT) — Privacy-preserving credentials that allow holders to selectively disclose attributes while keeping the rest private, Note: With the Inji Certify 0.13.0 release we have included full Insupport for SD-JWT.
mDoc (ISO 18013-5/7) — A mobile document format for secure, offline-verifiable digital documents
mDL (ISO 18013-5/7) — A mobile driver's license format, enabling secure and convenient digital driver's license presentation on mobile devices
By supporting both current and emerging standards, Inji Certify ensures that credentials are secure, future-ready, and interoperable with a wide range of applications, wallets, and verification ecosystems.
Inji Certify ensures that every credential is protected through digital signatures, guaranteeing authenticity, integrity, and tamper resistance. To meet diverse ecosystem and compliance needs, it offers issuers the flexibility to choose from a wide range of cryptographic signing algorithms.
Key capabilities include:
Configurable Signing Algorithms — Issuers can select the signing algorithm of choice during credential setup
Supported Options — Includes RSA, Ed25519 (2018 & 2020 specs), and Elliptic Curve (ECC K1 & R1)
Enhanced Cryptographic Flexibility — Support for Ed25519 and ECC Curve ensures compatibility with modern secure systems, broader wallet ecosystems, and evolving standards
Standards Compliance — All signatures are interoperable and verifiable across wallets and verification systems
Security and Adaptability — Enables issuers to stay aligned with cryptographic best practices and adapt to regional or program-specific security requirements
This combination of efficiency, flexibility, and compliance ensures that credentials issued through Inji Certify remain future-ready, secure, and widely interoperable.
Inji Certify is built on a modular plugin architecture, enabling seamless integration with identity systems, registries, data sources, and third-party services. This design makes the platform highly flexible, customizable, and easy to adopt across diverse ecosystems while simplifying both implementation and testing.
Key plugin categories include:
These plugins are responsible for generating and signing verifiable credentials. They typically connect with external identity or authentication systems, obtain the required information, and issue the VC in compliance with global standards.
Currently supported issuance plugins:
Sunbird Plugin — Enables seamless integration with Sunbird-based services
Data Provider Plugins are responsible for fetching relevant data from external registries or data sources. The retrieved data is returned in JSON format and is used by Inji Certify to construct and issue the corresponding Verifiable Credential (VC).
The data source for these plugins can be a database, a CSV file, or an external API.
Currently supported Data Provider Plugins include:
Mock IDA Plugin — Provides a simulated identity data and verification environment for testing and development purposes
Mock CSV Data Provider Plugin — Enables data retrieval from CSV files, primarily for sandbox and test data simulation
PostgreSQL Data Provider Plugin — Connects to PostgreSQL databases to fetch real-time data from registries or external systems
— Integrates with MOSIP APIs to retrieve identity data and construct Verifiable Credentials within Inji Certify
For detailed instructions on configuring the Data Provider Plugin, please refer to this guide.
Issuers can easily integrate additional custom plugins by following the detailed guidelines provided in this link. This extensible plugin framework ensures that Inji Certify can adapt to unique organizational needs without heavy customization. To know more about this feature please refer to this link: VC Issuance vs Data Provider Plugin.
Inji Certify introduces an initial implementation of revocation to enhance the trust and reliability of Verifiable Credentials (VCs).
Capabilities include:
Revocation List — Maintains a list of revoked JSON-LD credentials
Revocation API — Allows issuers to mark JSON-LD credentials as revoked
Verification API — Enables verifiers to check whether a JSON-LD credential is valid or revoked
Discovery API — Provides access to the most up-to-date revocation list
This release establishes the foundation for a standardized revocation mechanism in Inji Certify, with broader credential format support planned in future iterations. Click here to know more about this feature.
Inji Certify includes an optional ledger that records every Verifiable Credential (VC) issued by the system. When enabled, this ledger provides a searchable index of issued credentials, making it easier for issuers to track, audit, and manage credentials throughout their lifecycle.
Why it matters: The ledger simplifies operations such as revocation, where the system must quickly locate the credential being revoked. With indexed search support, issuers can retrieve credentials efficiently without maintaining an external lookup system.
Key Capabilities:
Configurable Recording — Issuers can choose whether or not to maintain an internal record of all issued VCs.
Indexed Search — The ledger supports searching issued credentials based on predefined indexes, enabling faster retrieval.
Revocation Support — When revocation is enabled, the ledger must be active, unless the issuer provides an external system capable of performing credential lookup.
Considerations: If the issuer intends to use Inji Certify's built-in revocation workflow, the ledger feature must be turned on. Otherwise, the issuer is responsible for implementing their own mechanism to locate credentials during revocation.
Inji Certify provides support for SVG-based credential rendering, ensuring wallets can display visually consistent and branded representations of issued credentials.
Why it matters: With SVG rendering support powered by the renderMethod metadata and defined templates, Certify ensures that every credential not only carries trust and verifiability, but also a consistent, secure, and issuer-branded visual identity across all wallets.
How it works:
renderMethod in Metadata — Certify includes a renderMethod parameter within the credential metadata, instructing wallets on how the credential should be visually rendered
Key Benefits:
Consistent Branding — Logos, colors, and layouts can be issuer-defined, ensuring uniform credential presentation across different wallets
Scalable & Device-Friendly — SVG ensures high-quality rendering on any screen size, from mobile devices to large displays
Wallet Interoperability — By embedding the rendering method in the credential metadata, any compliant wallet can render credentials without custom logic
Flexible Output — Wallets can convert rendered SVGs into other formats (PNG, PDF) for sharing or offline use
Please refer this guide to know more about this feature.
Inji Certify provides support for integrating with external authentication services compliant with OAuth 2.0, such as eSignet, Keycloak, and others. This allows issuers to leverage existing identity and access management solutions seamlessly.
Why it matters: By supporting external authentication providers, Certify enables issuers to adopt the authentication mechanism that best fits their ecosystem requirements. This ensures flexibility, stronger security, and compliance with existing organizational standards.
How it works:
OAuth 2.0 Compliance — Certify connects with external authentication services that follow the OAuth 2.0 standard
Configurable Integration — Issuers can configure Certify to integrate with different authentication providers based on their needs (e.g., eSignet for government deployments, Keycloak for open-source identity management, or other OAuth 2.0 providers)
Seamless Authorization — Once integrated, the external service handles user authentication, and Certify issues credentials only after successful authorization
Key Benefits:
Flexibility — Issuers can choose and configure the authentication provider that suits their ecosystem
Customizable per Issuer — Different issuers can configure different authentication services within the same Certify deployment
Inji Certify supports the use of externally issued, CA-signed certificates for credential signing, enabling issuers to integrate their own public key infrastructure (PKI) into the credential issuance workflow.
Key Benefits
Trust Alignment — Credentials are signed using the issuer’s own CA-backed certificates, reinforcing alignment with local or institutional PKI policies.
Greater Adoption Flexibility — Countries and organizations can adopt Certify without restructuring their existing certificate management models.
Seamless Compliance — Using a recognized CA certificate simplifies audits and compliance checks by matching established trust and governance frameworks.
End-To-End Security — The signing process remains fully managed through the Key Manager, ensuring secure key handling while maintaining issuer-specific trust anchors.
For deeper insights into certificate and key lifecycle handling, see the documentation on the Role of the Key Manager in Certify.
Inji Certify have capability to issue VC in multiple language based on the configuration done by issuer. During the VC type configuration, VC schema can be defined in multiple languages. While issuing the VC, based on the preferred language of the user, VC will be issued in that particular language.
Inji Certify introduces support for an additional issuance mode called Presentation During Issuance, enhancing trust and security in credential issuance workflows.
In this mode, the issuer requests the presentation of an existing Verifiable Credential (VC) from the wallet as part of issuing a new VC. The submitted presentation is verified internally by Inji Certify, and upon successful verification, the issuance of the new VC is triggered and delivered to the wallet.
This feature strengthens security, trust, and interoperability and is typically enabled using protocols such as OpenID4VCIand standards like Presentation Exchange.
Capabilities include:
Presentation Request — Ability to request the presentation of an existing VC from the wallet
Presentation Verification — Internal verification of the submitted VC presentation
Conditional Issuance — Automatic issuance and delivery of a new VC upon successful verification
'Inji Certify 0.14.0 Release' lays the groundwork for advanced, trust-based issuance flows in Inji Certify, enabling richer and more secure credential ecosystems.
With this feature, Inji Certify can generate verifiable credentials that are encoded into CBOR Web Token (CWT) form and delivered through QR codes compliant with Claim 169 specifications — a specification for embedding identity data in QR codes that supports compact, secure, and machine-readable representation of credential data.
This capability allows wallets and other consumer applications to request and obtain credentials by scanning a Claim 169-formatted QR code, improving usability in offline or low-connectivity environments and ensuring alignment with an interoperable QR standard.
Capabilities include:
Claim 169 QR Generation — Ability to encode issued VCs into Claim 169–compliant QR codes
CBOR-CWT Encoding — Support for compact, privacy-preserving CBOR Web Token encoding of VC data
Standard-Based Issuance — Delivery of QR-encoded credentials that adhere to global standards for machine-readable identity
'Inji Certify 0.14.0 Release' expands Inji Certify’s issuance modalities to include QR code–centric workflows using standardised Claim 169 structures, enhancing accessibility and interoperability with ecosystem wallets and verification tools.
This feature implements the OpenID4VCI pre-authorized code flow, where Inji Certify can issue a credential offer containing a pre-authorized code that the wallet uses to obtain an access token and then request a VC — without requiring the end user to re-authenticate during the issuance process. This flow is ideal for scenarios where the issuer has already verified the user’s identity and wants to simplify credential delivery.
With this enhancement, credential offers can be delivered via QR codes, deep links, or other channels, and wallets can redeem them with or without an additional transaction code (PIN).
Capabilities include:
Pre-Authorized Credential Offers — Generate offers that embed a pre-authorized code to streamline issuance.
Standards-Based Flow — Implements the OpenID4VCI flow for credential offer redemption and issuance.
Flexible Delivery — Support for multiple delivery methods such as QR codes and deep links.
Transaction Code Support — Optional support for requiring a PIN/transaction code during credential redemption.
'Inji Certify 0.14.0 Release' enhances Inji Certify’s interoperability with OpenID4VCI ecosystems and improves the user experience for VC issuance in trusted workflows.
The kotlin library has been added to your project.
Download swift artifact (ios-tuvali-library) from the repository.
Open your project in XCode.
Goto File > Add Package Dependencies.
Select Add Local option.
The swift library has been added to your project.
Before we understand how Tuvali works, let's go through BLE communication.
In BLE communication, one device is designated as Peripheral and another one designated as Central.
Peripheral can perform advertisement which can be read by a Central device and connected to it, if the advertisement is connectable.
Once the connection is made, Central can perform further actions on the device like
discovering services and characteristics
subscribing to notifications on characteristics
write/ read data from characteristics
While peripheral can perform actions like
sending notifications to subscribed characteristics
respond to read requests from Central
The above diagram explains the sequence of actions for BLE communication in general.
Advertisement from Peripheral
Connection establishment & additional data exchange
Service & Characteristic discovery from Central
More details about other BLE terminology used here can be found in standard BLE specifications of 4.2 and above.
Note: Tuvali is supposed to implement OpenID for VP over BLE specification. As part of it, both VP request and response transfer should be implemented. However the current version of Tuvali only transfers VC from Central to Peripheral.
In the case of Tuvali, the entire VC transfer flow can be divided into the following stages
Connection Setup & Cryptographic key exchange
Data transfer
Connection Closure
Steps 1 to 6 mentioned in the above diagram explain how the first stage is achieved. Before even the advertisement is started, the peripheral generates a 32-byte public key. This public key is sent to Central in two parts. The first part will have 5 bytes of the public key sent as part of the advertisement payload and while the second part is sent as part of SCAN_RESP.
Since the advertisement from Peripheral is of connectable type, Central would send out a SCAN_REQ on receiving the advertisement and gets the remaining 27 bytes of the peripheral public key. Post that, Central would derive a public key pair and send its 32 bytes public key on Identify characteristic of Peripheral.
Once the public keys are exchanged between Central and Peripheral, a set of keys are derived on both sides which would be used for encryption and decryption of data on the wire.
Cryptographic Algorithm usage:
Ephemeral Key Pair is generated from X25519 curve
Key Agreement uses ECKA-DH (Elliptic Curve Key Agreement Algorithm – Diffie-Hellman) as defined in BSI TR-03111
Wallet and Verifier derives respective keys using HKDF as defined in RFC5869
Steps 7 to 11 mentioned in the above diagram explain how the second stage is achieved. Before VC is transferred, Central performs encryption and compression and communicates the resultant data size by writing to Response Size characteristic to Peripheral. The actual data transfer would happen on Submit Response characteristic.
Since the maximum allowed write value for a characteristic is limited to 512 bytes. The actual VC data is split by a component called Chunker into multiple smaller chunks. After the split, the data is transferred on the Submit responsecharacteristics one after another until all chunks are completely sent.
Peripheral on the other hand, receives data on the Submit response characteristic. The received chunks are collected and the final VC is assembled by a component called Assembler.
At the end of sending one frame of data from Central. It would request a transfer report via Transfer report request characteristic. Peripheral response with a summary of missing/corrupted chunks sequence numbers via another Transfer report summary characteristic.
Central would read the Transfer report summary to understand if the Peripheral received all the chunks properly. If the summary report has at least one chunk sequence number. Central would send those specific chunks to the Peripheral which is called the Failure frame.
The failure frame will be sent from Central repeatedly until the Transfer report summary is successful. If during the process, Central reached the maximum allowed failure frame retry limit, the transfer is halted, devices will be disconnected and an error is generated (Please refer to API documentation on how this error can be read).
Gzip is the Compression algorithm used with default compression level
Each chunk have 2 bytes of CRC-16/Kermit added. Parameters for the same are: width=16 poly=0x1021 init=0x0000 refin=true refout=true xorout=0x0000 check=0x2189 residue=0x0000 name="CRC-16/KERMIT"
On a successful data transfer
On non-recoverable error occurred on Peripheral
Peripheral notify Central to perform disconnection via Disconnect characteristic mentioned in Step 12 of the above diagram.
Central also performs disconnect in the following scenarios:
On a successful data transfer
Non-recoverable error on Central
Peripheral is out of range/ disconnected
As part of connection closure, both central and peripheral clean the held resources, cryptographic keys, and Bluetooth resources, to ensure that the subsequent transfer happens smoothly.
Note: All the cryptographic keys generated/ derived are used only for a single VC transfer session. The library strictly ensures they are not re-used in subsequent VC transfers post connection closure.
Current Supported Stages: CON(Connection) | KEX(Key Exchange) | ENC(Encryption) | TRA(Transfer) | REP(Report) | DEC(Decryption) | UNK (Stage is unknown) Current Component+ Role Combinations: TVW(Tuvali+Wallet) | TVV(Tuvali+Verifier) | TUV(Tuvali where role is unknown)
List of Supported Error Codes:
UnknownException: TUV_UNK_001
WalletUnknownException: TVW_UNK_001
CentralStateHandlerException: TVW_UNK_002
Possible error scenarios:
During VC transfer, if there is a failure in the transfer of more than 70% of the data we get an exception on the verifier side and it disconnects from the wallet.
After the verifier and wallet establish a connection, the wallet initiates an MTU negotiation with the verifier. If the negotiated MTU is less than 64 Bytes, then the verifier throws an exception and disconnects from the wallet.
If the verifier receives the size of the VC as 0, it raises an exception and disconnects from the wallet.
Possible error scenarios:
After the verifier and wallet establish a connection, the wallet initiates an MTU negotiation with the verifier. If the wallet is unable to negotiate the MTU with the verifier, it raises an exception and disconnects from the verifier.
During VC transfer, if the transfer cannot be completed within the specified limit of retries, the wallet raises an exception and disconnects from the verifier.
After the wallet sends all the chunks, it requests a transfer report. If the wallet is not able to send the request, it raises an exception and disconnects from the verifier.
Below are the exception message and the disconnect message which appears on the screen during the error.
This message is displayed on the device throwing the exception.
This message is displayed whenever a device gets disconnected.
Backoff Strategy: Exponential Backoff is a technique that retries a failing operation, with an exponentially increasing wait time, up to a maximum retry count(MAX_RETRY_LIMIT) or maximum backoff time(MAX_ELAPSE_TIME).
Initially, it starts with 2 ms as wait time (INITIAL_WAIT_TIME) and increases exponentially with each failure until the count reaches MAX_EXPONENT after which the wait time becomes constant (INITIAL_WAIT_TIME ^ MAX_EXPONENT).
BLE Service Discovery: After the connection is established, the central attempts to discover all the services hosted by the peripheral. If it fails to discover our service, then the exponential backoff-based retry will kick in. Here are the values:
MAX_ALLOWED_DATA_LEN (509 Bytes): Maximum data length allowed for one write for both wallet and verifier.
MIN_MTU_REQUIRED (64 Bytes): Minimum number of bytes required to share public key transfer of the wallet is 46. In order not to operate in edges, we chose the nearest value in the power of 2 i.e., 64.
MAX_FAILURE_FRAME_RETRY_LIMIT (15): Maximum limit to retry sending failure chunks to the verifier.
IDENTIFY_REQUEST_CHAR_UUID (00000006-5026-444A-9E0E-D6F2450F3A77): Characteristic for sending the public key of the wallet.
REQUEST_SIZE_CHAR_UUID (00000004-5026-444A-9E0E-D6F2450F3A77): Characteristic for requesting VC size by wallet from verifier.
REQUEST_CHAR_UUID (00000005-5026-444A-9E0E-D6F2450F3A77): Characteristic for requesting the VC by the verifier.
SERVICE_UUID (00000001-0000-1000-8000-00805f9b34fb): Service UUID of the verifier
SCAN_RESPONSE_SERVICE_UUID (00000002-0000-1000-8000-00805f9b34fb): Service UUID for uniquely identifying the scan response data to the wallet's SCAN_REQ
Encryption/Decryption uses AES-256-GCM (192) (GCM: Galois Counter Mode) as defined in NIST SP 800-38D
Destroy Connection API
WalletTransferHandlerException: TVW_UNK_003
VerifierUnknownException: TVV_UNK_001
PeripheralStateHandlerException: TVV_UNK_002
VerifierTransferHandlerException: TVV_UNK_003
InvalidURIException: TVW_CON_001
MTUNegotiationException: TVW_CON_002
ServiceNotFoundException: TVW_CON_003
TransferFailedException: TVW_REP_001
UnsupportedMTUSizeException: TVV_CON_001
CorruptedChunkReceivedException: TVV_TRA_001
TooManyFailureChunksException: TVV_TRA_002
MAX_RETRY_LIMIT is 5 for Android and 10 for IOS
MAX_ELAPSE_TIME is 100 ms
MAX_EXPONENT is 5
Request Transfer Report [only for iOS]: After the wallet writes all the chunks to the verifier, it requests the transfer report. If the transfer report request write fails, then the exponential backoff-based retry will kick in. Here are the values:
MAX_RETRY_LIMIT is 5
MAX_ELAPSE_TIME is 100 ms
MAX_EXPONENT is 5
Dynamic MTU negotiation:
Android: After the connection is established, the wallet initiates an MTU negotiation with an initial value of 512 bytes. If it fails, it retries with 185 and 100 bytes subsequently with a wait time of 500 ms each. If the negotiation fails after all retries, it throws an exception and disconnects from the wallet.
iOS: iOS kicks off an MTU exchange automatically upon connection
RESPONSE_SIZE_CHAR_UUID (00000007-5026-444A-9E0E-D6F2450F3A77): Characteristic for sending VC size to the verifier.
SUBMIT_RESPONSE_CHAR_UUID (00000008-5026-444A-9E0E-D6F2450F3A77): Characteristic for sending the entire VC.
TRANSFER_REPORT_REQUEST_CHAR_UUID (00000009-5026-444A-9E0E-D6F2450F3A77): Characteristic for requesting for transfer report from the verifier.
TRANSFER_REPORT_RESPONSE_CHAR_UUID (0000000A-5026-444A-9E0E-D6F2450F3A77): Characteristic for sending transfer report to the wallet
VERIFICATION_STATUS_CHAR_UUID (00002037-0000-1000-8000-00805f9b34fb): Characteristic for informing the wallet if the VC is accepted or rejected.
DISCONNECT_CHAR_UUID (0000000B-5026-444A-9E0E-D6F2450F3A77): Characteristic for notifying the wallet to initiate the disconnection between the devices.
Installation:
Usage as a Kotlin library (for native android)
Usage as a Swift library (for native ios)
How does BLE Communication work?
How Tuvali works with BLE to transfer VC from Central to Peripheral
1. Connection Setup & Cryptographic key exchange
2. Data transfer
3. Connection closure
Disconnect initiated by Peripheral:
Disconnect initiated by Central
Error Codes And Error Scenarios:
Error Scenario 1: The verifier receives a Failed to transfer message and wallet receive a Disconnected message on the screen.
Error Scenario 2: The wallet receives a Failed to transfer message and the verifier receives a Disconnected message on the screen.
The scope of testing is to verify fitment to the specification from the perspective of Functionality, Configurability and Customizability. Verification is performed not only from the end-user perspective but also from the System Integrator (SI) point of view. Hence, the Configurability and Extensibility of the software are also assessed. This ensures the readiness of the software for use in multiple countries and diverse identity ecosystems.
Overview and Scope
Testing scope has been focused on the following features:
Insurance, MosipId and Mock (Issuance and Data provider (Postgres plugin)), which covered Land registry, school and Farmer use case
Integration with Inji Web and Inji verify
DB upgrade scripts testing, Backward compatibility - from Docker setup
Preauthcode
Presentation during issuance
Claim 169
Mdoc mdl format
The Functional verification of the Inji Mobile Wallet application is performed on Android and iOS platforms to ensure alignment with product specifications and business requirements. Analyzed with respect to functional stability, data integrity, and UI consistency. The validation adopts a persona-based testing strategy, simulating real-world user scenarios across diverse device matrices and multi-language configurations to ensure robustness in both online and offline environments.
Functionality
Combination
Configurability
Customizability
Table: Test Organization
Name
Functional Role
Responsibilities
Data Readiness: Validate the availability of all services along with configured identity schemas (UIN/VID) to authentication flows.
Table: Test Environment
Images (qa-inji1 env)
Images (released env)
Manual Test Execution was completed in qa-inji1 env achieving a 100% execution rate for all planned scenarios. The testing validated core functionalities with a high pass rate, while identified issues on both platforms have been logged for defect resolution.
Table: Test Execution Summary
Total
Pass
Fail
Skip
Total
Passed
Failed
Ignored
Known issues
Total
Passed
Failed
Ignored
Known issues
Total
Passed
Failed
Ignored
Known issues
Total
Passed
Failed
Ignored
Known issues
Total
Passed
Failed
Ignored
Known issues
Total
Passed
Failed
Ignored
Known issues
Total
Passed
Failed
Ignored
Known issues
The following table depicts only the bugs which are found and not addressed in the current release.
Table: Defect Metrics for the Release
Blocker
Critical
Major
Minor
Total
This section summarizes the key findings of test execution. It also provides a final QA recommendation on the build's readiness for release. The functional verification for Inji certify release version 0.14.0 has been successfully completed. The testing cycle achieved a 100% execution rate with a 97% pass rate across a total of 880 test cases. Additionally, API automation achieved an average of 95% across different use cases.
While there are 18 open defects (14 Major, 4 Minor) and as known issues, there are zero blocker defects that are open. Testing has demonstrated functional stability and data integrity consistent with product specifications.
The build has successfully met the defined exit criteria and is recommended for release. The approval is based on the following satisfied conditions:
Test Case Execution Completion: 100% of planned scenarios executed.
Defect Status: No Blocker defects remain open.
Documentation Sign-off: Reports are finalized.
Test Environment Stability: The test environment remained stable throughout the execution cycle.
Table: Report is signed off details
Name
Functional Role
Responsibilities
This includes additional reference information for the report. It contains a history of document versions and a list of acronyms and their meanings.
Version
Date
Author
Reviewers
Acronym
Literal Translation
It outlines the strategy used to ensure a comprehensive evaluation.
Version
Author
Date
Review
Affected Sections
Refer to the github link for more on reports .
Ragini Krishna
Senior QA Manager
High-level governance and executive reviews of reports and execution.
To perform offline sharing using BLE, we recommend below:
Devices with Bluetooth v4.2 and above
Android v23 and above for Android
The below sections describe the steps for building the android application in Mac and Windows OS.
Configure Node & npm (recommended to use v16.19.0)
Configure Yarn
Configure Gradle & Java
Configure Expo, refer .
Configure Android SDK, refer .
Configure environment variables in your ~/.zshrc / or ~/.bashrc (depending upon your shell)
Generate debug keystore for building debug build.
Export keystore
Install Git
Use the below link to download git
After installation, run Git as admin.
Install SDKMAN
Use the below command in Git terminal
If you encounter an error while installing sdkman, please install zip on your system using your favourite package manager.
Install zip
SDKMan requires the installation of the zip utility, which is not included in the default installation of Windows Git Bash.
To address this, please visit the .
Locate zip in the list of available files and download the zip-3.0-bin.zip archive. Extract the zip.exe file from the archive and place it in the bin folder. Location of bin folder C:\Program Files\Git\usr\bin
Install gradle
Use the command below in Git terminal.
To check the installed gradle version.
gradle -V
Install Java JDK, refer .
Install expo
Install Android SDK, refer .
Install Node, refer .
Install nvm
or
update the nvm version
Install adb
Configure ANDROID_HOME and JAVA_HOME in system environment variables
Clone Inji repository.
Create an android/local.properties file with the following data:
Alternatively, you can open the Android folder in the android studio. It will create local.properties file with sdk.dir = <location-of-the-android-sdk>.
Note:
Default path for MacOS: /Users/<username>/Library/Android/sdk
Default path for Linux: /home/<username>/Android/Sdk
Inji application currently supports two themes: gradient and purple.
The default theme of the app is gradient.
To change the theme of the application, go to .env file and change the value of APPLICATION_THEME to purple
Update mimoto url as https://api.collab.mosip.net
Update esignet host as https://esignet.collab.mosip.net
To deploy mimoto in local refer
Go to the root folder of the project in the terminal.
Install all the dependencies using npm install.
Build and run the application on the device:
Run npm run android:mosip to build and install the application on the device.
Run npm run android:mosip --reset-cache to build and install the application if any change is made in the .env file.
If you encounter the below issue on Windows,
Run npm i expo-modules-autolinking@~1.1.0 and rebuild the app
Path for debug apk in Inji directory android/app/build/outputs/apk/mosip/debug
Creating A Google Cloud Project Refer to this documentation on setting up a Google Cloud Project - https://developers.google.com/workspace/guides/create-project
Enabling Google Drive APIs Go to - https://console.cloud.google.com/apis/library
Search for Google drive API and Select Google Drive API from the list.
Then enable the API.
Create Google Consent Screen
Go to - https://console.cloud.google.com/apis/credentials/consent
Create a new Consent Screen with necessary details such as - App Name, User Support Email, App Logo and Developer Info. Once added these details Save and Continue.
Create Oauth Client ID
Go to - https://console.cloud.google.com/apis/credentials
Click on CREATE CREDENTIALS and choose OAuth client ID
Choose Appliation type as Android
Add in details such as Name, Package Name and SHA- Fingerptint
Note:
SHA-1 should be of the keystore generated for signing the APK
Make sure you have checked Custom URI Scheme in Advanced Settings
Set Environment Variable
Once the Client ID has been created copy the client ID and add it as part of .env file.
GOOGLE_ANDROID_CLIENT_ID="<copied-client-id>"
The Internal testing version of the build can be uploaded to PlayConsole for testing. PlayConsole allows the creation of internal testers group.
Publishing build manually to PlayConsole
A Google play console developer account is a must to publish builds in PlayConsole.
Set the backend URL and choose a theme (orange | purple) inside the .env file.
Build the Apk or App bundle.
Login to PlayConsole and create a new release inside Internal testers.
Upload in PlayConsole
Once the build is uploaded and saved you will be able to see the status of the release with version name, code, API level and some more details.
Select the testers group you want to share with. Once saved, you can copy the link and share the same with the testers to test the APK or App bundle.
You are required to manually share the link with the testers as they will not receive any notifications when a new build is uploaded.
Publishing build via Github actions (Automation) to PlayConsole
A Google PlayConsole developer account must be configured to Inji to publish builds via PlayConsole.
Testers must be added to internal testers group in Play console.
To deploy the Android build to PlayConsole, select Android Custom Build workflow from github actions.
Choose the branch, backend url, theme and describe about build details.
Click the Run workflow button.
Once the pipeline has done with building the app (takes around ~25-30min), you need to login to PlayConsole and verify the build version name and code in the internal testers track.
Note: Only those who are registered in the selected testers group will be able to download the App from Google Play.
The below section describes the steps build the iOS application.
Follow the to configure Node & npm, Expo and generate debug keystore
Configure XCode, refer .
Enable iCloud and create Containers, refer https://developer.apple.com/help/account/manage-identifiers/create-an-icloud-container/
Install all the dependencies
Run Metro bundler in the background
Run Inji directly to a connected device Command to run on simulator
Command to run real device
The beta version of the build can be uploaded to TestFlight for testing. TestFlight allows the creation of internal and external testing teams who will be notified once a new build is published.
Publishing build manually to TestFlight
An Apple developer account is a must to publish builds in TestFlight.
Set the backend URL and choose a theme (orange | purple) inside the .env file.
Archive the build using xcode.
Upload the archive to Testflight.
First choose Distribute App.
Upload in TestFlight
Login to TestFlight and check for the build upload status. Once the build is uploaded successfully, add Groups to provide access to testers.
All the group members will be notified about the new build. Open TestFlight and install the new version.
Publishing build via Github actions (Automation) to TestFlight
An Apple developer account must be configured to Inji app to publish builds via TestFlight.
Testers must be added to group in TestFlight.
To deploy the iOS build to testflight, select Inji iOS build workflow from github actions.
Choose the branch, backend URL, theme, testers group from TestFlight to get the build and describe about build details.
Click the Run workflow button.
Once the pipeline has done with building the app (takes around ~25-30min), TestFlight notifies corresponding testers associated with the testers group in email about deployed build details.
.
Finally, rerun the SDKMan installation script.
Default path for Windows: C:\Users\<username>\AppData\Local\Android\sdk
or
orange
to apply gradient theme
The APK signing keystore needs to be unchanged for backup feature to work as the SHA-1 is 1-1 mapped for a client ID created
Upload the Apk or App bundle to PlayConsole.
Now, you can share the link to testers.
brew install nvm
nvm install 16.19.0
nvm use 16.19.0
**FAILURE:** Build failed with an exception.
**Where:**
Script 'C:\....\inji\node_modules\expo\scripts\autolinking.gradle' line: 2
**What went wrong:**
A problem occurred evaluating script.
> Could not read script 'C:\"PATH"\inji\node_modules\expo\scripts\android\autolinking_implementation.gradle' as it does not exist.
npm install
npx pod-install
npm start
npm run ios
npm run ios -- --device
Android - Build and Run
1a. Installation and Keystore generation on MAC
Step 1:
Step 2:
Step 3:
Step 4:
Step 5:
Step 6:
1b. Installation and Keystore generation on Windows
Step 1:
Step 2:
Step 3:
Step 4:
Step 5:
Step 6:
Step 7:
Step 8:
Step 9:
2. Command to build the application
Step 1:
Step 2:
Step 3:
Step 4:
Step 5:
Step 6:
3. Troubleshooting
4. Setting Up Google API Services and Client ID for Data backup & Restore
Here we present the Inji-Stack product roadmap for 2026 and our strategic horizon forward. This roadmap outlines the planned features, progress, and release details for Inji Stack.
The annual product cycle for the Inji Stack begins in January and concludes in December.
For detailed module-wise roadmaps, please refer to the respective sections; Inji Wallet (, ), and .
Q2
Localization
🟢 Completed
Q2
Responsive View
🟢 Completed
Q2
Theme customization
🟢 Completed
Q2
Tech Upgrades:
Movement from Material UI to Tailwind
Conversion of JS to TS
🟢 Completed
Q2
QR Code in PDF
🟢 Completed
v0.10.0
Q2
Online Sharing
🟢 Completed
v0.10.0
Q3
Secure time bound storage
🟢 Completed
v1.0.0
Q3
Performance Testing
Moved to 2025
NA
Q3
Security Testing
Moved to 2025
NA
Q3
Web UI enhancements:
Home Page
svg template in PDF
Moved to 2025
NA
Q4
User login, VC management, profile management (profile menu)
Moved to 2025
NA
Q4
VC Validation & Verification
Moved to 2025
NA
Q4
OpenID4VCI enhancements
Moved to 2025
NA
Q4
Categorization of issuers
Moved to 2026 & Beyond
NA
Q4
mDoc/mDL & CBOR VC download
Moved to 2026 & Beyond
NA
Q2
Inji Certify - Base code v0.9
Publish as an independent module (VCI + C)
VCI segregation from eSignet and moving to Inji Certify.
Plugin Support :
Completed
Q3
Movement to Data Model 2.0
Completed
v0.10.0
Q3
OpenID for Verifiable Credential Issuance - draft 13 Spec
Pre-Authorized Code Flow
Credential Offer End Point
Completed
v0.10.0
Q3
VC Generation: Create Credentials from the Request Payload
W3C VC Issuance API
Moved to 2025
v0.10.0
Q3
Simplify the process of onboarding an issuer for a single entity
Moved to 2025
v0.11.0
Q3
Multi-tenancy: Onboarding of multiple issuers
Moved to 2025
v0.11.0
Q3
Persistent store for credentials
Pre-generated credentials
Credentials Registry (Hosted Infra)
moved to 2025
v0.11.0
Q4
Issue a physical credential (PDF / Printable)
Support PDF or other formats of presentation based on plugins - PDF, PCF, PKPASS
Moved to 2025
v0.11.0
Q4
Vault Integration - Key manager support
Moved to 2025
v0.12.0
Q4
Vault - Key management
Moved to 2025
v0.12.0
Q4
Revocation Mechanism
Moved to 2025
v0.12.0
Q4
Discovery and Metadata
DNS based Well Known specifications for publishing PK, Schema, credential types and other meta data (Proposed by MOSIP and included in standards)
Moved to 2025
v0.12.0
Q4
Allow Bulk/Batch Issuance
Issue certificates from an existing database
Moved to 2025
v0.12.0
Q4
Deferred Credential Endpoint
OpenIDVCI - Draft 13
Moved to 2025
v0.12.0
Q4
Inji Certify - Beta 1 - LTS
Deprioritised
v1.0
Q1-Q4
Extend Credentials
Ability to issue extension on existing credential
Moved to 2025
Depriortized
Q1-Q4
Credential Correction
Support to retire the old credential and issue the new credential
Moved to 2025
Depriortized
Q1-Q4
Credential Formats Support - Selective Disclosure - Support SD JWT
Moved to 2025
Depriortized
Q1-Q4
[Credential Formats Support - Support mDocs
Moved to 2025
Depriortized
Q1-Q4
Business models (central, third-party SaaS, self-hosted)
Moved to 2025
Depriortized
Q2
UI/UX Enhancements based on GenderMag
Completed
Q2
Mobile Responsive Version - Upload and Scan feature
Completed
Q2
Material UI to Tailwind
Completed
Q2
Bug Fixes
Completed
Q3
Request Credential - OpenIDVP - OVP Flow
Completed
Q3
Docker Compose
Completed
Q4
Support for Country QR code - CWT Format
Completed
Q4
Verification SDK
Completed
Q4
Displaying Issuer Details post validation on UI
Completed
Q4
Multi-lingual UI Support - Localization
Completed
2025
Templatizing post-VC verification on Inji Verify(Render)
Moved to 2025
Depritoritized
2025
Receive Credentials
(QR-based Verifiable Presentation)
Moved to 2025
Depritoritized
2025
VP requestor SDK
Moved to 2025
Depritoritized
2025
Consume Data from credential
Moved to 2025
Depritoritized
2025
Production Ready - Inji Verify - LTS Release 1.0.0
Building a trust-first digital wallet experience simplified sharing, enhanced protection, and frictionless verification for every user, everywhere.
Inji Mobile Wallet’s 2026 vision is to evolve into a fully interoperable, standards-aligned verifiable credential wallet that is secure, user-centric, and future-ready. The roadmap focuses on strengthening foundational capabilities—OpenID4VP & VCI final spec compliance, advanced cryptographic support (ECC R1, BBS+), unified key management, profile creation, and end-to-end revocation across all major VC formats (SD-JWT, JWT, mDoc). These upgrades ensure the wallet remains globally interoperable while meeting the needs of governments, implementers, and ecosystems adopting Inji.
We aim to deliver a highly reliable and scalable wallet that supports cross-platform verification, richer offline and BLE capabilities, multi-format rendering (SVG, PDF), and enhanced privacy models.
We will be able to introduce strategic features such as Shamir’s Secret Sharing for key recovery, BLE enhancements for iOS↔iOS, mDoc revocation, and a dedicated iOS verification library later during the year. Longer-term (2027+) innovation tracks explore multi-user credentials, one-time/bulk credential patterns, consent management, DIDComm, anonymous credentials, and multi-tech-stack portability—setting the foundation for Inji as a universal, secure, and inclusive digital credential wallet for global public infrastructure.
Inji Web
Vision
The vision for the Inji Web roadmap is to build a secure, interoperable, and user-friendly web wallet that fully supports the next generation of global verifiable credential standards. By introducing capabilities such as W3C Data Model 2.0, SD-JWT, mDoc/mDL, revocation, credential refresh, profile management, delegated access, and offline/USSD-based sharing, Inji Web aims to offer citizens and organizations a trusted platform to receive, manage, and present credentials across diverse digital ecosystems. With enhanced privacy features like BBS+ and seamless integration with identity providers and verifier services, Inji Web will evolve into a comprehensive, inclusive, and scalable wallet experience suitable for national-level deployments and cross-sector use cases.
Inji Certify
Vision
In 2026, Inji Certify will be a globally trusted, standards-aligned digital credential issuance platform enabling secure, interoperable, and scalable verifiable credentials across ecosystems. By supporting universal credential formats, OpenID4VCI v1.0, advanced cryptography, and a robust multi-issuer architecture, Certify will simplify adoption for large-scale government and enterprise deployments. Alongside delivering policy-ready issuance, revocation, and trust framework integrations, the platform will prioritize clearing technical debt and strengthening security, maintainability, and operational reliability—ensuring Certify remains a future-ready, developer-friendly backbone for privacy-preserving digital credentials worldwide.
Inji Verify
Vision
By 2026, Inji Verify aims to become a universal, multilingual, and highly interoperable verification platform supporting all major credential formats including W3C JSON/JWT VCs, IETF JWT/SD-JWT, mDoc/mDL, MOSIP UIN VCs, and advanced revocation with multiple status lists backed by decentralized trust through KERI, DEDI, and global trust registries. It plans to deliver rich, branded verification outputs through SVG and PDF templatising, multi-language rendering, and support for multiple QR formats.
Verification experiences aims to be seamless across online, offline, and proximity-based scenarios with OpenID4VP and OpenIDVP same-device flows, BLE presentations, offline SDKs, and server-side ECC-R1 verification.
Inji Verify plans to expand platform reach through native Android/iOS apps and broad framework-compatible SDKs, making it a secure, accessible, future-ready, and developer-friendly global standard for credential verification.
Important: We are in the process of updating screenshots and content in the End User Guide to reflect our new branding. These updates will be available soon, thank you for your patience!
This document serves as a concise user guide for end users, providing comprehensive information on the features and functionalities offered by Inji Wallet.
Installing Inji Wallet
The below sections explain the steps for installing the Inji Wallet application on Android and iOS platforms.
On Android device
To install the Inji Wallet app on an Android smartphone, click here to get the Inji Wallet apk file for installation.
Transfer the apk file onto the smartphone on which it is to be installed.
Click on the apk file and follow the OS installation instructions.
Install the test flight app on your device.
Follow the steps mentioned .
The below screenshots explain the next steps after you get access.
After installation when you launch the app for the first time:
Select the preferred language.
You can read though a five-page tutorial for the Inji Wallet which is presented.
Choose a secure login method to enter the app (Biometric / PIN). This can be achieved through a PIN or the device's Biometrics (such as fingerprint or facial recognition). Once the setting is done you will be directed to the app's home page.
Inji Wallet supports VC downloads using eSignet as the authorization layer. Some of the available use-cases include:
Download National ID (MOSIP VC)
Download Insurance VC
And many more use-cases available to explore via eSignet!
Download credentials using UIN / VID:
On the home page, a plus "+" symbol will display the list of issuers from which you can download VCs.
Select the issuer that states National Identity Department and choose a credential type (MOSIP National ID). Once clicked, the browser will open and take you to the eSignet page.
On the authorization page (eSignet page), the user has to enter the UIN / VID and provide the OTP sent to the registered mobile number/email.
Download credentials using KBI:
A plus "+" symbol on the home page will display the list of issuers from which you can download VCs.
Select the issuer that states Stay Protected Insurance and choose a credential type (Health Insurance, Life Insurance). Once clicked, the browser will open and take you to the eSignet page.
On the authorization page (eSignet page), the user has to enter the Policy Number, Full Name, and Date Of Birth(D.O.B).
Once we click on the downloaded VC on the Home Page, the detailed view opens up for the VC.
Users can see all the details of the National ID in the detailed view. In addition, the user can access the quick access menu (...) on the top right to perform actions such as Pin/Unpin, Share, Share with Selfie, QR Code Login, view Activity Log, and Remove from the detailed view of the VC.
Users can see all the Insurance policy details in the detailed view along with the QR Code. The QR Code can be magnified which can be presented to the verifier for scanning. Through the quick access menu (...) on the top right user can also perform other actions like Share, Pin, Remove and Activity log on the VC.
This flow allows you to download credentials simply by scanning a QR code, without login or manual input of ID/Identifier or other data.
Used in public campaigns or mass rollouts (e.g., vaccine certificates, land cards).
On the issuer’s website, or from a flyer/poster, scan the QR code using the Scan & Download option available in Inji Wallet.
Click on the "+" (Add Credential) icon.
Select the first option: Scan & Download.
Scan the QR code from the issuer's website or printed material.
If this is your first time interacting with the issuer, a trust screen will appear asking you to trust the issuer.
You can proceed to trust and add the issuer to your trusted list or decline as per your preference. This prompt appears only once per issuer.
If you Decline, the download will not proceed further.
The wallet recognizes the embedded credential offer, without needing to log in or enter any data, your credential starts downloading.
You’ll see a success message and the VC will appear in your wallet.
Used for personalized and secure issuance (e.g., mDL, insurance).
On the issuer’s website, or from a flyer/poster, scan the QR code using the Scan & Download option available in Inji Wallet.
Click on the "+" (Add Credential) icon.
Select the first option: Scan & Download.
Scan the QR code from the issuer's website or printed material.
If this is your first time interacting with the issuer, a trust screen will appear asking you to trust the issuer.
You can proceed to trust and add the issuer to your trusted list or decline as per your preference. This prompt appears only once per issuer.
If you Decline, the download will not proceed further.
If you Allow, the download will proceed further.
After entering the code, the wallet retrieves the credential securely.
The wallet recognizes the embedded credential offer, Without needing to log in or enter any data, your credential starts downloading.
You’ll see a success message and the VC will appear in your wallet.
After completing several scenarios, we can find it by selecting the third icon in the bottom right corner when we navigate to the history page. This page will display a comprehensive list of all the events.
Users can view the activity logs of a VC from the Home Page or the detailed view by choosing the menu option "View Activity Log" from the quick access menu (...).
Two or more devices with Inji Wallet installed are required to share credentials. The relying party's phone should be an Android device.
All required permissions like Bluetooth, location, and camera access are enabled on both devices.
The parties involved are usually a Resident (sharing party) who wishes to share their credentials with a Relying party (receiving party), a banker, a health worker, or other professional service.
Users can now share their credentials using any of the methods listed below:
Share option from the NavBar.
Share or Share with Selfie option from the quick access menu (...) from a VC in the Home Page
Share or Share with Selfie option from quick access menu (...) in detailed view of VC.
Let us understand the process of sharing credentials using an example and see the step-wise process for all the above three methods. Suppose a Resident wishes to share their credentials with a Relying/ Requesting party through the receiver's phone, the following steps outline the procedure for both parties involved:
On the Sharing Party's phone:
The resident opens the QR Code Scanner by clicking on the Share button in the NavBar. The application now prompts for permissions.
Upon granting the necessary permissions, the app opens a camera where the resident can scan the QR code of the recipient's (Verifier/Relying Party) phone.
Once the QR code is successfully scanned, both phones will establish a Bluetooth connection.
On the Relying Party's phone
This functionality is only available on Android devices. To access it, the receiver needs to navigate to the settings page and locate the Receive Cards option.
On selecting this option, it will open the QR code page. For the relying party to be able to receive a card, the resident needs to scan the QR code using a shared phone. Once the QR code is scanned and shared, the relying party will receive the VC and be able to preview its contents.
To view the received cards, they would need to access the settings page and find the Received Cards
On the Sharing Party's phone:
The resident clicks on the quick access menu (...) from a VC on the Home Page and chooses the Share or Share with Selfie option from the menu.
The application now prompts for permissions if not granted already.
Upon granting the necessary permissions, the app opens a camera where the resident can scan the QR code of the recipient's (Verifier/Relying Party) phone.
On the Relying Party's phone:
This functionality is only available on Android devices. To access it, the receiver needs to navigate to the settings page and locate the Receive Cards option.
On selecting this option, it will open the QR code page. For the relying party to be able to receive a card, the resident needs to scan the QR code using a shared phone. Once the QR code is scanned and shared, the relying party will receive the VC and be able to preview its contents.
To view the received cards, they would need to access the settings page and find the Received Cards
On the Sharing Party's phone
The resident clicks on the VC on the Home page and clicks on the quick access menu (...) in the detailed view. Resident can choose either Share or Share with Selfie option from the menu.
The application now prompts for permissions if not granted already.
Upon granting the necessary permissions, the app opens a camera where the resident can scan the QR code of the recipient's (Verifier/Relying Party) phone.
On the Relying Party's phone:
This functionality is only available on Android devices. To access it, the receiver needs to navigate to the settings page and locate the Receive Cards option.
On selecting this option, it will open the QR code page. For the relying party to be able to receive a card, the resident needs to scan the QR code using a shared phone. Once the QR code is scanned and shared, the relying party will receive the VC and be able to preview its contents.
To view the received cards, they would need to access the settings page and find the Received Cards
Note: Screenshots will be added soon to enhance the user experience and better explain the steps shown below.
Inji Wallet supports two primary modes of sharing Verifiable Credentials (VCs) using the OpenID4VP protocol:
Same-Device Flow, where the wallet and verifier are accessed from the same mobile device.
Cross-Device Flow, where the wallet and verifier operate on separate devices.
Both flows support standard JSON-LD VCs, mDL (ISO 18013-5), and IETF SD-JWT credentials for full or non-selective disclosure sharing.
For privacy-preserving selective disclosure, the SD-JWT VP flow is followed, as described below.
This method is used when the Inji Wallet is on a mobile phone, and the verifier (such as a service provider portal, kiosk, or scanner) operates on a different device (e.g., laptop or tablet).
Steps to Present Credentials:
Verifier generates a QR code on their system/portal requesting specific credentials.
On your Inji Wallet, tap the QR scanner icon from the home screen or use the “Share” option.
Scan the QR code displayed by the verifier.
This method is useful when you’re accessing a portal from the same mobile device that has the Inji Wallet installed.
Steps to Present Credentials:
On your phone browser, visit the service portal that is requesting your credentials.
Tap on the “QR Code” or similar button.
This opens a deep link that launches your Inji Wallet app automatically.
This method allows users to share only specific claims from an IETF SD-JWT credential, ensuring privacy-preserving and minimal disclosure of information.
Steps to Present Credentials with SD-JWT VP:
Access the verifier’s portal or service (same-device or cross-device).
Initiate the credential request using the OpenID4VP flow.
The verifier specifies required claims (e.g., Name, Date of Birth).
Download a new credential into the Inji Wallet.
As soon as the download finishes, the app automatically begins checking whether the credential is still valid.
The wallet looks up the status of the credential.
It checks if the issuing authority has marked the credential as:
Active (valid)
After clicking on the ellipsis button on the downloaded VC, a button will appear allowing for the VC to be pinned. Selecting this option will pin the specific VC to the top of the screen.
There are two ways to activate the VC:
The first option is to click on the "Activate for online login" menu option by clicking on the quick access menu (...) of the card from the Home Page.
The second option is to click on the "Activate for online login" menu option by clicking on the quick access menu (...) of the card from the detailed view of the VC.
A confirmation alert message will be prompted upon clicking the "Activate for online login" option. Once permission is granted, the user will be directed to an OTP screen. After entering the correct OTP, the VC will be activated and projected on the screen with the same message.
There are two ways to remove/delete a VC from the wallet:
The first option is to click on the Remove from Wallet menu option from the quick access menu (...) of the card from the Home Page.
The second option is to choose the Remove from Wallet menu option from the quick access menu (...) of the card from the detailed view of the VC.
Upon clicking this option, the user will be prompted with a pop-up for confirmation. If the user chooses, “Yes, I confirm” the VC will be removed from the wallet.
Users can now search for a VC by providing a search string in the search bar. VCs that match the search criteria will be displayed.
To backup VCs, the user has to choose their preference for the cloud based on the device they are using.
Firstly, the user has to go to settings and click on the Backup and Restore menu options.
The User should consent for the app to use the drive, and once consented, the application displays a backup and restore screen.
In this screen, the user can manually take a backup by clicking on the Backup button and this asynchronously happens allowing the user to use the application.
To restore backed-up VCs, the user has to choose their preference of the cloud based on the device and use the same Google/apple ID that they used for taking backups.
Firstly, the user has to go to settings and click on the Backup and Restore menu options.
The user should consent for the app to use the drive, and once consented, the application displays a backup and restore screen.
Users find the details of latest backup details in the Last Backup Details section.
Upon successful validation of OTP, the user will be taken back to the application and land on the loading screen. After the download process is completed, the user will be returned to the home page, where the Downloaded Credential will be available.
Upon successful validation, the user will return to the application and land on the loading screen. Following the completion of the download process, the user will be returned to the home page, where the Downloaded Credential will be available.
If you Allow, the download will proceed further.
You will be prompted to enter a Transaction Code / OTP provided by the issuer via SMS or Email.
The resident then needs to choose a downloaded VC and select either the Share or the Share with Selfie option.
The Share button will solely share the VC, while the Share with Selfie option will verify if the sender's face matches the photo in the VC before proceeding to share.
section. Clicking on this section will display the received cards. If the receiver has not received any card, this section will be empty.
Please note that the relying party can only view the received cards and will not be able to share or perform other actions with them.
Once the QR code is successfully scanned, both phones will establish a Bluetooth connection.
The Share button will solely share the VC, while the Share with Selfie option will verify if the sender's face matches the photo in the VC before proceeding to share.
section. Clicking on this section will display the received cards. If the receiver has not received any card, this section will be empty.
Please note that the relying party can only view the received cards and will not be able to share or perform other actions with them.
Once the QR code is successfully scanned, both phones will establish a Bluetooth connection.
The Share button will solely share the VC, while the Share with Selfie option will verify if the sender's face matches the photo in the VC before proceeding to share.
section. Clicking on this section will display the received cards. If the receiver has not received any card, this section will be empty.
Please note that the relying party can only view the received cards and will not be able to share or perform other actions with them.
The wallet reads the verifier’s request and shows you a list of matching credentials.
You are prompted for face authentication.
Choose the credentials you want to share.
Tap “Share” to proceed. The wallet sends the Verifiable Presentation (VP) to the verifier securely.
You’ll see a confirmation message once the sharing is complete.
The wallet fetches the verifier’s request.
A list of matching credentials is displayed.
You will be asked for face authentication.
Choose the credentials to be shared.
Tap “Share”.
You are automatically redirected back to the service portal (Android).
On iOS, you may need to manually switch back to the browser.
The Inji Wallet parses the SD-JWT credential and identifies which claims can be selectively disclosed.
The wallet displays:
The verifier’s details and request information.
A list of available claims within the SD-JWT credential.
The user can select only the claims they wish to share.
The wallet generates a Verifiable Presentation (VP) containing only the selected claims.
You are prompted for authentication (Face) if VC contains a face photo.
Upon confirmation, the SD-JWT VP is securely shared with the verifier.
A success message confirms completion of the privacy-preserving sharing process.
Revoked (no longer valid)
Or if the status cannot be confirmed yet
The wallet verifies the information.
To make sure the status is trustworthy, the wallet:
Confirms the status file is valid
Checks that the information is current
The wallet updates the credential status on the screen.
Based on the result, you will see:
🟢 Valid — you can use or share the credential
🔴 Revoked — you cannot use it
🟡 Pending — try again later; internet may be required
The wallet logs the status check.
The app saves a record in your History showing when the status was last checked.
Manually check the status anytime.
To check the status later, you can go to the card options and tap Check Status.
Users will be notified of success or failure.
In this screen, the user can manually restore a backup by clicking on the Restore button and this asynchronously happens allowing the user to use the application.
Users will be notified of success or failure.
On iOS device
First launch of the app
Download of Verifiable Credentials
1. Download National ID (MOSIP VC)
2. Download Insurance VC
Detailed view of the downloaded VC
Detailed View of National ID VC
Detailed View of Insurance VC
Download Credential by Scanning a QR Code (Credential Offer with Pre-Auth Code)
Here we present the product roadmap for the entire Inji Stack for the calendar year 2025. The annual product cycle for the Inji Stack begins in January and concludes in December.
For detailed module-wise roadmaps, please refer to the following:
Prioritization: Through this roadmap the startegic or adaptive prioritization, if there is, has been indicated as below:
Add [ ➕ ]: Added new.
Inji Wallet
Vision
In 2025, Inji Wallet will continue to ensure compatibility with diverse ecosystems by supporting multiple credential formats, such as mDoc/mDL, SD-JWT, and JWT. The wallet will also incorporate privacy-preserving mechanisms such as BBS+, selective disclosure, and one-time credentials, empowering users to retain full control over their personal information. Additionally, the wallet will enable multi-user credential sharing, addressing family-based use-cases such as ration cards and property deeds, further enhancing its versatility and real-world applicability.
The wallet’s roadmap includes critical features like enhancements for cross-device and same-device flows, Shamir’s secret sharing for secure key recovery, ECC K1 and R1 key support. By enabling the seamless integration of features like credential offer endpoints and pre-authorized code flows (), Inji Wallet will cater to real-world use cases with ease.
The mobile and web interfaces of Inji Wallet will support high-performance operations, maintaining accessibility even in low-connectivity environments. With robust user login and profile management features, along with integration of play integrity on Android, the wallet will ensure a scalable, secure, and privacy-focused user experience.
Inji Mobile
Inji Web
Inji Certify
Vision
The goal of Inji Certify for the rear 2025 is to provide a comprehensive and user-centric platform for issuing, managing, and verifying credentials, tailored to meet the diverse needs of individuals, organizations, and issuers. With support for multiple credential formats (e.g., SD-JWT, mDoc/mDL), advanced cryptographic standards (ECC, BBS), and privacy-preserving mechanisms, the platform ensures secure and flexible credential handling.
By enabling features like multi-issuer onboarding, deferred issuance, subject-holder relationship management, and one-click authorization during issuance, Inji Certify addresses real-world scenarios such as sharing family credentials, automating bulk credential generation, and simplifying issuer interactions. The integration of offline capabilities (e.g., printable QR-embedded credentials) and scalable architecture ensures accessibility, even in low-connectivity environments, while maintaining performance benchmarks of up to 1 million credentials per day.
Inji Certify’s vision is to foster trust and interoperability in the digital identity ecosystem, empowering users with control over their credentials while providing issuers with a reliable and standards-compliant platform.
Inji Verify
Vision
Our vision for 2025 is to position Inji Verify as the go-to tool for seamless and secure credential verification. We aim to deliver easily configurable UI components for third-party verifier portals, tailored to meet the diverse needs of organizations across the globe. With support for multiple credential formats (SD-JWT, mDoc/mDL, W3C) and advanced cryptographic standards (ECC), Inji Verify ensures flexible and secure credential handling.
Inji Verify fosters trust and interoperability in the digital identity ecosystem. By introducing features like multi-proof capabilities, QR Based Verifiable Presentation in Same Device, SVG Rendering post VC verification, able to identify revoked credentials during verification, able to support credential correction, verification of documents with multiple QR codes, BLE Based verifiable presentation - Inji Verify will redefine user experience and reliability. With a focus on performance , enhanced design for an intuitive look and feel, and adherence to global standards (Data Model 1.1/2.0), the GA release will set new benchmarks for stability, usability, and excellence in digital verification.
Strategic priortization [ ↑ ] : Brought ahead in schedule.
Adaptive reschedule [ ↓ ]: Is moved to approaching quarters.
By 2025, Inji Wallet aims to be a reliable, standards-compliant digital wallet, empowering users to manage their credentials while fostering trusted data exchange and seamless interoperability within the verifiable credentials ecosystem.
Q1
OpenIDVP : Cross-Device Flow
🟢 Completed
Q1
Support of mDL/mDoc Credentials
🟢 Completed
Q2
Cross-Device Enhancements for Credential Sharing
( OpenIDVP :Verifier Metadata Management)
🟢 Completed
Moved to
Q2
Q2➕
VC Verifier SDK (Kotlin): ECC K1 Verification Support
🟢 Complete
Added to Q2
Q2➕
Sharing of mDL/mDoc via OpenIDVP
🟢 Complete
Added to Q2
Q2➕
Complaint to of OpenIDVP Spec
🟢 Complete
Added to Q2
Q2➕
WLA login through deep link in iOS
🟢 Complete
Added to Q2
Q2↑
Same Device Flow: Multiple credential requests during the presentation (OpenIDVP)
🟢 Complete
Moved to Q2 to Q3
Q3
OpenID4VCI Support for credential offer endpoint and pre-authorised code flow
🟢 Complete
Q3↓
Support for SD-JWT Credentials Format
🟢 Complete
Moved to Q3 from Q2
Q4↓
W3C Data Model 2.0 & SVG Render Method
&
🟢 Complete
Moved to Q4 from Q2
Q4➕
Selective Disclosure via OpenIDVP
🟢 Complete
Added to Q4
Q4↓
Credential Revocation
🟢 Complete
Moved to Q4 from Q3
2026↓
Presentation During Issuance
Moved to 2026 & Beyond
v0.22.0
Q4 Moved to 2026
2026↓
Support for Advanced Cryptographic Keys (ECC R1)
Moved to 2026 & Beyond
NA
Q4
Moved to 2026
2026↓
Support for JWT Credentials Format
Moved to 2026 & Beyond
NA
Q4
Moved to 2026
2026↓
Wallet Login with Unified Key Management
Moved to 2026 & Beyond
NA
Q3
Moved to 2026
2026↓
Profile Creation Using a Single Credential
Moved to 2026 & Beyond
NA
Q3
Moved to 2026
2026↓
Secure Key Recovery with Shamir’s Secret Sharing
Moved to 2026 & Beyond
NA
Q3
Moved to 2026
2027↓
Advanced Privacy Features with BBS+
Moved to 2026 & Beyond
NA
Q3
Moved to 2026
2027↓
Android App Security with Play Integrity
Moved to 2026 & Beyond
NA
Q3
Moved to 2027
2027↓
Multi-User Family Credentials
Moved to 2026 & Beyond
NA
Q4
Moved to 2027
2027↓
One-Time Use Credentials for Privacy
Moved to 2026 & Beyond
NA
Q4
Moved to 2027
2027↓
Secure Wallet Setup with Key Binding
(SIOP)
Moved to 2026 & Beyond
NA
Q1
Moved to 2027
Q1
Enable RSA256 Signature Suites for Guest Login(without login)
🟢 Complete
Q2
Enabling customisation of PDF Template
🟢 Complete
Q3+
User Login with IDP
🟢 Complete
Added to Q3
Q3+
Enable RSA256 Signature Suites for Login Flow
🟢 Complete
Q3↓
Enable Ed25519 2018 and 2020 Signature Suites for Login Flow
🟢 Complete
Q3↓
Enable ECC K1 Signature Suites for Login Flow
🟢 Complete
Q4↓
SD-JWT Credential Support
🟢 Complete
Moved to Q4 from Q3
Q4+
Enable Ed25519 2018 and 2020 Signature Suites for Guest Login (Without Login)
🟢 Complete
Added to Q4
Q4+
Enable ECC K1 Signature Suites for Guest Login (Without Login)
🟢 Complete
Added to Q4
Q4+
OpenIDVP Support for JSON-LD(W3C) VCs
🟢 Complete
Added to Q4
2026↓
Credential Revocation
Moved to 2026 & Beyond
v0.16.0
Q4
Moved to 2026
2026↓
W3C Data Model 2.0 & SVG Render Method
Moved to 2026 & Beyond
v0.16.0
Q4
Moved to 2026
2026↓
OpenIDVP Support for SD-JWT
Moved to 2026 & Beyond
NA
Q4
Moved to 2026
2026↓
Support for Advanced Cryptographic Keys (ECC R1)
Moved to 2026 & Beyond
NA
Q4
Moved to 2026
2026↓
Secure Key Recovery Using Shamir’s Secret Sharing
Moved to 2026 & Beyond
NA
Q2
Moved to 2026
2026↓
Support for mDoc/mDL Credentials
Moved to 2026 & Beyond
NA
Q2
Moved to 2026
2026↓
CBOR Credential Format Support
Moved to 2026 & Beyond
NA
Q2
Moved to 2026
2026↓
OpenID4VCI Support for credential offer endpoint and pre-authorised code flow
Moved to 2026 & Beyond
NA
Q3
Moved to 2026
2026↓
Advanced Privacy with BBS+ Support
Moved to 2026 & Beyond
NA
Q3
Moved to 2026
2026↓
Support for JWT Credentials
Moved to 2026 & Beyond
NA
Q3
Moved to 2026
2026↓
Unified Key Management for Web & Mobile
Moved to 2026 & Beyond
NA
Q1
Moved to 2026
2027↓
One-Time-Use Credentials for Privacy
Moved to 2026 & Beyond
NA
Q3
Moved to 2027
2027↓
Multi-User Family Credentials
Moved to 2026 & Beyond
NA
Q3
Moved to 2027
Q1
Support for VC data model 2.0
🟢 Completed
Q1
Implementation of Data Provider Plugin
🟢 Completed
Q1
ED25519 (2018 & 2020) VC Signing
🟢 Completed
Q2
Support for ECC K1
🟢 Completed
Moved to Q2 from Q1
Q2+
Support for ED25519 (2018 & 2020)
🟢 Completed
Added to Q1
Q2+
OAuth Support with external authentication
🟢 Completed
Added to Q1
Q3↓
Add New Credential Type to Issuer
🟢 Completed
Moved to Q3 from Q2
Q3↓
Support for ECC R1
🟢 Completed
Moved to Q3 from Q1
Q3+
Support for Data Integrity
🟢 Completed
Added to Q3
Q3↓
Credential Revocation Mechanism
🟢 Completed
&
Moved to Q3 from Q1
Q3↓
Credential Formats Support for - SD JWT
🟢 Completed
&
Moved to Q3 from Q1
Q3↓
Credential Formats Support for -mDoc
🟢 Completed
Moved to Q3 from Q2
Q3↓
Pre-authorized Code Flow
Moved to 2026 & Beyond
0.14.0
Moved to Q2 from Q1
Q3↓
Presentation during issuance of Credential
Moved to 2026 & Beyond
0.14.0
Moved to Q3 from Q2
Q3+
Claim 169 Support with QR Code Generation
Moved to 2026 & Beyond
0.14.0
Added to Q3
Q3↓
Anon Credential
Deprioritised
TBD
Moved to Q3 from Q2
Q3
VC Generation: Create Credentials from the Request Payload
Moved to 2026 & Beyond
TBD
Q3
Multi-issuers: Onboarding of multiple issuers
Moved to 2026 & Beyond
TBD
Q3
Subject Holder relationship for VC
Moved to 2026 & Beyond
TBD
Q3
Allow bulk generation of onetime credentials
Moved to 2026 & Beyond
TBD
Q4
Deferred Credential Endpoint
Deprioritised
TBD
Q4
Multi-User Credentials
Deprioritised
TBD
Q4
Issue a physical credential (PDF / Printable)
Deprioritised
TBD
, ,
Q1
Upgrades in OpenID4VP - Draft 21 specification
🟢 Completed
Q1
Inji Verify SDK: OpenID4VP- VP Verification component (cross device flow) and publish as an NPM module
🟢 Completed
Q1
Migration of Inji Verify backend from H2 in memory DB to PostgreSQL DB
🟢 Completed
Q2
Inji Verify SDK: Scan/ Upload Component and publish as an NPM module
🟢 Completed
Q2
Server Setup for VC and VP Proof Verification in vc-verifier library
🟢 Completed
Q3
OpenIDVP Same Device Flow (via deeplink): Integrate to Inji Verify SDK
Inji is a digital credentialing stack that enables users to securely download, store, share, and verify credentials. This guide is structured to provide a comprehensive approach for deploying the Inji stack (Inji Certify, Mimoto, Inji Web and Inji Verify). Not only the Inji Stack, this deployment guide has taken an approach to cover everything from deploying Wireguard to Base Infrastructure setup, Core Infra setup to configurations and finally the Inji Stack deployment.
Do I need to read through the entire guide to be able to deploy Inji?
This is the first question you could ask and the answer is No! If you have the Infrastructure ready and you just want to deploy the Inji stack you can directly jump to the Inji Stack Deployment section.
How is this guide structured and organized?
Introduction: Provides an overview of the Inji stack, deployment scenarios, required skill sets, system architecture, and key considerations for on-premise deployments.
: Outlines infrastructure details, hardware/software/network requirements, and initial setup steps.
: Guides you through setting up the foundational infrastructure for Inji, including Kubernetes provisioning, NGINX configuration, networking, and optionally, the observability cluster and monitoring module.
: Explains the external services required—such as the database, artifactory, etc.,—and provides steps for their installation and configuration.
: Offers step-by-step instructions to deploy Inji modules (Certify, Wallet, Verify) along with configuration guidance.
: Highlights how you can contribute code, share feedback, or reach out for support while working with the application.
Each section provides direct steps and references to external resources for a streamlined deployment experience.
The scenarios listed below are only a few examples. Inji Stack can support many more deployment possibilities depending on the country, organization, or individual requirements.
Deployment Scenario
Modules Included
Countries / Use Case Example
Deploying Inji Stack is easier while you have Base Infrastructure ready, still, if you want to deploy it 'On-Premise' and from scratch, this guide helps you with the instructions to achieve this.
Linux System Administration: Proficiency in Linux command-line operations, user and permission management, and basic networking.
Networking Fundamentals: Knowledge of firewalls, load balancers, DNS, and secure network configuration.
Containerisation: Experience with Docker or similar container technologies for building and managing service containers.
Links to the deployment architecture diagrams below take you to respective sections of this guide and illustrate the high-level deployment architecture for Inji Stack, showing how core components interact within the Kubernetes cluster, including ingress, services, and external integrations.
Inji Wallet
For a smooth and error-free setup of the Inji Stack, it is recommended to follow the deployment order starting with Inji Certify, followed by mimoto backend for Inji Wallet(Mobile+Web), next the Inji Web Wallet, and finally Inji Verify. This sequence ensures that foundational services and dependencies are available before deploying modules that rely on them, leading to a more stable and seamless deployment experience.
The section helps you to have a quick understanding of what you should expect when you go about deploying Inji-Stack, especially if you are deploying it 'On-Premise' and from scratch.
Inji modules are deployed as microservices in a Kubernetes cluster.
Wireguard is used as a trust network extension to access the admin, control, and observation panes.
Inji uses Nginx server for:
While we have placed the Prerequisites specific to a section under respective sections itself, here, this 'Prerequisites' lists the common ones which you will need no matter which component you are deploying such as Wireguard, PC - Tools and Utilities etc.
Follow the steps mentioned here to install the required tools on your personal computer to create and manage the k8's cluster.
The Inji stack can be deployed with a PC having one of the following operating systems, however for this guide we have considered a linux machine with Ubuntu 22.04 LTS.
Linux (Ubuntu 22.04 LTS - recommended for production deployments)
Windows
macOS (OSX)
You should have these tools installed on your local machine from where you will be running the ansible playbooks to create and manage the k8 cluster using RKE1.
- version > 2.12.4
Command line utilities:
- version 2.12.4 or higher
: version:
: version: 1.15.0
Create a directory as mosip in your PC and:
Wireguard bastian server provides secure private channel to access Inji cluster. Bastian server restricts public access, and enables access to only those clients who have their public key listed in Wireguard server.
WireGuard is a modern, fast, and secure VPN (Virtual Private Network) protocol and software that creates encrypted tunnels between devices.
Wireguard bastian server provides secure private channel to access Inji cluster.
Bastian server restricts public access, and enables access to only those clients who have their public key listed in Wireguard server.
Before proceeding, Create a Wireguard server VM with the mentioned specification under 'Prerequisites' above. This VM will be used to set up the Wireguard server. Once the VM is ready, open the required ports on the Bastion server VM.
Open required ports in the Bastian server VM
Configure the firewall on the Bastion server virtual machine to allow network traffic through specific ports needed for your application or remote access.
cd $K8_ROOT/wireguard/
Create copy of hosts.ini.sample as hosts.ini and update the required details for wireguard VM
cp hosts.ini.sample hosts.ini
Execute ports.yml to enable ports on VM level using ufw:ansible-playbook -i hosts.ini ports.yaml
Install docker
execute docker.yml to install docker and add user to docker group:
Setup Wireguard server
SSH to wireguard VM
ssh -i <path to .pem> ubuntu@<Wireguard server public ip>
Install Wireguard client on your PC using .
Assign wireguard.conf:
SSH to the wireguard server VM.
Once connected to wireguard, you should be now able to login using private IP’s.
"Base Infrastructure Setup" refers to preparing all foundational resources and configurations needed before deploying the Inji stack. This includes provisioning servers/VMs, configuring networks and firewalls, setting up SSL certificates, installing Kubernetes clusters and required tools (Docker, kubectl, Helm, etc.), establishing secure access (e.g., Wireguard VPN), and deploying essential services like NGINX, storage, monitoring, and logging. It ensures the environment is ready for Inji stack installation.
Provisioning foundational resources required for the Inji stack, including:
Virtual machines (VMs) or servers as per hardware requirements.
Before deploying any Inji Stack module, ensure that the following common prerequisites are met. These requirements apply to all modules and must be fulfilled to guarantee a smooth and successful deployment process.
Note: You can deploy Inji on an environment and operating system that supports Kubernetes-based deployments. Ensure your chosen OS and infrastructure meet the prerequisites and compatibility requirements. Note: This guide references using Ubuntu Server 22.04 LTS. Note: For large-scale deployments or environments with strict security requirements, an on-premises setup is recommended. For pilot projects, demonstrations, or rapid prototyping, a cloud-based deployment may be more suitable.
Note: Virtual Machines (VMs) can use any operating system as per convenience. For this installation guide, Ubuntu OS is referenced throughout.
VMs and Hardware Specifications
3 VMs (allocate etcd, control plane, and worker nodes accordingly for HA)
Below is a sample mapping of domain names to their respective IP addresses and purposes for a typical Inji deployment. Update these as per your environment.
rancher.xyz.net
Maps to: Private IP of Nginx server or load balancer (Observation cluster)
Purpose: Rancher dashboard for monitoring and managing the Kubernetes cluster.
Note: Ensure all DNS records are created and point to the correct IP addresses (public or private) as per your network design. For private domains, access is typically restricted via Wireguard VPN.
See the section for common prerequisites required for all deployments.
Note: For detailed VM provisioning steps and hardware/network prerequisites, see the above for VM - Hardware specification and more.
Find the kubernetes infrastructure repository which contains the scripts to install and configure Kubernetes cluster with required monitoring, logging and alerting tools.
After reviewing the k8s-infra repository and ensuring that you also have all the required tools and utilities installed on your local machine, the next step is to provision and configure your Kubernetes cluster nodes (VMs or servers) according to the hardware and network requirements specified under 'Prerequisites' above. Once your nodes are ready and accessible, proceed to run the provided Ansible playbooks and scripts from the k8s-infra repository to set up the Kubernetes cluster, networking, and essential infrastructure components.
Ingress setup
It is a service mesh for the MOSIP K8 cluster which provides transparent layers on top of existing microservices along with powerful features enabling a uniform and more efficient way to secure, connect, and monitor services.
cd $K8_ROOT/mosip/on-prem/istio
./install.sh
This will bring up all the Istio components and the Ingress Gateways.
Storage classes (NFS)
Multiple storage classes options are available for onprem K8's cluster. In this reference deployment will continue to use NFS as a storage class.
Move to nfs directory in your personel computer.
Create a copy of hosts.ini.sample as hosts.ini.
Update the NFS machine details in hosts.ini file.
Note :
Add below mentioned details:
ansible_host : internal IP of NFS server. eg. 10.12.23.21. In our reference implementation using nginx server
SSH to the nfs node:
Clone k8s-infra repo in nginx VM:
Move to the nfs directory:
Execute script to install nfs server:
Note: > * Script prompts for below mentioned user inputs: > > > ..... > Please Enter Environment Name: <envName> > ..... > ..... > ..... > [ Export the NFS Share Directory ] > exporting *:/srv/nfs/mosip/<envName> > NFS Server Path: /srv/nfs/mosip/<envName> > > > * envName: env name eg. dev/qa/uat...
Switch to your personel computer and excute below mentioned commands:
Post installation check:
Check status of NFS Client Provisioner from your PC, make sure pointing to right kubeconfig file.
Check status of nfs-client storage class.
SSL certificate creation
For Nginx server setup, we need ssl certificate, add the same into Nginx server.
Incase valid ssl certificate is not there generate one using letsencrypt:
SSH into the nginx server
Generate wildcard SSL certificates for your domain name.
Add below mentioned lines with updated details of nginx server to the hosts.ini and save.
Execute below mentoned command to open required ports:
Login to the nginx server node.
Clone k8s-infra
Provide below mentioned inputs as and when prompted
MOSIP nginx server internal ip
MOSIP nginx server public ip
Check Overall nginx and istio wiring
Install httpbin: This utility docker returns http headers received inside the cluster.
httpbin can be used for general debugging - to check ingress, headers etc.
Make sure pointing to right kubeconfig file.
To see what is reaching the httpbin (example, replace with your domain name):
Note :
Monitoring in the sandbox environment is optional and can be deployed if required.
For production environments, alternative monitoring tools can be used.
These steps can also be skipped in development environments if monitoring is not needed.
Prometheus and Grafana and Alertmanager tools are used for cluster monitoring.
Select 'Monitoring' App from Rancher console -> Apps & Marketplaces.
In Helm options, open the YAML file and disable Nginx Ingress.
Note:
Alerting in the sandbox environment is optional and can be deployed if required.
For production environments, alternative alerting tools can be used.
These steps can also be skipped in development environments if alerting is not needed.
Install Default alerts along some of the defined custom alerts:
Alerting is installed.
Note :
Logging in the sandbox environment is optional and can be deployed if required.
For production environments, alternative logging tools can be used.
These steps can also be skipped in development environments if logging is not needed.
Inji uses and elasticsearch to collect logs from all services and reflect the same in Kibana Dashboard.
Install Rancher FluentD system : Required for screpping logs outs of all the microservices from Inji k8 cluster.
Install Logging from Apps and marketplace within the Rancher UI.
Select Chart Version 100.1.3+up3.17.7 from Rancher console -> Apps & Marketplaces.
Open kibana dashboard from https://kibana.sandbox.xyz.net.
Kibana --> Menu (on top left) --> Dashboard --> Select the dashboard.
This section covers the installation and configuration of essential infrastructure components required for the Inji stack, including configmaps, databases, object storage, secrets management, configuration server, and artifactory.
inji-stack-config configmap: For inji K8's env, inji-stack-config configmap in default namespace contains Domain related information. Follow below steps to add domain details for inji-stack-config configmap.
Update the domain names in inji-stack-cm.yaml correctly for your environment.
Create values.yaml
This ensures that values.yaml is available for your Helm install command and can be referenced directly during the config-server deployment.
Create a values.yaml file that will contain the configuration for the chart and send it to your config-server installation.
Review values.yaml and make sure git repository parameters are as per your installation and enable only the required environment variables.
Open the file and paste the following content into it in the same directory where values.yaml is created.
Run the Script
Once Prerequisites, Base Infrastructure, and the Core Infrastructure Setup and Configuration are complete, now you can proceed with the deployment of the Inji stack components.
For detailed deployment steps, architecture, and module-level instructions, refer to the following:
Inji Wallet
While you have a deployment environment ready, you can now proceed with the installation of Inji Certify by following the steps explained here.
Note: Before deploying Inji Certify, it is recommended to always use the latest . Each release includes enhancements, technical upgrades, and new features to ensure the best experience.
Inji Certify is deployed as containerized microservices in your Kubernetes cluster.
Where Will it Run?
Target Environment: Your main Kubernetes cluster
Deployment Method: Helm charts that pull Docker images from container registries
Access Point: Through your configured NGINX ingress at https://injicertify.sandbox.xyz.net
Before deploying Inji Certify, ensure the following infrastructure components and configurations are in place as mentioned
Step 2: Prepare Your Deployment Environment
From your local machine, you'll run deployment scripts that:
Connect to your Kubernetes cluster via kubectl
Deploy containerized services using Helm charts
Configure ingress rules through Istio
Step 3: Clone and Navigate to Deployment Scripts
Step 4: Deploy Redis (if not already deployed)
Step 5: Initialize Database
Step 6: Deploy Inji Certify Microservices
Helm Charts Execution: Downloads and deploys Docker containers
Service Registration: Services register with config-server for configuration
Database Initialization: Creates required tables and seed data
###3 Verification Steps
Check Pod Status
Verify Service Endpoints
Test External Access
Deployment Scripts Executed Successfully
All deployment scripts (install.sh) for Redis and Inji Certify microservices complete without errors.
No failed Helm releases or container pull issues during deployment.
Remote Deployment: You deploy from your local machine to the remote K8s cluster
Container Registry: Docker images are pulled from public/private registries during deployment
Configuration: All configuration comes from your config-server and configmaps
If deployment fails, check:
Cluster Connectivity: kubectl cluster-info
Prerequisites: Ensure config-server, postgres, redis are running
Resources: Verify cluster has sufficient CPU/memory
You can also refer to the file for deployment steps given in individual module repositories.
Need help or have questions?
In case you encounter any issues or have queries while using or deploying the application, please post them in the . The community and maintainers are available to assist you.
This section provides a structured, step-by-step guide to deploy Mimoto, which serves as the backend for Inji Mobile Wallet and Inji Web Wallet. Follow these instructions to ensure a successful and reproducible deployment.
Note: Before deploying mimoto, it is recommended to always use the latest released version. Each release includes enhancements, technical upgrades, and new features to ensure the best experience.
Mimoto is deployed as containerized microservices in your Kubernetes cluster.
Where Will it Run?
Target Environment: Your main Kubernetes cluster
Deployment Method: Helm charts and shell scripts that pull Docker images from container registries
Access Point: Through your configured NGINX ingress (domain as configured)
What Gets Installed?
Kubernetes Pods: Running Mimoto microservices
Services: For internal communication
Ingress Rules: For external access via NGINX/Istio
Step 1: Pre-Deployment Checklist
Before deploying the mimoto (backend for Inji Wallet), ensure the following infrastructure components and configurations are in place as mentioned below:
Step 2: Clone and Navigate to Deployment Scripts
Step 3: Install Redis (If Not Already Installed)
To install Redis, run:
Step 4: Initialize Database
Update the values file for PostgreSQL initialization as needed, then run:
Step 5: Install Partner Onboarder
To install the Partner Onboarder module:
During the execution of the install.sh script, you will be prompted to provide information for the S3 bucket, including its name and URL.
Once the job completes, log in to your S3 or NFS storage and verify the reports. There should be no failures.
Step 6: Install Mimoto
Before installing Mimoto, ensure that the database host and port are correctly configured in the values.yaml file.
To install Mimoto:
During the execution of the install.sh script, you will be prompted to specify whether a public domain and a valid SSL certificate are present on the server.
If the server does not have a public domain and valid SSL certificate, select n.
This will enable an init-container with an emptyDir volume, which will download the server's self-signed SSL certificate and mount it to the Java keystore (cacerts) within the container.
This is useful for deployments using self-signed SSL certificates.
Step 6: Onboarding a New Issuer for VCI
To onboard a new issuer for VCI:
Create a folder named certs in the root directory.
Inside certs, create a file named oidckeystore.p12.
Store the keys as different aliases for each issuer in this file.
For more details, refer to the official documentation or the relevant section in the repository.
Check Pod Status:
Check Service Endpoints:
Test External Access:
Remote Deployment: You deploy from your local machine to the remote K8s cluster.
Container Registry: Docker images are pulled from public/private registries during deployment.
Configuration: All configuration comes from your config-server and configmaps.
Note: Screenshots for each success criteria step will be added shortly to provide a visual reference.
Deployment Scripts Executed Successfully
All installation scripts (install.sh) for Redis, Partner Onboarder, and Mimoto complete without errors.
No failed Helm releases or container pull issues during deployment.
If deployment fails, check:
Cluster Connectivity: kubectl cluster-info
This command checks if your local kubectl is properly configured and can communicate with the Kubernetes cluster.
It displays information about the cluster's master and services, confirming that your connection is active and functional.
Prerequisites: Ensure config-server, postgres, redis are running
Resources: Verify cluster has sufficient CPU/memory
Network: Ensure ingress and DNS are properly configured
You can also refer to the file for deployment steps given in individual module repositories.
Need help or have questions?
In case you encounter any issues or have queries while using or deploying the application, please post them in the . The community and maintainers are available to assist you.
This section explains how to deploy the Inji Web Wallet, which comes with a reference web UI and DataShare. This web UI serves as a sample implementation to help integrators and countries build their own customized user interface.
Note: Before deploying Inji Web Wallet, it is recommended to always use the latest . Each release includes enhancements, technical upgrades, and new features to ensure the best experience.
Inji Web UI and dataShare are deployed as containerized microservices in your Kubernetes cluster.
Where Will It Run?
Target Environment: Your main Kubernetes cluster
Deployment Method: Helm charts that pull Docker images from container registries
Access Point: Through your configured NGINX ingress at https://injiweb.sandbox.xyz.net (and DataShare endpoints as configured)
What Gets Installed?
Kubernetes Pods: Running Inji Web UI and DataShare microservices
Services: For internal communication
Ingress Rules: For external access via NGINX/Istio
Step 1: Pre-Deployment Checklist
Before deploying Inji Web Wallet, ensure the following infrastructure components and configurations are in place as mentioned below:
Step 2: Prepare Your Deployment Environment
From your local machine, you'll run deployment scripts that:
Connect to your Kubernetes cluster via kubectl
Deploy containerized services using Helm charts
Configure ingress rules through Istio/NGINX
Step 4: Clone and Navigate to Deployment Scripts
Step 5: Prepare Configuration
Review and update the values.yaml file for your environment (domain names, DB connection, object store endpoints, etc.).
Ensure the active_profile_env parameter in the config map of the config-server-share is set to:
Step 6: Deploy DataShare (if required)
If DataShare is a separate module, deploy it first:
Step 6: Deploy Inji Web UI
From the deploy directory:
Step 7: Verification Steps
Check pod status:
Check service endpoints:
Test external access:
Step 8: Post-Installation Configuration
Confirm that the active_profile_env in the config-server-share config map is set as described above.
Ensure DNS records for injiweb.sandbox.xyz.net and any DataShare endpoints are correctly mapped to your ingress controller.
Remote Deployment: You deploy from your local machine to the remote K8s cluster
Container Registry: Docker images are pulled from public/private registries during deployment
Configuration: All configuration comes from your config-server and configmaps
Note: Screenshots for each success criteria step will be added shortly to provide a visual reference.
Your deployment is successful if:
Pods are Running and Healthy
All pods in the injiweb namespace show STATUS = Running and READY counts match.
kubectl get pods -n injiweb shows no CrashLoopBackOff or Error.
Services are Registered and Reachable
kubectl get services -n injiweb lists expected Inji Web and DataShare services.
Each service has a valid ClusterIP or LoadBalancer.
Configuration is Applied Correctly
Ensure the active_profile_env parameter in the config map of the config-server-share is set to: default,inji-default, standalone
No config fetch errors appear in Inji Web pod logs.
Ingress/DNS is Working
DNS entries (e.g., injiweb.sandbox.xyz.net) point correctly to your ingress controller.
Running curl k https://injiweb.sandbox.xyz.net/health returns HTTP 200 with a healthy response.
DataShare Module (if deployed) is Accessible
DataShare pods are up and healthy.
DataShare endpoints are reachable and registered in Kubernetes.
No Critical Errors in Logs
Reviewing logs (kubectl logs <pod-name> -n injiweb) shows no failures during startup or runtime.
If deployment fails, check:
Cluster Connectivity: kubectl cluster-info
This command checks if your local kubectl is properly configured and can communicate with the Kubernetes cluster.
It displays information about the cluster's master and services, confirming that your connection is active and functional.
Prerequisites: Ensure config-server, postgres, redis are running
Resources: Verify cluster has sufficient CPU/memory
Network: Ensure ingress and DNS are properly configured
You can also refer to the file for deployment steps given in individual module repositories.
Need help or have questions?
In case you encounter any issues or have queries while using or deploying the application, please post them in the . The community and maintainers are available to assist you.
This section provides step-by-step instructions to install Inji Verify. Please follow these guidelines to make sure a successful setup in your environment.
Note: Before deploying Inji Verify, it is recommended to always use the latest . Each release includes enhancements, technical upgrades, and new features to ensure the best experience.
Inji Verify is deployed as containerized microservices in your Kubernetes cluster.
Where Will It Run??
Target Environment: Your main Kubernetes cluster
Deployment Method: Helm charts that pull Docker images from container registries
Access Point: Through your configured NGINX ingress at https://injiverify.sandbox.xyz.net
Before deploying Inji Verify, ensure the following infrastructure components and configurations are in place as mentioned
Step 2: Prepare Your Deployment Environment
From your local machine, you'll run deployment scripts that:
Connect to your Kubernetes cluster via kubectl
Deploy containerized services using Helm charts
Configure ingress rules through Istio
Step 3: Clone and Navigate to Deployment Scripts
Step 4: Initialize Database
Update the values file for PostgreSQL initialization as needed.
Step 5: Deploy Inji Verify Microservices
Helm Charts Execution: Downloads and deploys Docker containers
Service Registration: Services register with config-server for configuration
Database Initialization: Creates required tables and seed data
Check Pod Status
Verify Service Endpoints
Test External Access
Delete all services:
Restart all services:
Remote Deployment: You deploy from your local machine to the remote K8s cluster
Container Registry: Docker images are pulled from public/private registries during deployment
Configuration: All configuration comes from your config-server and configmaps
Note: Screenshots for each success criteria step will be added shortly to provide a visual reference.
Deployment Scripts Executed Successfully
Deployment scripts (install-all.sh) complete without errors.
No failed Helm releases or container pull issues during deployment.
If deployment fails, check:
Cluster Connectivity: kubectl cluster-info
This command checks if your local kubectl is properly configured and can communicate with the Kubernetes cluster.
It displays information about the cluster's master and services, confirming that your connection is active and functional.
Prerequisites: Ensure config-server, postgres, redis are running
Resources: Verify cluster has sufficient CPU/memory
Network: Ensure ingress and DNS are properly configured
You can also refer to the file for deployment steps given in individual module repositories.
We welcome contributions from everyone!
Check to learn how you can contribute code to this application. If you have any questions or run into issues while trying out the application, feel free to post them in the — we’ll be happy to help you out.
Module-Specific Deployment (with eSignet)
Selected modules based on requirement
Certify + Verify: Issuance & verification focus
Module-Specific Deployment (without eSignet)
Selected modules based on requirement
Web Wallet + Mobile Wallet: Credential holding/presentation
Hybrid Deployment
Some modules on-premise, some on cloud
Countries with regulatory/data residency constraints, for example issuer to be on-prem while the inji wallet is deployed on cloud
Phased Rollout Deployment
Gradual deployment of modules/regions
Pilot projects or regional rollouts
Kubernetes Administration: Understanding of Kubernetes concepts, cluster setup, resource management, and troubleshooting.
Helm: Familiarity with Helm for managing Kubernetes manifests and deployments.
Database Management: Basic skills in managing PostgreSQL or similar databases, including initialization and schema setup.
Configuration Management: Ability to manage application configuration files, secrets, and certificates securely.
Monitoring and Logging: Understanding of logging and monitoring tools to observe system health and troubleshoot issues.
Security Best Practices: Awareness of secure credential handling, certificate management, and access control.
Scripting: Basic scripting skills (e.g., Bash, Python) for automation and operational tasks.
Familiarity with CI/CD Pipelines: Understanding of continuous integration and deployment processes is a plus.
Kubernetes (k8's) cluster is administered using the rke tools and kubectl commands.
We have two k8's clusters:
Observation cluster [Optional] - This cluster is part of the observation plane and assists with administrative tasks. By design, this is kept independent from the actual cluster as a good security practice and to ensure clear segregation of roles and responsibilities. As a best practice, this cluster or its services should be internal and should never be exposed to the external world.
Rancher is used for managing the Inji cluster.
Keycloak in this cluster is used to manage user access and rights for the observation plane.
It is recommended to configure log monitoring and network monitoring in this cluster during production deployment.
In case you have an internal container registry, then it should run here.
Inji cluster - This cluster runs all the Inji components and core infrastructure components like kafka, Postgres, minio, etc.
Inji Services are deployed in this cluster.
helm- any client version above 3.0.0 and add below repos as well
clone k8’s infra repo with tag : 1.2.0.2 (whichever is the latest version) inside mosip directory. git clone https://github.com/mosip/k8s-infra -b v1.2.0.2
clone mosip-infra with tag : 1.2.0.2 (whichever is the latest version) inside mosip directory. git clone https://github.com/mosip/mosip-infra -b v1.2.0.2
Set below mentioned variables in bashrc and excute command source .bashrc
Note: Above mentioned environment variables will be used throughout the installation to move between one directory to other to run install scripts.
istiod: Istio daemon for replicating the changes to all envoy filters.
ansible_user : user to be used for installation, in this ref-impl we use Ubuntu user.
ansible_ssh_private_key_file : path to pem key for ssh to wireguard server. eg. ~/.ssh/wireguard-ssh.pem .
Make sure Kubeconfig file is set correctly to point to required mosip cluster.
Install Pre-requisites:
The default challenge HTTP is changed to DNS challenge, as we require wildcard certificates.
Create a DNS record in your DNS service of type TXT with host _acme-challenge.sandbox.xyz.net, with the string prompted by the script.
Wait for a few minutes for the above entry to get into effect.
** Verify**: host -t TXT _acme-challenge.sandbox.mosip.net
Press enter in the certbot prompt to proceed.
Certificates are created in /etc/letsencrypt on your machine.
Certificates created are valid for 3 months only.
Wildcard SSL certificaterenewal. This will increase the validity of the certificate for next 3 months.
Use any editor to create new hosts.ini file:
Publically accessible domains (comma seperated with no whitespaces)
SSL cert path
SSL key path
Cluster node ip's (comma seperated no whitespace)
Post installation check
sudo systemctl status nginx
Steps to uninstall nginx (incase it is required)
sudo apt purge nginx nginx-common
DNS mapping: Once nginx server is installed sucessfully, create DNS mapping for observation cluster related domains as mentioned in DNS requirement section.
Incase skipping execute below commands to install monitoring crd as the same is required by mosip services:
Click on Install.
Alerting is part of cluster monitoring, where alert notifications are sent to the configured email or slack channel.
Monitoring should be deployed which includes deployment of prometheus, grafana and alertmanager.
Artifactory is used to store, manage, and distribute build artifacts (such as Docker images, Helm charts, binaries, and other deployment packages) required by the Inji stack and related services. Installing Artifactory ensures that all deployment dependencies are securely managed and easily accessible during automated deployments and upgrades.
Why install Artifactory?
Centralizes storage of deployment artifacts for consistency and reliability.
Enables version control and traceability of all build packages.
Facilitates automated CI/CD pipelines by providing a secure and scalable repository.
Redis Installation
Redis Installed and Running
Redis pod is running and healthy.
Verified via:kubectl get pods -n mimoto
Database Initialized Correctly
PostgreSQL tables and seed data are created as per values.yaml.
No database errors during initialization.
Partner Onboarder Installed and Functional
Partner Onboarder module installed without errors.
Reports are successfully generated and visible in S3 or NFS storage.
Correct S3 bucket configuration provided during installation.
Mimoto Installed Successfully
Database host and port are correctly configured in values.yaml.
SSL certificate handling works correctly (self-signed or public domain).
All Mimoto pods are running and healthy.
Onboarding New Issuer for VCI
certs/oidckeystore.p12 is correctly created with all required keys and aliases.
Issuer onboarding can be verified through logs or API calls.
Pods Running and Healthy
All Mimoto-related pods are in Running or Completed status.
Verified via kubectl get pods -n mimoto
Services Registered and Reachable
All microservices are listed and accessiblekubectl get services -n mimoto
External Access Verified
Health endpoint responds successfully curl -k https://<your-mimoto-domain>/health
HTTP 200 response received.
Logs: Check pod logs for errors: kubectl logs <pod-name> -n mimoto
ConfigMaps & Secrets: For configuration and credentials
kubectl apply -f - <<EOF
## The data here is of generic interest to modules in different namespaces hence this is marked as inji-stack-config.
## Replace your domain names here.
## api-host: External public access. (Typically required only in production rollouts).
## api-internal-host: Internal secure access over Wireguard.
## By default all domains and subdomains listed below point to api-internal-host. Modify this default behavior ONLY in production rollout as follows:
apiVersion: v1
kind: ConfigMap
metadata:
name: inji-stack-config
namespace: default
data:
inji-version: develop
installation-domain: sandbox.xyz.net
api-host: api.sandbox.xyz.net
iam-external-host: iam.sandbox.xyz.net
api-internal-host: api-internal.sandbox.xyz.net
injiweb-host: injiweb.sandbox.xyz.net
injiverify-host: injiverify.sandbox.xyz.net
injicertify-host: injicertify.sandbox.xyz.net
inji-postgres-host: postgres.sandbox.xyz.net
esignet-mock-host: esignet-mock.sandbox.xyz.net
mosipid-identity-esignet-host: esignet-mosipid.sandbox.xyz.net
esignet-insurance-host: esignet-insurance.sandbox.xyz.net
minio-host: minio.sandbox.mosip.net
EOF
#!/bin/bash
# Installs config-server
## Usage: ./install.sh [kubeconfig]
if [ $# -ge 1 ] ; then
export KUBECONFIG=$1
fi
NS=config-server
CHART_VERSION=12.0.1
read -p "Is conf-secrets module installed?(Y/n) " yn
if [ $yn = "Y" ]; then read -p "Is values.yaml for config-server chart set correctly as part of Pre-requisites?(Y/n) " yn; fi
if [ $yn = "Y" ]
then
echo Create $NS namespace
kubectl create ns $NS
# set commands for error handling.
set -e
set -o errexit ## set -e : exit the script if any statement returns a non-true return value
set -o nounset ## set -u : exit the script if you try to use an uninitialised variable
set -o errtrace # trace ERR through 'time command' and other functions
set -o pipefail # trace ERR through pipes
echo Istio label
kubectl label ns $NS istio-injection=enabled --overwrite
helm repo update
UTIL_URL=https://raw.githubusercontent.com/mosip/mosip-infra/master/deployment/v3/utils/copy_cm_func.sh
COPY_UTIL=./copy_cm_func.sh
DST_NS=config-server # DST_NS: Destination namespace
wget -q $UTIL_URL -O copy_cm_func.sh && chmod +x copy_cm_func.sh
echo Copy configmaps and secrets
$COPY_UTIL configmap inji-stack-config default $NS
if kubectl -n conf-secrets get secret conf-secrets-various >/dev/null 2>&1; then
$COPY_UTIL secret conf-secrets-various conf-secrets $NS
else
echo "Skipping copy, conf-secrets-various secret not found"
fi
if kubectl -n s3 get configmap s3 >/dev/null 2>&1 && kubectl -n s3 get secret s3 >/dev/null 2>&1; then
$COPY_UTIL configmap s3 s3 $NS
$COPY_UTIL secret s3 s3 $NS
else
echo "Skipping copy, s3 config or secret not found"
fi
echo Installing config-server
helm -n $NS install config-server mosip/config-server -f values.yaml --wait --version $CHART_VERSION
echo Installed Config-server.
else
echo Exiting the MOSIP installation. Please meet the pre-requisites and than start again.
kill -9 `ps --pid $$ -oppid=`; exit
fi
chmod +x configserver.sh
./configserver.sh
# On your local machine (connected to K8s cluster via kubectl)
git clone https://github.com/mosip/inji-certify.git
cd inji-certify/deploy
cd redis
./install.sh
cd ../db_scripts
# Update init_values.yaml with your database configuration, update the necessary parameters for your PostgreSQL database. Provide path or how to navigate to this yaml in cloned repo.
./init_db.sh
# On your local machine (connected to K8s cluster via kubectl)
git clone https://github.com/mosip/mimoto.git
cd mimoto/deploy
cd deploy/redis
./install.sh
cd ../../db_scripts
./init_db.sh
cd ../partner-onboarder
./install.sh
cd ../deploy/mimoto
./install.sh
kubectl get pods -n mimoto
kubectl get services -n mimoto
curl -k https://<your-mimoto-domain>/health
git clone https://github.com/mosip/inji-web.git
cd inji-web/deploy
default,inji-default,standalone
cd datashare
./install.sh
cd ..
cd injiweb
./install.sh
kubectl get pods -n injiweb
kubectl get services -n injiweb
curl -k https://injiweb.sandbox.xyz.net/health
git clone https://github.com/mosip/inji-verify.git
cd inji-verify/deploy
cd ../db_scripts
# Update init_values.yaml with your database configuration, update the necessary parameters for your PostgreSQL database.
./init_db.sh
cd ../deploy
./install-all.sh
kubectl get pods -n inji-verify
kubectl get services -n inji-verify
curl -k https://injiverify.sandbox.xyz.net/health
./delete-all.sh
./restart-all.sh
Typical Deployment Scenarios
Basic Skill-sets Required
Note: The basic Skill-sets mentioned below, in fact, expects you to know the following to be able to deploy it from scratch and that too on a bare metal servers (On-Premise). This should not get intimidating as in typical scenarios we expect the infrastructure to be deployed by an experienced 'System-Admin/DevOps'. However in case you want to evangelize Inji in your organization and want to have a hands-on with the deployment, this guide helps you with the steps and instructions to achieve this.
Deployment Architecture of Inji
Typical Deployment Order
Deployment Considerations for On-Premise Inji Stack
Prerequisites for Overall Deployment
Personal Computer
Operating Systems
Note:
Ignored scenarios are not related to particular use cases and 34 scenarios are known issues can be tracked from INJICERT-681, INJICERT-1118, INJICERT-1176
Tools and Utilities
Setting Up Wireguard
Note: In case you already have VPN configured to access nodes privately please skip Wireguard installation and continue to use the same VPN.
Setting up Wireguard VM and wireguard bastion server
Note:
Remove [Cluster] complete section from copied hosts.ini file.
Add below mentioned details:
ansible_host : public IP of Wireguard Bastion server. eg. 100.10.20.56
ansible_user : user to be used for installation. In this ref-impl we use Ubuntu user.
ansible_ssh_private_key_file : path to pem key for ssh to wireguard server. eg. ~/.ssh/wireguard-ssh.pem
Note:
Permission of the pem files to access nodes should have 400 permission. sudo chmod 400 ~/.ssh/privkey.pem
These ports are only needed to be opened for sharing packets over UDP.
Take necessary measure on firewall level so that the Wireguard server can be reachable on 51820/udp.
Note:
Increase the number of peers above in case more than 30 wireguard client confs (-e PEERS=30) are needed.
Change the directory to be mounted to wireguard docker as per need. All your wireguard confs will be generated in the mounted directory (-v /home/ubuntu/wireguard/config:/config).
Setup Wireguard Client on your PC
Base Infrastructure Setup
What do we mean here by Base Infrastructure Setup?
Prerequisites for Base Infrastructure Setup
On-Prem Server Requirements
VMs-Virtual Machines (Hardware, Network, Certificate and DNS) - Along with Nginx server (use Loadbalancer if required)
Note: Network Requirements
All the VM's should be able to communicate with each other.
Need stable Intra network connectivity between these VM's.
All the VM's should have stable internet connectivity for docker image download (in case of local setup ensure to have a locally accessible docker registry).
DNS Requirements
PC Requirements
Setting Up Kubernetes Cluster
K8s (Kubernetes) Cluster Configuration
Ingress and Storage Class setup
Note:
Output should show the cluster name to confirm you are pointing to right kubernetes cluster.
If not pointing to right K8 cluster change the kubeconfig to connect to right K8 cluster.
Enable firewall with required ports:
Note:
Script prompts for:
* NFS Server: NFS server ip for persistence.
* NFS Path : NFS path for storing the persisted data. eg. /srv/nfs/mosip/
Inji K8's (Kubernetes) cluster Nginx server setup
[Optional] Monitoring module deployment
[Optional] Alerting setup
[Optional] Logging module setup and installation
Core Infrastructure Components Setup
Inji Stack Configmap: For inji K8's env
Note: You can find the inji-stack-cm.yaml file in the deployment scripts or configuration directory of the Inji stack repository, typically under the deploy or k8s folder. If it is not present, you can create it using the sample configmap YAML provided in this guide, and then update the domain names as per your environment before applying it to your Kubernetes cluster
conf-secret installation
Config Server Installation
Inji Stack Deployment
Deploying Inji Certify
Understanding the Deployment Approach for Inji Certify
Deployment Architecture for Inji Certify
Deployment Process
What Happens During Installation
Note :
Ensure nelow mentioned services are listed in the output result of above command.
You can even check Rancher incase deployed.
1. inji-certify
2. inji-softhsm
Note :
Ensure below mentioned services are listed in the output result of above command.
You can even check Rancher incase deployed.
1. inji-certify
2. inji-softhsm
Success Criteria for Inji Certify Deployment
Important Notes
Troubleshooting
Deploying Mimoto backend for Inji Wallet
Understanding the Deployment Approach of Mimoto
Deployment Process
Note:
If you are running the Onboarder in a separate INJI cluster, update the extraEnvVars section in values.yaml accordingly.
Verification Steps
Important Notes
Success Criteria for Mimoto Deployment
Troubleshooting
Deploying Inji Web Wallet
Understanding the Deployment Approach of Inji Web Wallet
Deployment Architecture for Inji Web Wallet
Deployment Process of Inji Web Wallet
Important Notes
Success Criteria for Inji Web Wallet Deployment
Troubleshooting
Deploying Inji Verify
Understanding the Deployment Approach of Inji Verify
Update the allowed IP's to subnets CIDR ip . e.g. 10.10.20.0/23
Share the updated peer.conf with respective peer to connect to wireguard server from Personel PC.
ansible_ssh_private_key_file : path to pem key for ssh to wireguard server. eg. ~/.ssh/nodes-ssh.pem
Make sure all the nodes are covered in the provided CIDR range. (nginx server, K8 cluster nodes for observation as well as mosip).
contains a Search dashboard which shows only the error logs of the services, called MOSIP Error Logs dashboard.
contains a Search dashboard which show all logs of a particular service, called Inji Service Logs dashboard.
contains dashboards which show insights into Inji processes, like the number of UINs generated (total and per hr), the number of Biometric deduplications processed, number of packets uploaded etc, called Inji Insight dashboard.
contains dashboards which show how quickly different MOSIP Services are responding to different APIs, over time, called Response Time dashboard.
Supports integration with Kubernetes, Docker, and Helm for seamless deployments.
Is host (<node1-ip>) a Control Plane host (y/n)? [y]: y
Is host (<node1-ip>) a Worker host (y/n)? [n]: y
Is host (<node1-ip>) an etcd host (y/n)? [n]: y
`cluster_name: sandbox-name`
INFO[0000] Building Kubernetes cluster
INFO[0000] [dialer] Setup tunnel for host [10.0.0.1]
INFO[0000] [network] Deploying port listener containers
INFO[0000] [network] Pulling image [alpine:latest] on host [10.0.0.1]
...
INFO[0101] Finished building Kubernetes cluster successfully
The link transaction endpoint is invoked from Wallet-app.
Validates the link-code and its expiry and generates the linkTransactionId. This linkTransactionId is linked to transactionId returned from /oauth-details endpoint.
Returns the auth-factors, clientName, logoUrl, User claims, authorize scopes along with linkTransactionId.
Note:
Wallet-app will hereafter address the transaction with this linkTransactionId for the /authenticate and /consent endpoints.
Body
requestTimestringRequired
linkCodestringRequired
Link code as received by the wallet-app from the QR code scanning.
Responses
200
OK
application/json
responseTimestringOptional
linkTransactionIdstringOptional
Unique link-transaction-id.
clientNameobjectOptional
OIDC client name in different languages where language is the key and client name
is the value. Default name is passed in @none key.
logoUrlstringOptional
Registered OIDC client Logo URL.
authorizeScopesstring[]Optional
List of requested scopes to be permitted by the end user.
essentialClaimsstring[]Optional
List of client request mandatory claim names.
voluntaryClaimsstring[]Optional
List of client request optional claim names.
typestring · enumRequired
Name of the authentication method
Possible values:
countintegerOptional
Applicable for biometric based authentication, number of bio segments to be captured for authentication.
bioSubTypesstring[]Optional
Applicable for biometric based authentication. Can be more specific about which bio segments should be captured.
configsobjectOptional
credentialScopesstring[]Optional
List of valid credential scopes requested
errorCodestring · enumOptionalPossible values:
errorMessagestringOptional
post/linked-authorization/v2/link-transaction
Linked Authentication Endpoint V2
post
Once end user provides the user identifier (UIN/VID) and all the required auth challenge to the Wallet-app, this endpoint will be invoked from wallet-app.
Supported auth-challenge depends on the integrated authentication server.
Validates linkedTransactionId.
Validates null / empty individualId.
Invokes kyc-auth call to integrated authentication server (IDA).
Relays error from integrated authentication server to UI on failure.
It validates stored userconsent against the requested claims and scopes
On Authentication Success: linkTransactionId and consentAction is returned in the below response without any errors.
On Authentication Failure: Error list will be set with the errors returned from the integrated authentication server.
This is the same transactionId sent in the link-transaction response.
individualIdstringRequired
User identifier (UIN/VID).
authFactorTypestring · enumRequired
Defines the type of auth challenge. It should be same as authfactor.type (oauth-details response).
Possible values:
challengestringRequired
Actual challenge as string.
formatstring · enumRequired
Format of the challenge provided.
Possible values:
post/linked-authorization/v2/authenticate
Linked Consent Endpoint V2
post
Once the authentication is successful and user consent is obtained, this endpoint will be invoked by the wallet app to send the accepted consent and permitted scopes.
Validates linkedTransactionId.
Validate accepted claims and permitted scopes in the request and the signature.
If valid, stores the accepted claims, permitted scopes and signature in the consent registry.
Transaction id echoed starting from /authorize call.
permittedAuthorizeScopesstring[]Optional
List of permitted scopes by end-user.
acceptedClaimsstring[]Optional
List of accepted essential and voluntary claims by end-user.
signaturestringOptional
Signature of permittedscopes and acceptedclaims from inji
Responses
200
OK
application/json
responseTimestringOptional
linkedTransactionIdstringOptional
This is the same transactionId sent in the link-transaction response.
errorCodestring · enumOptionalPossible values:
errorMessagestringOptional
post/linked-authorization/v2/consent
VC Issuance endpoint
post
Once the access token is received via the token endpoint, Wallet should invoke this endpoint to get the verifiable credential.
Authorizations
AuthorizationstringRequired
Access token received from /token endpoint
Body
formatundefined · enumRequired
Format of the Credential to be issued.
Possible values:
proof_typeundefined · enumRequired
The proof object MUST contain a proof_type claim of type JSON string denoting the concrete proof type.
Possible values:
jwtstringOptional
When proof_type is jwt, a proof object MUST include a jwt claim
cwtstringOptional
When proof_type is cwt, a proof object MUST include a cwt claim
@contextstring[]Optional
typestring[]Required
credentialSubjectobjectOptional
Responses
200
OK
application/json
formatstringRequired
JSON string denoting the format of the issued Credential.
credentialobject | stringRequired
Contains issued Credential. MUST be present when acceptance_token is not returned. MAY be a JSON string or a JSON object, depending on the Credential format.
400
Bad Request
application/json
401
Unauthorized
application/json
post/vci/credential
200
OK
Responses
200
OK
application/json
responseTimestringOptional
linkedTransactionIdstringOptional
This is the same transactionId sent in the oauth-details response.
consentActionstring · enumOptional
This field indicates the need to capture user consent or not
