1 of 100

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

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

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

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

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.

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.

Try It Out

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.

Collab Guides

Explore the guides of the various Inji Modules from below:

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.

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

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!

Supported Integrations

Project Governance

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:

Contribution

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 .

To engage with us on our community forum, visit .

Code Contribution

Overview

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

Repositories

License

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

All MOSIP's repositories are licensed under the terms of .

All trademarks are the property of their respective holders. Other products and company names mentioned 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.

What all you will find here:

Deployment Architecture
Deploying Inji

Contact Us

Have a question or feedback? We are here for you!

Reach out to us through the channel that best fits your purpose, as outlined below.

Community Forum Join the conversation at 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 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 [email protected] — we’re happy to connect!

Inji Wallet

Inji Mobile

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.

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.

Architecture Layers

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

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.

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

Installation

iOS (Swift)

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

Android (Kotlin)

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.

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

Telemetry

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

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:

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, API is called. For retrieving the credential types and display properties, .well-known location is referred for every issuer from the

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

Activate credentials

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.

Configuration

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.

Issuers Listing

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.

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

VC Issuance endpoint

For credential request, refer credential_endpoint attribute in issuer's configuration response.

Customizations

Countries also have the option to customize Inji as per their requirements. Refer to the documents below for more information on the same.

The following customizations are available in Inji:

Locale customization

Steps to Support a new language

Under locales folder, localization of a particular language JSON file has to be added.
Language JSON has to be imported in i18n.ts and load the resources to i18next as follows. import fil from './locales/fil.json'; const resources = { en, fil, ar, hi, kn, ta };
To ensure the language needs to be included in the const SUPPORTED_LANGUAGES.
To use with react, must include the key with the 't' function

About libraries

Inji Wallet has the capability to support multiple languages.
i18next is an internationalization framework. It provides the standard i18n features such as , , , and . It provides a complete solution to localize products from the web to mobile and desktop.
react-i18next is a set of components, hooks, and plugins that sit on top of i18next, and is specifically designed for React.

Configuration

Configuration for Inji Wallet

The configurable properties for Inji Wallet can be found at inji-default.properties. This property file is maintained as one for each deployment environment. On this repository, each environment configuration is placed in a corresponding branch specific to that environment.

Refer to inji-default.properties of Collab environment.

These values will be used by Inji Wallet via Mimoto. Mimoto loads all the configurations and exposes an API which is used by the Inji Wallet application to fetch and store the configurations in the local storage.

API used to fetch these configurations: https://api.collab.mosip.net/v1/mimoto/allProperties

The implementers can choose to use the existing configurations or add new configurations to them.

The properties used by Inji Wallet are:

