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!

• Roadmap 2026

• Roadmap 2025

• Roadmap 2024

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.

How do I contribute?

For code contributions, refer here.

To engage with us on our community forum, visit here.

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.

What all you will find here:

• Infrastructure Requirements

• Deployment Architecture

• Deploying Inji

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!

The 'Setup' section offers a detailed overview of the process and steps involved in building and deploying Inji Certify.

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.

Refer to Inji Certify API Documentation here - https://mosip.stoplight.io/docs/inji-certify/25f435617408e-open-api-definition

This section is for hands-on testing of Inji Mobile. Use it to validate real end-user flows.

It includes sandbox exercises and user-facing guidance. Use it when you want to try features quickly.

What you’ll find in this section

• Try It Out. Start quickly in a sandbox setup.

• Workflow. Understand the end-to-end user journey.

• End User Guide. Step-by-step usage for common actions.

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

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.

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.

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

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

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.

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.

Inji Certify is currently compatible and certified with the following browsers:

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:

1. Inji Wallet Backend (Mimoto)

2. Authorization Server for Authentication Using Inji Wallet Credentials

3. Credential Issuer

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.

• Functional Overview: Concepts, plugins, and how Certify fits together.

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:

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

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

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

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

Overview

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.

• Navigate to Community.

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

\

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

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

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.

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.

Release Name: Inji Certify 0.8.0

Support: Developer Release

Release Date: 30th April, 2024

Overview

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:

• Credential Issuance

• Effortless Installation

Repository Released

Known Issues

No Known Issues

Documentation

• Feature Documentation

• Local Setup

Inji Mobile is the mobile wallet app in the Inji stack. Use it to download, store, and share verifiable credentials (VCs).

What you’ll find here

• Overview: What the app is, and what it supports.

• Test: Try the app flows, sandbox content, and user guides.

• Setup: Local setup prerequisites and environment needs.

• Develop: Architecture, components, integrations, and customization docs.

• API: API references used by the wallet and supporting services.

• : Deployment instructions and pointers.

• Releases: Version history and test reports.

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.

The current specification is in draft state.

Contribution

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:

  1. It is prohibited to collect any personally identifiable information (PII) or phone details.

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

  3. Recording or transmitting IP addresses, user details, Phone IMEI, phone numbers, or user photos in telemetry or logs is strictly prohibited.

  4. The use of phone numbers and device fingerprints should be limited to managing the SDK license.

Overview

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 W3C Bitstring Status List 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 here to explore.

Why This Feature Matters

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

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

  • Status entries where statusPurpose == "revocation".

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

1. Format coverage:

   • Revocation checks currently apply only to credentials using the (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.

2. iOS signature verification:

• : To learn how revocation works with Inji Mobile Wallet

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

• Publishing others' private information, such as a physical or email address, without their explicit permission

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 .

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 is available across multiple platforms and programming languages, making it accessible for diverse development environments:

• : Available as an NPM package for web and Node.js applications

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.

1. Presentation Layer (Green)

The following table summarizes the main technologies, tools, and frameworks used to build the Inji Wallet application:

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

• Android 6.0+ (Hardware-backed keystore)

• iOS 13.0+ (Secure Enclave + Keychain)

• Maven Snapshots are available

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

Inji VC Renderer is a library designed to render Verifiable Credentials (VCs) by converting SVG templates into visual SVG images. The library dynamically replaces placeholders in SVG templates with actual Verifiable Credential JSON data, strictly following the JSON Pointer Algorithm (RFC6901) for value extraction.

Key Responsibilities:

• VC Rendering Library

  • Downloads SVG templates from the VC's render method

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.

1. 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).

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

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: Ensures that sensitive credentials (eg: Driving Licenses ) are issued only after validating an authoritative credential (eg: National ID).

VCI Client library enables carrying out the credential request from the consumer application (mobile wallet or web) and downloading the VC.

• Request credentials from OID4VCI-compliant credential issuers

• Supports both the Verifiable Credential download flows defined in the OID4VCI specification:

  • Issuer Initiated Flow (Credential Offer Flow).

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

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

Release Version: v0.13.1