mosip.inji.faceSdkModelUrl(https://${mosip.api.public.host}/inji): This is the path of the file server from where the face SDK model can be downloaded.
mosip.inji.modelDownloadMaxRetry(10): The maximum times the application will try to fetch the model.
mosip.inji.audience(ida-binding): This is used to generate the JWT token which will be passed during online login.

Test

Inji Mobile is a versatile digital wallet designed to securely manage, store, and share trusted data as Verifiable Credentials (VCs) through a seamless and user-friendly interface. This mobile application offers several key functionalities aimed at enhancing the user experience, ensuring robust data security, and simplifying digital credential management.

Key features include:

Inji Wallet enables users to securely download their verifiable credentials (VCs) directly onto their mobile devices. As part of this process, verification occurs to ensure the authenticity and validity of the credentials. Once verified, the VCs are securely stored using the device’s hardware-based secure keystore, ensuring that the credentials are protected from unauthorized access.

Try It Out

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

Releases

Version: 0.20.0

Name: Inji Mobile Wallet 0.20.0

Date: 22nd October, 2025

Test Report

Tuvali

This is the module that supports transferring verifiable credentials (VC) over Bluetooth Low Energy (BLE).

Let's have a look at how BLE communication works in general between the two devices A & B.

Repository:

tuvali presents the kotlin library for tuvali
to get details on swift artifact.
contains the artefacts in maven.

Installation:

Usage as a Kotlin library (for native android)

In build.gradle.kts add the following:

The kotlin library has been added to your project.

Usage as a Swift library (for native ios)

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.

How does BLE Communication work?

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
disconnect from device

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
The characteristic subscription on Peripheral

More details about other BLE terminology used here can be found in standard BLE specifications of 4.2 and above.

How Tuvali works with BLE to transfer VC from Central to Peripheral

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

1. Connection Setup & Cryptographic key exchange

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

2. Data transfer

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"

3. Connection closure

Disconnect initiated by Peripheral:

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.

Disconnect initiated by Central

Central also performs disconnect in the following scenarios:

On a successful data transfer
Non-recoverable error on Central
Peripheral is out of range/ disconnected
Destroy Connection API

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.

Error Codes And Error Scenarios:

Error Code Format: <Component(2 Character)Role(1 Character)>-<Stage(3 Character)>-<Number(3 Character)>

List of Supported Error Codes:

UnknownException: TUV_UNK_001
WalletUnknownException: TVW_UNK_001
CentralStateHandlerException: TVW_UNK_002
WalletTransferHandlerException: TVW_UNK_003

Error Scenario 1: The verifier receives a `Failed to transfer` message and wallet receive a `Disconnected` message on the screen.

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.

Error Scenario 2: The wallet receives a `Failed to transfer` message and the verifier receives a `Disconnected` message on the screen.

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.

Retry scenarios

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:

Constants

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.

Characteristics UUID

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.
RESPONSE_SIZE_CHAR_UUID (00000007-5026-444A-9E0E-D6F2450F3A77): Characteristic for sending VC size to the verifier.

Service UUID

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

OpenID4VP

This library enables consumer applications (mobile wallet) to share users Verifiable Credentials with Verifiers who request them online. It adheres to the OpenID4VP specification draft version 23, which outlines the standards for requesting and presenting Verifiable Credentials.

Library Functionalities: Processing the Request from Decoding to Verifier Response

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.
Constructs the vp_token without proof section and sends it back to the consumer application for generating Json Web Signature (JWS).

Supported features

Feature

Supported values

Android: Kotlin package for OpenID4VP:

Repository

inji-openid4vp kotlin repo -

Installation

Snapshot builds are available .

Note: implementation "io.mosip:inji-openID4VP:0.1.0-SNAPSHOT"

Create instance of OpenID4VP library to invoke its methods

val openID4VP = OpenID4VP("test-OpenID4VP")

APIs

Below are the APIs provided by this library:

1. authenticateVerifier

Receives a list of trusted verifiers & Verifier's encoded Authorization request from consumer app(mobile wallet).
Decodes and parse the request, extracts the clientId and verifies it against trusted verifier's list clientId.
Returns the Authentication response which contains validated Presentation Definition of the Authorization request.

Parameters

Name

Type

Description

Sample

Exceptions

DecodingException is thrown when there is an issue while decoding the Authorization Request
InvalidQueryParams exception is thrown if
- query params are not present in the Request
- there is an issue while extracting the params

This method will also notify the Verifier about the error by sending it to the response_uri endpoint over http post request. If response_uri is invalid and validation failed then Verifier won't be able to know about it.

2. constructVerifiablePresentation

Receives a map of input_descriptor id & list of verifiable credentials for each input_descriptor that are selected by the end-user.
Creates a vp_token without proof using received input_descriptor IDs and verifiable credentials, then returns its string representation to consumer app(mobile wallet) for signing it.

Parameters

Name

Type

Description

Sample

Exceptions

JsonEncodingFailed exception is thrown if there is any issue while serializing the vp_token without proof.

This method will also notify the Verifier about the error by sending it to the response_uri endpoint over HTTP post request. If response_uri is invalid and validation failed then Verifier won't be able to know about it.

3. shareVerifiablePresentation

This function constructs a vp_token with proof using received VPResponseMetadata, then sends it and the presentation_submission to the Verifier via a HTTP POST request.
Returns the response back to the consumer app(mobile app) saying whether it has received the shared Verifiable Credentials or not.

Parameters

Name

Type

Description

Sample

Exceptions

JsonEncodingFailed exception is thrown if there is any issue while serializing the generating vp_token or presentation_submission class instances.
InterruptedIOException is thrown if the connection is timed out when network call is made.
NetworkRequestFailed exception is thrown when there is any other exception occurred when sending the response over http post request.

4. sendErrorToVerifier

Receives an exception and sends its message to the Verifier via an HTTP POST request.

Parameters

Name

Type

Description

Sample

Exceptions

InterruptedIOException is thrown if the connection is timed out when network call is made.
NetworkRequestFailed exception is thrown when there is any other exception occurred when sending the response over http post request.

iOS: Swift package for OpenID4VP:

Repository

inji-openid4vp-ios-swift swift repo ->

Installation

Clone the repo.
In your swift application go to file > add package dependency > add the https://github.com/mosip/inji-openid4vp-ios-swift in git search bar > add package.
Import the library and use.

Create instance of OpenID4VP library to invoke its methods

let openID4VP = OpenID4VP(traceabilityId: "AXESWSAW123", networkManager: NetworkManager)

APIs

1. authenticateVerifier

Receives a list of trusted verifiers & Verifier's encoded Authorization request from consumer app(mobile wallet).
Takes an optional boolean to toggle the client validation.
Decodes and parse the request, extracts the clientId and verifies it against trusted verifier's list clientId.
Returns the validated Authorization request object

Parameters

Name

Type

Description

Sample

Exceptions

DecodingException is thrown when there is an issue while decoding the Authorization Request
InvalidQueryParams exception is thrown if
- query params are not present in the Request
- there is an issue while extracting the params

2. constructVerifiablePresentation

Receives a dictionary of input_descriptor id & list of verifiable credentials for each input_descriptor that are selected by the end-user.
Creates a vp_token without proof using received input_descriptor IDs and verifiable credentials, then returns its string representation to consumer app(mobile wallet) for signing it.

Parameters

Name

Type

Description

Sample

Exceptions

JsonEncodingFailed exception is thrown if there is any issue while serializing the vp_token without proof.

3. shareVerifiablePresentation

This function constructs a vp_token with proof using received VPResponseMetadata, then sends it and the presentation_submission to the Verifier via a HTTP POST request.
Returns the response back to the consumer app(mobile app) saying whether it has received the shared Verifiable Credentials or not.

Parameters

Name

Type

Description

Sample

Exceptions

JsonEncodingFailed exception is thrown if there is any issue while serializing the generating vp_token or presentation_submission class instances.
InterruptedIOException is thrown if the connection is timed out when network call is made.
NetworkRequestFailed exception is thrown when there is any other exception occurred when sending the response over http post request.

sendErrorToVerifier

Receives an exception and sends its message to the Verifier via an HTTP POST request.

Parameters

Name

Type

Description

Sample

Exceptions

InterruptedIOException is thrown if the connection is timed out when network call is made.
NetworkRequestFailed exception is thrown when there is any other exception occurred when sending the response over http post request.

OpenID4VP library and Inji Wallet integration:

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.

End User Guide

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

On iOS device

Install the test flight app on your device.
Follow the steps mentioned .

The below screenshots explain the next steps after you get access.

First launch of the app

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.

Download of Verifiable Credentials

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!

1. Download National ID (MOSIP VC)

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

2. Download Insurance VC

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

Detailed view of the downloaded VC

Once we click on the downloaded VC on the Home Page, the detailed view opens up for the VC.

Detailed View of National ID 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.

Detailed View of Insurance 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.

Download Credential by Scanning a QR Code (Credential Offer with Pre-Auth Code)

This flow allows you to download credentials simply by scanning a QR code, without login or manual input of ID/Identifier or other data.

1. Pre-Authorized Credential Offer (Without Transaction Code)

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.

B. Pre-Authorized Credential Offer (With Transaction Code)

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.

Viewing the history of the downloaded VC

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.

Activity Log for a VC:

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

Pre-requisites

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 section. Clicking on this section will display the received cards. If the receiver has not received any card, this section will be empty.

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.
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 section. Clicking on this section will display the received cards. If the receiver has not received any card, this section will be empty.

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.
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 section. Clicking on this section will display the received cards. If the receiver has not received any card, this section will be empty.

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.

Cross-Device Flow (OpenID4VP)

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.
The wallet reads the verifier’s request and shows you a list of matching credentials

Same-Device Flow (OpenID4VP)

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.
The wallet fetches the verifier’s request.

Selective Disclosure Flow (IETF SD-JWT VP)

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).
The Inji Wallet parses the SD-JWT credential

Pinning a VC

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.

Activating a VC

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.

Deleting a VC

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.

Search

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.

Data backup and restore

Backup

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.
Users will be notified of success or failure.

Data backup - Android

Data backup- ios

Restore

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

Restore - Android

Restore - ios

Inji Deployment Guide

Overview

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

How is this guide structured and organized?

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

Each section provides direct steps and references to external resources for a streamlined deployment experience.

Typical Deployment Scenarios

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

Basic Skill-sets Required

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.

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.

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.
Kubernetes Administration

Deployment Architecture of Inji

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

Typical Deployment Order

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.

Deployment Considerations for On-Premise Inji Stack

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

Prerequisites for Overall Deployment

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.

Personal Computer

Follow the steps mentioned here to install the required tools on your personal computer to create and manage the k8's cluster.

Operating Systems

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)

Tools and Utilities

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
- - any client version above 3.0.0 and add below repos as well

: version:
: version: 1.15.0
Create a directory as mosip in your PC and:
- 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

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.

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.
Bastion server listens on UDP port 51820.

Note: You can also refer to for more on Wireguard configuration and management.

Prerequisites to Set Up Wireguard

Wireguard Bastion Host

VMs and Hardware Specifications
- 1 VM (ensure to set up active-passive for HA)
- Specification - 2 vCPUs, 4 GB RAM, 8 GB Storage (HDD)
Server Network Interfaces