Release Type: Developer Release

Release Date: 5th December, 2025

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.

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.

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.

Release Name: Inji Certify 0.8.1 (Patch)

Support: Developer Release

Release Date: 17th May, 2024

Version 0.8.1 introduces significant enhancements to streamline the management and issuance of verifiable credentials using the Sunbird platform. Key updates include:

1. Sunbird Installation and Configuration:

   • Postman collections are provided for creating issuers and credential schemas.

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:

• Inji certify Docker compose testing(VCI segregations)

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

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

The Github link for the xls file is

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:

1. eSignet Version Upgrade:

   • The eSignet version has been upgraded to 1.4.1 for compatibility with different Certify plugins.

2. OIDC-UI Pod Version Bump:

   • The OIDC-UI pod version has been upgraded to 1.4.1.

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

   • The updated Certify plugins are now available as 0.2.1-SNAPSHOT versions.

For detailed steps click here to view the file.

1. Setup: Configure InjiWeb and Mimoto in your local environment.

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

3. Private Key Addition: Insert the private key from the OIDC client created in eSignet into the .p12 file in Mimoto.

4. Verification:

The following table outlines the tested and certified compatibility of Inji Certify 0.9.0 with other modules.

Below is the list of known issues. To read in detail and view all the topics related to Inji Certify please click .

Overview

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.

The sample app illustrates how to:

• Securely generate and manage cryptographic keys

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

For the detailed feature list of Inji Mobile Wallet, refer !

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

The custom wallet application integrates several Inji stack libraries, which provide ready-made methods for credential flows.

1. Create Activity

   • In Android Studio, create a new project with an empty activity.

2. Add Dependencies

   • Open app/build.gradle

The flow below shows how the custom verifiable credentials wallet downloads and verifies a credential.

• Call generate_key_pair() from Secure Keystore.

  • Generates RS256 or ES256 key pair, stored in Android hardware keystore.

• Retrieve issuer metadata (client_id, redirect_uri, etc.) from trusted issuers list.

• VCI Client returns a callback requiring user authorization.

• Wallet opens a web-view to the Authorization Server.

• User authenticates, and an authorization code is returned to the wallet.

• Wallet sends the authorization code to the VCI Client, fulfilling the callback.

• VCI Client triggers get_token_response callback.

• Wallet makes a POST request to the token endpoint with auth code.

• Authorization Server responds with an access token + cNonce.

• VCI Client requests a Proof JWT (get_proof_JWT).

• Wallet constructs JWT with claims: nonce, aud, iat, exp.

• Wallet calls verify() from VC Verifier 🔎, passing credential JSON.

• VC Verifier checks validity (signature, expiry, issuer).

• Verification result returned (True/False with message).

• Wallet calls Pixelpass to generate QR code.

• Pixelpass returns a QR image for displaying to the verifier.

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.

• Database Script Correction – Shedlock table has been added to DB scripts to support distributed job scheduling and ensure reliable execution in production setups.

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

The following table outlines the tested and certified compatibility of 0.12.2 with other modules.

Open Source Governance Process at MOSIP

1. Overview

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.

2. Governance Structure

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.

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.

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

• 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

We use 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 . 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.

Project Lead initiates the release process. The process can be found .

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.

• This is the module built for verifiers to receive VC via BLE. This is a wrapper built on Tuvali with simplified APIs.

Repository

Installation

• Add a dependency in package.json

• Publishing npm module is WIP. Once it's published, it can be integrated as any other npm module.

API Specification

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

• 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

Transitions between states is shown below:

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.

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

Deployment:

The table below specifies the tools needed to deploy Inji Certify:

Overview

The recommended Github workflow here is for developers to submit code and documentation contributions to Inji open-source repositories.

Repositories

Setup your development machine

1. Fork the repository.

2. Clone the fork to your local machine. E.g.:

   Copy

   $ git clone https://github.com/<your_github_id>/inji.git

3. Set the upstream project as the original from where you forked. E.g.:

   Copy

   $ cd inji
   $ git remote add upstream https://github.com/mosip/inji.git

4. Make sure you never directly push upstream.

5. Confirm the origin and upstream.

   This should display origin and upstream as below:

1. Create a new issue in GitHub.

1. Follow the issue template provided.

2. Please provide as much information as possible.

3. 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 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 for a faster response.

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

1. Docker setup - Authorization endpoints pointing to collab.mosip.net

Test Rate: 100%, With Pass Rate: 96% and Fail Rate: 0%

Test Rate: 100%, With Pass Rate: 100% and Fail Rate: 0%

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

Overview

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.

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

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)

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.

For deeper technical details about the Key Manager component itself, you can refer to the MOSIP documentation .

This is 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?

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

• docker-compose.yml file with the mimoto setup.

1. Prepare the environment:

   • The docker-compose folder's config directory holds the configuration files Mimoto needs to act as BFF for Inji Wallet.

   • Create a certs folder in the

To enable Google OAuth2.0 authentication, follow these steps:

1. Go to the Google Cloud Console: Visit .

2. Create a New Project: If you don't already have a project, create one from the project dropdown.

3. Enable the OAuth Consent Screen: "APIs & Services" > "OAuth consent screen". Select "External" and configure the required fields. Save.

4. Create OAuth 2.0 Credentials: "APIs & Services" > "Credentials" > "Create Credentials" > "OAuth 2.0 Client IDs" > "Web application".

Set the eSignet host Mimoto should use — update mosip.esignet.host in mimoto-default.properties (or application-local.properties if running Mimoto via IDE) to point to the eSignet instance for your target environment:

Then point your local Inji Wallet build at this Mimoto instance — set MIMOTO_HOST to your ngrok URL (not localhost) in the wallet app's .env file (see ).

Note:

• For local env use .

• Replace http://localhost:8099 by the ngrok public domain at the following places:

  • token_endpoint in mimoto-issuers-config.json

Release Version: 0.12.1

Release Type: Developer Release

Release Date: 11th September, 2025

Overview

Inji Certify v0.12.1, brings enhancements in automation of testing to support latest eSignet release v1.6.2

Major Highlights/ Features

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 eSignet v1.6.2.

Bug Fixes

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

The following table outlines the tested and certified compatibility of <release version> with other modules.

Release Version: v0.10.2 (Patch)

Release Type: Developer Release

Release Date: 21st Feb, 2025

Overview

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.

Bug Fixes

Below is the list of bug fixes as part of the 0.10.2 release:

The following table outlines the tested and certified compatibility of <release version> with other modules.

Version: v1.0.0-alpha.1

• Name: Release Version: 1.0.0-alpha.1

• Date: 31st July, 2026

• Release Notes

Version: 0.14.0

• Name: Release Version: 0.14.0

• Date: 25th March, 2026

• Name: Release Version: v0.13.1

• Date: 5th December, 2025

• Name: Inji Certify 0.13.0

• Date: 28th November, 2025

• Name: Inji Certify 0.12.2

• Date: 23rd October, 2025

• Name: Inji Certify 0.12.1

• Date: 11th September, 2025

• Name: Inji Certify 0.12.0

• Date: 26th August, 2025

• Name: Inji Certify 0.11.0

• Date: 2nd May, 2025

• Name: Inji Certify 0.10.2

• Date: 21st Feb, 2025

• Name: Inji Certify 0.10.1

• Date: 3rd February, 2025

• Name: Inji Certify 0.9.1 (Patch)

• Date: 3rd October, 2024

• Name: Inji Certify 0.9.0

• Date: 22nd August, 2024

• Name: Inji Certify 0.8.1 (Patch)

• Date: 17th May, 2024

• Name: Inji Certify 0.8.0

• Date: 30th April, 2024

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

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

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

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

• 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

• 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

• 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

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.

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.

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.

Release Version: v0.10.1

Release Type: Developer Release

Release Date: 3rd February, 2025

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

1. Local deployment using docker compose

Release Version: v0.11.0

Release Type: Developer Release

Release Date: 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 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.

Before proceeding with the installation, ensure you have the following installed:

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.

Users don’t need to remember IDs or complete repetitive verification steps. Credential selection and consent happen directly within the wallet.

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:

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

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