Setting up Wireguard VM and wireguard bastion 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

Note:

Remove [Cluster] complete section from copied hosts.ini file.

Execute ports.yml to enable ports on VM level using ufw:ansible-playbook -i hosts.ini ports.yaml

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.

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>
- Create directory for storing wireguard config files. mkdir -p wireguard/config

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

Install Wireguard client on your PC using .
Assign wireguard.conf:
SSH to the wireguard server VM.
cd /home/ubuntu/wireguard/config

Once connected to wireguard, you should be now able to login using private IP’s.

Base Infrastructure Setup

What do we mean here by Base Infrastructure Setup?

"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.
- Network configuration (internal connectivity, firewall rules, DNS).
- SSL certificate setup for secure communications.

Prerequisites for Base Infrastructure Setup

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.

On-Prem Server Requirements

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-Virtual Machines (Hardware, Network, Certificate and DNS) - Along with Nginx server (use Loadbalancer if required)

VMs and Hardware Specifications
- 3 VMs (allocate etcd, control plane, and worker nodes accordingly for HA)
- Specification - 8 vCPUs, 32 GB RAM, 64 GB Storage (HDD)
Network Interfaces

Note: Network Requirements

All the VM's should be able to communicate with each other.
Need stable Intra network connectivity between these VM's.

DNS Requirements

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.
keycloak.xyz.net

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.

PC Requirements

See the section for common prerequisites required for all deployments.

Setting Up Kubernetes Cluster

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.

K8s (Kubernetes) Cluster Configuration

Ingress and Storage Class setup

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.
Check Ingress Gateway services:

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

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.

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.

Inji K8's (Kubernetes) cluster Nginx server setup

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
- Install Pre-requisites:

Generate wildcard SSL certificates for your domain name.
- sudo certbot certonly --agree-tos --manual --preferred-challenges=dns -d *.sandbox.mosip.net -d sandbox.mosip.net
  - replace sanbox.mosip.net with your domain.

Nginx server setup for Inji K8's cluster

Move to nginx directory in your local:
cd $K8_ROOT/mosip/on-prem/nginx/
Open required ports :
- Use any editor to create new hosts.ini

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
- Publically accessible domains (comma seperated with no whitespaces)

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

[Optional] Monitoring module deployment

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.
Click on Install

[Optional] Alerting setup

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.
Alerting is part of cluster monitoring, where alert notifications are sent to the configured email or slack channel.

Install Default alerts along some of the defined custom alerts:

Alerting is installed.

[Optional] Logging module setup and installation

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.

Core Infrastructure Components Setup

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 Configmap: For inji K8's env

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.

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

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

Inji Stack Deployment

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

Deploying Inji Certify

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.

Understanding the Deployment Approach for Inji Certify

Inji Certify is deployed as containerized microservices in your Kubernetes cluster.

Deployment Architecture for Inji Certify

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

What Gets Installed?

Kubernetes Pods: Running Inji Certify microservices
Services: For internal communication
Ingress Rules: For external access via NGINX
ConfigMaps & Secrets: For configuration and credentials

Deployment Process

Step 1: Pre-Deployment Checklist

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

What Happens During Installation

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
Ingress Configuration: Configures routes through Istio gateway

###3 Verification Steps

Check Pod Status

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

Verify Service Endpoints

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

Test External Access

Success Criteria for Inji Certify Deployment

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.

Important Notes

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

Troubleshooting

If deployment fails, check:

Cluster Connectivity: kubectl cluster-info
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.

Deploying Mimoto backend for Inji Wallet

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.

Understanding the Deployment Approach of Mimoto

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
ConfigMaps & Secrets: For configuration and credentials

Deployment Process

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:

- Note: Before running the Postgres install script, update the POSTGRES_HOST value in install.sh with the correct PostgreSQL host.

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.

Note: If you are running the Onboarder in a separate INJI cluster, update the extraEnvVars section in values.yaml accordingly.

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.

Verification Steps

Check Pod Status:
Check Service Endpoints:
Test External Access:

Important Notes

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.

Success Criteria for Mimoto Deployment

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.

Troubleshooting

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
Logs: Check pod logs for errors: kubectl logs <pod-name> -n mimoto

You can also refer to the file for deployment steps given in individual module repositories.

Deploying Inji Web Wallet

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.

Understanding the Deployment Approach of Inji Web Wallet

Inji Web UI and dataShare are deployed as containerized microservices in your Kubernetes cluster.

Deployment Architecture for Inji Web Wallet

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
ConfigMaps & Secrets: For configuration and credentials

Deployment Process of Inji Web Wallet

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.

Important Notes

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

Success Criteria for Inji Web Wallet Deployment

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.

Troubleshooting

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
Logs: Check pod logs for errors: kubectl logs <pod-name> -n injiweb

You can also refer to the file for deployment steps given in individual module repositories.

Deploying Inji Verify

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.

Understanding the Deployment Approach of Inji Verify

Inji Verify is deployed as containerized microservices in your Kubernetes cluster.

Deployment Architecture for Inji Verify

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

What Gets Installed?

Kubernetes Pods: Running Inji Verify microservices
Services: For internal communication
Ingress Rules: For external access via NGINX
ConfigMaps & Secrets: For configuration and credentials

Deployment Process of Inji Verify

Step 1: Pre-Deployment Checklist

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

What Happens During Installation

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
Ingress Configuration: Configures routes through Istio gateway

Verification Steps

Check Pod Status

Verify Service Endpoints

Test External Access

Managing Inji Verify Services

Delete all services:
Restart all services:

Important Notes

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

Success Criteria for Inji Verify Deployment

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.
Pods Running and Healthy

Troubleshooting

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
Logs: Check pod logs for errors: kubectl logs <pod-name> -n inji-verify

You can also refer to the file for deployment steps given in individual module repositories.

Contribution and Community

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.

Inji

Inji

Overview

Inji’s Key Capabilities

Inji Stack Components

Inji Certify– Credential Issuance

Inji Wallet – Credential Holding and Sharing

Inji Verify – Credential Verification

Real-World Applications

Interoperability and Standards

Inji: How the Pieces Work Together

How it works?

Summary

Try It Out

Overview

Collab: Development Integration Environment

How to use:

Collab Guides

Synergy: Stable Integration Environment

Feedback and Support

Use case

Use Cases of Verifiable Credentials and Their Impact

Use Case 1: Healthcare Industry

Roadmap

Supported Integrations

Project Governance

Open Source Governance Process at MOSIP

1. Overview

Contribution

How do I contribute?

Code Contribution

Overview

Repositories

License

Setup

Contact Us

Inji Wallet

Inji Mobile

Develop

Architecture

Architecture Layers

Integration Guides

SDK Integration Specifications

Permissions & Requirements

Permissions

Android

iOS

Minimum Version Requirements

Capabilities

Secure Keystore

Platforms Supported

Artifacts

Installation

iOS (Swift)

Android (Kotlin)

Face Match

Contribution

Repository

NPM Package

Installation

Face Compare with liveness is coming soon

Telemetry

Specifications

Backend Services

Mimoto

Support for downloading VC from multiple Issuers

Download via eSignet

Activate credentials

Configuration

Issuers Listing

eSignet

Online login

QR code scanning and login to the service provider portal

Inji Certify

Overview

Download VC

VC Issuance endpoint

Customizations

Locale customization

Steps to Support a new language