1 of 19

Inji

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

Try It Out

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

Access resources on Collab, our sandbox environment, through the provided.

Explore the guides of the various Inji Modules from below:

Using Mock Data

Introduction

Welcome to the Inji ecosystem, which encompasses the Inji Mobile Wallet, Inji Web Wallet, Inji Verify, and Inji Certify. These tools provide a powerful platform for managing and verifying digital credentials with ease. This document guides you through using mock data to explore the functionalities of each component, allowing you to understand and leverage their capabilities effectively. Read on to discover how you can interact with Inji's ecosystem, using demo credentials and mock data as explained below.

Whether you're a Developer, System Integrator, or an Enthusiast eager to dive into the world of verifiable credentials, use this guide for necessary information to get started with Inji in our Collab environment. Let's begin this journey of seamless setup and exploration.

This guide explains the use of mock data for following:

Inji Mobile Wallet
Inji Web Wallet
Inji Verify

What would you need?

You will need UIN (Unique identification number) as a demo credential whic will allow you to explore Inji's capabilities and experience seamless VC sharing. You can also try this with 'Sample Insurance Credentials'.

Issuance of UIN (Unique identification number) as a demo credential will allow you to explore Inji's capabilities and experience seamless VC sharing firsthand.
Now you can self generate your own UIN Credential using the .
- Click on the Get UIN button located at the top-right corner of the page. This will open the , Alternatively, you can simply click on this to self register. You need to duly fill the self registration form.

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

For sample Insurance Credentials, please provide the below details in the eSignet authentication page:

Policy Name: insuranceCredentials
DOB: 2000-01-01
Policy Number: 12345

The mock data you will need for Inji Web Wallet is same as that of Inji Mobile Wallet (Explained above).

Follow the procedure to try out Inji Verify in our collab environment:

To obtain sample verifiable credentials embedded in a QR code, please initiate the process by following the steps to generate the QR code, click !
To use the QR code with verifiable credentials and test out the Inji Verify application, exploring the scan and upload features, please use the QR codes provided below:

Use case

Current Challenge: Patients often need to share medical records and test results securely across different healthcare providers. This process is cumbersome, requiring manual handling of paper documents or insecure sharing via email and other communication channels.

Solution with Verifiable Credentials: Healthcare providers can issue VCs for vaccination records, allergies, or medication history. VCs can securely store and share medical records, test results, and vaccination history digitally. Patients can then easily share these credentials with other providers, ensuring continuity of care and faster treatment. Patients can control access to their data, ensuring only authorized healthcare providers can verify and access their information.

Benefits:

Reduced Friction: Patients can easily share verified medical credentials with healthcare professionals, streamlining the consultation and treatment process

Resources

Overview

The resources section provides a comprehensive introduction to the Inji modules — Inji Mobile Wallet, Inji Web Wallet, Inji Verify, and Inji Certify, showcasing how its modules deliver trusted, low-cost, and scalable credential management across sectors.

Each demonstration video explains the product’s purpose, setup, features, and practical applications. Together, they offer an end-to-end understanding of how verifiable credentials can be issued, held, and verified instantly, across both digital and paper-based formats.

Video Playlist

Watch the complete series on YouTube: Inji Stack Demonstration Playlist

Inji Stack: Overview

What you'll learn:

An introduction to the Inji Stack, the open-source suite by MOSIP for verifiable credentials.
Explanation of how the core modules like Inji Certify, Inji Wallet, and Inji Verify work together to create a trusted digital credential ecosystem.
Overview of Inji's role in enabling secure, interoperable, and privacy-preserving data exchange.
Demonstrates the potential of verifiable credentials in sectors like education, healthcare, governance and many more.

What you'll learn:

Introduction to Inji Certify, the credential issuance module of the Inji Stack.
Demonstrates how authorized entities can issue, manage, and revoke verifiable digital credentials.
Explains interoperability with OpenID4VC, W3C VC, and other standards.

What you'll learn:

Step-by-step local deployment of Inji Certify using Docker Compose.
Explains configuration of plug-ins, environment variables, and credential templates.
Demonstrates issuance and revocation flows in a local testing environment.

What you'll learn:

In-depth look at Inji Certify's credential issuance architecture.
Explains credential templates, signing algorithms, revocation APIs, and integration with data sources.
Details plug-in architecture for flexible issuance from multiple registries or databases.

What you'll learn:

Comprehensive walkthrough of the Inji Mobile Wallet app.
Demonstrates secure storage, management, and sharing of verifiable credentials.
Covers key features:

What you'll learn:

Introduction to the Inji Web Wallet, a browser-based wallet that complements the mobile app.
Demonstrates credential management and secure sharing using QR codes in both digital and printed form.
Explains how the web wallet supports W3C VC, OpenID4VP, and ISO standards for global interoperability.

What you'll learn:

Step-by-step guide to setting up the Inji Web Wallet locally using IntelliJ instead of Docker for faster iteration.
Walkthrough of dependencies, configuration steps, and environment setup.
Demonstrates how to load and test credentials within the local environment.

What you'll learn:

Configuration of Mimoto backend for Inji Wallet integration using Docker Compose.
This setup provides a ready-to-run local Docker environment for Mimoto, which acts as the backend for Inji Web and the BFF (Backend-for-Frontend) for Inji Mobile, enabling secure OIDC-based authentication and credential exchange.
It helps developers quickly configure, test, and integrate Mimoto with Inji services in a non-production environment.

What you'll learn:

Overview of Inji Verify, the verifier module for digital and paper-based credential verification.
Demonstrates secure, instant QR-based verification workflows.
Highlights modular SDK integration, interoperability with OpenID4VP, and verifier backend service.

What you'll learn:

Detailed explanation of Inji Verify's architecture, including backend services, SDKs, and UI components.
Covers OpenID4VP flows, handling of verifiable presentations, and data validation.
Shows how to run Verify locally using Docker Compose and how to integrate SDK components into React-based applications.

The workshop aims to provide a comprehensive understanding of the Inji ecosystem, focusing on its various components, configuration, and practical usage. It covered essential topics to help participants effectively use and integrate Inji's features.

Understanding DID Methods: The workshop explains the different Decentralized Identifier (DID) methods supported by Inji, helping participants grasp how digital identities are managed.
OIDC Client and p12 File Creation: Participants learn how to create an OIDC client and generate a p12 file, ensuring secure key storage and authentication processes.
Configuring Mimoto in Inji Web: Detailed steps are provided to configure Mimoto within the Inji Web application, addressing common issues and ensuring seamless integration.

The Workshop demonstrates how to integrate Inji Certify, a credential issuance platform, with a custom data provider plugin to issue 'Verifiable Credentials'. The specific use case covered is issuing farmer IDs based on official land registry data.

Data Setup: A sample farmer registry is created in a database with details like National ID, Name, Phone Number, and Land Ownership Information.
Configuration: A velocity template is defined to format the data, issuer information and verification keys are configured, and a "well-known" property is set up.
Plugin Development: A data provider plugin is created to fetch farmer data from the registry based on the national ID.

The webinar delves into the technical architecture and implementation details of the Inji Stack, specifically focusing on the Inji Wallet and its integration with other stacks/components like eSignet and Inji Certify. The webinar offers a comprehensive overview of the technical intricacies involved in building a decentralized credential issuance and verification system using the MOSIP's Inji platform.

Inji Wallet: A mobile application that acts as both a digital wallet for storing verifiable credentials (VCs) and a verifier of VCs.
Integration with eSignet and Inji Certify: eSignat is used for authentication and authorization, while Inji Certify is responsible for issuing VCs.
Technical Architecture: The webinar covers the high-level architecture, including the use of Mimoto as a backend for frontend (BFF), the role of the Tuvali library for secure VC transfer, and the integration of native modules for specific functionalities.

The webinar delves into MOSIP's solutions for identity verification and credential management also to see how national IDs empower citizens in the digital age.

National ID as an Enabler: Learn how national IDs can be used to access various services.
Digital Transformation: Explore how IDs can streamline processes for citizens and governments.
eSignet: An online authentication solution supporting multiple methods like OTP, digital wallets, and biometrics.

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:

Process of open source contributions and review of code in this project.
Decision-making process on backlogs and including contributions.

2. Governance Structure

The MOSIP project follows a simple structure with 3 levels.

Level 1 - MOSIP Technology Committee. This committee is responsible for high level roadmap and policy decisions such as licensing, and technology stack.

Level 2 - Project leadership. This is the executive leadership at MOSIP that includes key project roles within MOSIP such as product owner, engineering lead, and architects. These members will be appointed as maintainers and lead in the project by MOSIP.

Level 3 - Members. This is a set of people who are working on the project.

Given below is a list of specific roles and their responsibilities.

Maintainers are individuals who have “Commit” rights; And are the primary caretakers of the code and the strategic vision of the project. They are empowered to make decisions and resolve disputes for all contributions. They are appointed by MOSIP.
Project Lead is the chair of the committee of maintainers. They are appointed by MOSIP.
Contributors are the people or organisations who take part actively in the project and its meetings, code, design, and test and are recognized for their contributions. The contributors are part of the GitHub Members and would be actively involved in the discussion of a PR and review. Members strongly influence the Maintainer's decision.

Scope of Contributions

The whole of the project is open to contributions. The kind of contributions that are welcome include:

Code
Documentation
Design
Raising Bugs

Code, Documentation & Design
- All artefacts including the code are maintained in the github repository.Contributions can be made by raising a Pull Request.
Reporting Issues & Feature Request

We use to track the work associated with the project (account required). That is where issues open for community contribution can be found.

The process to contribute the code is present . Once code is submitted, it is reviewed through the following process:

At least two members should have reviewed the submitted contribution for the pull request to be accepted. The maintainers may request for more reviews of the code from other relevant members.
If the members deem the submitted code to be critical to overall product development, they can seek the inputs of the relevant product owners for the review process.
The maintainers review the two (or more) sets of comments received from the tech leads and the submitted code before taking a decision regarding committing the code to the appropriate branch.

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

Attribution is in accordance with the relevant licence. Individual and affiliated contributors will be listed.

The key decisions to be taken are for the following activities

Roadmap and backlog priority
Triaging of bugs and requirements
Accepting a contribution Pull Request)
Releases

Most decisions will be made in periodical meetings where owners of the relevant aspect of work present a case for a decision and the decision will be made either by consensus, or by majority where a quorum exists. The maintainers of the project will be the decision makers. The project lead will have veto power on decisions due to their expertise and commitment to the vision of the project. Contributors can share their views in these meetings for consideration.

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

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

Code Contribution

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

Fork the repository.
Clone the fork to your local machine. E.g.:

Code of Conduct

Preamble

Community was created to foster an open, innovative and inclusive community around open source & open standards. To clarify expected behaviour in our communities we have adopted the Contributor Covenant. This code of conduct has been adopted by many other open-source communities and we feel it expresses our values well.

Our Pledge

We as members, contributors, and leaders pledge to make participation in our community a harassment-free experience for everyone, regardless of age, body size, visible or invisible disability, ethnicity, sex characteristics, gender identity and expression, level of experience, education, socio-economic status, nationality, personal appearance, race, caste, colour, religion, or sexual identity and orientation.

We pledge to act and interact in ways that contribute to an open, welcoming, diverse, inclusive, and healthy community.

Our Standards

Examples of behaviour that contributes to a positive environment for our community include:

Demonstrating empathy and kindness toward other people
Being respectful of differing opinions, viewpoints, and experiences
Giving and gracefully accepting constructive feedback
Accepting responsibility and apologizing to those affected by our mistakes, and learning from the experience
Focusing on what is best not just for us as individuals, but for the overall community

Examples of unacceptable behaviour include:

The use of sexualized language or imagery, and sexual attention or advances of any kind
Trolling, insulting or derogatory comments, and personal or political attacks
Public or private harassment

Community leaders are responsible for clarifying and enforcing our standards of acceptable behaviour and will take appropriate and fair corrective action in response to any behaviour that they deem inappropriate, threatening, offensive, or harmful.

Community leaders have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, and will communicate reasons for moderation decisions when appropriate.

This Code of Conduct applies within all community spaces and also applies when an individual is officially representing the community in public spaces. Examples of representing our community include using an official e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event.

Instances of abusive, harassing, or otherwise, unacceptable behaviour may be reported to the community leaders responsible for enforcement at . All complaints will be reviewed and investigated promptly and fairly.

All community leaders are obligated to respect the privacy and security of the reporter of any incident.

Community leaders will follow these Community Impact Guidelines in determining the consequences for any action they deem in violation of this Code of Conduct:

Community Impact: Use of inappropriate language or other behaviour deemed unprofessional or unwelcome in the community.

Consequence: A private, written warning from community leaders, providing clarity around the nature of the violation and an explanation of why the behaviour was inappropriate. A public apology may be requested.

Community Impact: A violation through a single incident or series of actions.

Consequence: A warning with consequences for continued behaviour. No interaction with the people involved, including unsolicited interaction with those enforcing the Code of Conduct, for a specified period of time. This includes avoiding interactions in community spaces as well as external channels like social media. Violating these terms may lead to a temporary or permanent ban.

Community Impact: A serious violation of community standards, including sustained inappropriate behaviour.

Consequence: A temporary ban from any sort of interaction or public communication with the community for a specified period of time. No public or private interaction with the people involved, including unsolicited interaction with those enforcing the Code of Conduct, is allowed during this period. Violating these terms may lead to a permanent ban.

Community Impact: Demonstrating a pattern of violation of community standards, including sustained inappropriate behaviour, harassment of an individual, or aggression toward or disparagement of classes of individuals.

Consequence: A permanent ban from any sort of public interaction within the community.

This Code of Conduct is adapted from the , version 2.1, available at .

Community Impact Guidelines were inspired by .

For answers to common questions about this code of conduct, see the FAQ at . Translations are available at .

GenderMag

What is GenderMag?

The GenderMag Methodology aims to analyze and mitigate gender biases in users’ problem-solving interactions with software. It underscores the importance of accounting for gender differences in human-computer interaction (HCI) during the software design process.

Process

We identified two personas based on their familiarity with technology and their ability to embrace technological progress. The personas are:
- Abi, who is either Abigail or Abishek, is 45 years old. She works as a homemaker, is literate, but not very tech- savvy. Her internet connectivity is moderate, and she does not have a personal phone.
- Tim, who is either Timothy or Timara, a 24-year-old financial consultant, is literate, tech-savvy, and boasts excellent internet connectivity. Additionally, he owns the latest phone.
Examine the feature, systematically walk through the process, assess their information handling, and pinpoint any problems.

During the walkthrough, we pinpointed inclusivity concerns in the Inji Wallet app’s user interface and experience. Subsequently, we took steps to mitigate these issues, aiming to eliminate digital entry barriers.

As part of Phase1, below P1 items are fixed in the v0.11.0-Inji Wallet release:

Sl No

Problem statement

Solution

Jira number

As part of Phase2, below P1, P2 items are fixed in the v0.12.0 release of Inji Wallet:

Sl No

Problem Statement

Solution

Jira number

License

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

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

All Inji code is owned and maintained by International Institute of Information Technology, Bangalore, on behalf of Inji.

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

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:

Infrastructure Requirements
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 community.mosip.io to ask questions, share ideas, and explore discussions about MOSIP and its solutions.

Feedback We truly value your input. Every suggestion counts in shaping our products and processes. Click here to share your feedback and help us make Inji better. \

Other Queries For anything more specific or direct, feel free to write to us at info@mosip.io — we’re happy to connect!

{ "credential": { "credentialSubject": { "gender": "Male", "primaryCropType": "Maize", "mobileNumber": "9876543210", "postalCode": "453000", "landArea": "3 hectares", "fullName": "John Doe", "secondaryCropType": "Rice", "dateOfBirth": "25-05-1990", "face": "data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABwAAAAFCAYAAABW1IzHAAAAHklEQVQokWNgGPaAkZHxPyMj439sYrSQo51PBgsAALa0ECF30JSdAAAAAElFTkSuQmCC", "farmerID": "987654321", "villageOrTown": "Koramangala", "district": "Bangalore", "id": "did:jwk:eyJrdHkiOiJSU0EiLCJlIjoiQVFBQiIsInVzZSI6InNpZyIsImtpZCI6Iml3Qkl1Q2QzaFU1NlBWM3VTc3gzekhMc1E4SXdYckdHdmh6YkE1VlJuQkEiLCJhbGciOiJSUzI1NiIsIm4iOiJtMWlMQ0prNzA5VkpIbUF2MURsWUxsblA0UDEtLXFfU3Q3aVo3WjhWbXk0d0Mxb2FTQWxXdjFXZjlKQXg2YmQ3OXdMbDhINEkwa25GeG9FbkktTUhvOUtGRXpFcGdJNXZIUHY2X0M2dWI4RmUwaXphRVFXTlY3VEpVRG54MVZ5OU5UZS15ekFVd2dfWk91Y0pFb3hyQW54VXM5OFcyTWpyUmtZdHVQcTlKRUxVTzRJM0wxX1B5S21hRG8zN0xCR3NVamhLVmQ0X0VzTkVPQ3AwQTZwbnBaUUd1S1RteXVhMUVYSDhLWUVTSEZ4alA4NGVCaGk0YmZPSWMwQjQ2VlZrVG81WG9TeUtnRi1xemRyTGFQRGJwZGxBaVNKMEJ5Vk5jaUE3Z2ctWEJLQkV0QVd1b19EQ3pYZUsxREJKT2txMXlkWEJzeWdjeGtpVmdobnFtUTFsVHcifQ==", "state": "Karnataka", "landOwnershipType": "Owner" }, "validUntil": "2027-10-09T03:08:19.711Z", "validFrom": "2025-10-09T03:08:19.711Z", "type": [ "VerifiableCredential", "FarmerCredential" ], "@context": [ "https://www.w3.org/ns/credentials/v2", "https://piyush7034.github.io/my-files/farmer.json", "https://w3id.org/security/suites/ed25519-2020/v1" ], "issuer": "did:web:piyush7034.github.io:my-files:sample-ed25519", "credentialStatus": { "statusPurpose": "revocation", "statusListIndex": "7", "id": "http://localhost:8090/v1/certify/credentials/status-list/649d3d36-2719-42eb-9f00-ac479a906059#7", "type": "BitstringStatusListEntry", "statusListCredential": "http://localhost:8090/v1/certify/credentials/status-list/649d3d36-2719-42eb-9f00-ac479a906059" }, "proof": { "type": "Ed25519Signature2020", "created": "2025-10-08T21:38:19Z", "proofPurpose": "assertionMethod", "verificationMethod": "did:web:piyush7034.github.io:my-files:sample-ed25519#LYs95rEHKsqm1_TIFJxffLUXHZL1rM_h-UuwRi6PtN4", "proofValue": "z5Z3Rj9rhV5b6whiq4EgZaD8gmtsBtfMEqwNXAgasCxtBRCpc35DkiGFyRfy8NYDtXBDX6RjAUpWfgNGn94t2ywgm" } } }

{ "credential": { "issuanceDate": "2025-10-09T03:05:40.782Z", "credentialSubject": { "gender": "Male", "primaryCropType": "Maize", "mobileNumber": "9876543210", "postalCode": "453000", "landArea": "3 hectares", "fullName": "John Doe", "secondaryCropType": "Rice", "dateOfBirth": "25-05-1990", "face": "data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABwAAAAFCAYAAABW1IzHAAAAHklEQVQokWNgGPaAkZHxPyMj439sYrSQo51PBgsAALa0ECF30JSdAAAAAElFTkSuQmCC", "farmerID": "987654321", "villageOrTown": "Koramangala", "district": "Bangalore", "id": "did:jwk:eyJrdHkiOiJSU0EiLCJlIjoiQVFBQiIsInVzZSI6InNpZyIsImtpZCI6IkVIdXU5eU5MN1VFcnFDd0hWOUdPTk5KWWdxQmVvMVhUTmY0OU95Tk1LN0EiLCJhbGciOiJSUzI1NiIsIm4iOiJ2VmF1dFFYa3JMUXVaU2hGWWFDNkRMNEZOcnMzcm5meTVkVjhyWVJRQnhyOW1oZllfdGxwTzc5QzRiZnplS1BzaVBXN0c4NEMtZGt4QlNOR3RXV0wwdy1oX3JOd3Y2eUFMT1VZaGdtcnZVeGhWakhCRzFMdTFtTUhERF9JZlpJb0lpV1JRZkpvMGZYMFBzZ2FrRWhIZmxjWHdPNk1DaVItNGVNTUdhNU0zR2ViTVQtUHlsQVVKYzJiN2NoaGFvTlJYQWNWbTBsZTFmUG5RRGJfQ21XMENxOW9kOHFjQUwtellqc0F3MnJzMWxhZ3RDcTdsSXVIWkszUnF2U0NQb2lmSG1ZZEZvdzZnNkF5eTlyNzhxc2VwYkU3d3JDYS1aRF92TkxHblpTbXVac3RicmxxZkxfelFfdnlwNjM1NTMtRmNPNGlKNW1Md0w4Z2pwTWRrVmVMRFEifQ==", "state": "Karnataka", "landOwnershipType": "Owner" }, "type": [ "VerifiableCredential", "FarmerCredential" ], "@context": [ "https://www.w3.org/2018/credentials/v1", "https://piyush7034.github.io/my-files/farmer.json", "https://w3id.org/security/suites/ed25519-2020/v1" ], "issuer": "did:web:piyush7034.github.io:my-files:sample-ed25519", "expirationDate": "2027-10-09T03:05:40.782Z", "proof": { "type": "Ed25519Signature2020", "created": "2025-10-08T21:35:40Z", "proofPurpose": "assertionMethod", "verificationMethod": "did:web:piyush7034.github.io:my-files:sample-ed25519#LYs95rEHKsqm1_TIFJxffLUXHZL1rM_h-UuwRi6PtN4", "proofValue": "z3BW5Tx6ZHJ53rriixAwkrbjGEurLP5eNWwZQQkmEMEEWtLK5qJRThA6wyuyaiin7ucfaUDk4H2BKVBLpSAqcDPcu" } } }

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 Inji Stack Deployment section.

How is this guide structured and organized?

Introduction: Provides an overview of the Inji stack, deployment scenarios, required skill sets, system architecture, and key considerations for on-premise deployments.
: Outlines infrastructure details, hardware/software/network requirements, and initial setup steps.
: Guides you through setting up the foundational infrastructure for Inji, including Kubernetes provisioning, NGINX configuration, networking, and optionally, the observability cluster and monitoring module.
: Explains the external services required—such as the database, artifactory, etc.,—and provides steps for their installation and configuration.
: Offers step-by-step instructions to deploy Inji modules (Certify, Wallet, Verify) along with configuration guidance.
: Highlights how you can contribute code, share feedback, or reach out for support while working with the application.

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

The scenarios listed below are only a few examples. Inji Stack can support many more deployment possibilities depending on the country, organization, or individual requirements.

Deployment Scenario

Modules Included

Countries / Use Case Example

Deploying Inji Stack is easier while you have Base Infrastructure ready, still, if you want to deploy it 'On-Premise' and from scratch, this guide helps you with the instructions to achieve this.

Linux System Administration: Proficiency in Linux command-line operations, user and permission management, and basic networking.
Networking Fundamentals: Knowledge of firewalls, load balancers, DNS, and secure network configuration.
Containerisation: Experience with Docker or similar container technologies for building and managing service containers.

Links to the deployment architecture diagrams below take you to respective sections of this guide and illustrate the high-level deployment architecture for Inji Stack, showing how core components interact within the Kubernetes cluster, including ingress, services, and external integrations.

Inji Wallet

For a smooth and error-free setup of the Inji Stack, it is recommended to follow the deployment order starting with Inji Certify, followed by mimoto backend for Inji Wallet(Mobile+Web), next the Inji Web Wallet, and finally Inji Verify. This sequence ensures that foundational services and dependencies are available before deploying modules that rely on them, leading to a more stable and seamless deployment experience.

The section helps you to have a quick understanding of what you should expect when you go about deploying Inji-Stack, especially if you are deploying it 'On-Premise' and from scratch.

Inji modules are deployed as microservices in a Kubernetes cluster.
Wireguard is used as a trust network extension to access the admin, control, and observation panes.
Inji uses Nginx server for:

While we have placed the Prerequisites specific to a section under respective sections itself, here, this 'Prerequisites' lists the common ones which you will need no matter which component you are deploying such as Wireguard, PC - Tools and Utilities etc.

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

The Inji stack can be deployed with a PC having one of the following operating systems, however for this guide we have considered a linux machine with Ubuntu 22.04 LTS.

Linux (Ubuntu 22.04 LTS - recommended for production deployments)
Windows
macOS (OSX)

You should have these tools installed on your local machine from where you will be running the ansible playbooks to create and manage the k8 cluster using RKE1.

- version > 2.12.4
Command line utilities:
- - version 2.12.4 or higher

: version:
: version: 1.15.0
Create a directory as mosip in your PC and:

Wireguard bastian server provides secure private channel to access Inji cluster. Bastian server restricts public access, and enables access to only those clients who have their public key listed in Wireguard server.

WireGuard is a modern, fast, and secure VPN (Virtual Private Network) protocol and software that creates encrypted tunnels between devices.

Wireguard bastian server provides secure private channel to access Inji cluster.
Bastian server restricts public access, and enables access to only those clients who have their public key listed in Wireguard server.
Bastion server listens on UDP port 51820.

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)

Before proceeding, Create a Wireguard server VM with the mentioned specification under 'Prerequisites' above. This VM will be used to set up the Wireguard server. Once the VM is ready, open the required ports on the Bastion server VM.

Open required ports in the Bastian server VM

Configure the firewall on the Bastion server virtual machine to allow network traffic through specific ports needed for your application or remote access.

cd $K8_ROOT/wireguard/
Create copy of hosts.ini.sample as hosts.ini and update the required details for wireguard VM
cp hosts.ini.sample hosts.ini

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

Install docker

execute docker.yml to install docker and add user to docker group:

Setup Wireguard server
- SSH to wireguard VM
- ssh -i <path to .pem> ubuntu@<Wireguard server public ip>

Install Wireguard client on your PC using .
Assign wireguard.conf:
SSH to the wireguard server VM.

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

"Base Infrastructure Setup" refers to preparing all foundational resources and configurations needed before deploying the Inji stack. This includes provisioning servers/VMs, configuring networks and firewalls, setting up SSL certificates, installing Kubernetes clusters and required tools (Docker, kubectl, Helm, etc.), establishing secure access (e.g., Wireguard VPN), and deploying essential services like NGINX, storage, monitoring, and logging. It ensures the environment is ready for Inji stack installation.

Provisioning foundational resources required for the Inji stack, including:
- Virtual machines (VMs) or servers as per hardware requirements.
- Network configuration (internal connectivity, firewall rules, DNS).

Before deploying any Inji Stack module, ensure that the following common prerequisites are met. These requirements apply to all modules and must be fulfilled to guarantee a smooth and successful deployment process.

Note: You can deploy Inji on an environment and operating system that supports Kubernetes-based deployments. Ensure your chosen OS and infrastructure meet the prerequisites and compatibility requirements. Note: This guide references using Ubuntu Server 22.04 LTS. Note: For large-scale deployments or environments with strict security requirements, an on-premises setup is recommended. For pilot projects, demonstrations, or rapid prototyping, a cloud-based deployment may be more suitable.

Note: Virtual Machines (VMs) can use any operating system as per convenience. For this installation guide, Ubuntu OS is referenced throughout.

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

Below is a sample mapping of domain names to their respective IP addresses and purposes for a typical Inji deployment. Update these as per your environment.

rancher.xyz.net
- Maps to: Private IP of Nginx server or load balancer (Observation cluster)
- Purpose: Rancher dashboard for monitoring and managing the Kubernetes cluster.

Note: Ensure all DNS records are created and point to the correct IP addresses (public or private) as per your network design. For private domains, access is typically restricted via Wireguard VPN.

See the section for common prerequisites required for all deployments.

Note: For detailed VM provisioning steps and hardware/network prerequisites, see the above for VM - Hardware specification and more.

Find the kubernetes infrastructure repository which contains the scripts to install and configure Kubernetes cluster with required monitoring, logging and alerting tools.
- After reviewing the k8s-infra repository and ensuring that you also have all the required tools and utilities installed on your local machine, the next step is to provision and configure your Kubernetes cluster nodes (VMs or servers) according to the hardware and network requirements specified under 'Prerequisites' above. Once your nodes are ready and accessible, proceed to run the provided Ansible playbooks and scripts from the k8s-infra repository to set up the Kubernetes cluster, networking, and essential infrastructure components.

Ingress setup

It is a service mesh for the MOSIP K8 cluster which provides transparent layers on top of existing microservices along with powerful features enabling a uniform and more efficient way to secure, connect, and monitor services.

cd $K8_ROOT/mosip/on-prem/istio
./install.sh
This will bring up all the Istio components and the Ingress Gateways.

Storage classes (NFS)

Multiple storage classes options are available for onprem K8's cluster. In this reference deployment will continue to use NFS as a storage class.

Move to nfs directory in your personel computer.

Create a copy of hosts.ini.sample as hosts.ini.

Update the NFS machine details in hosts.ini file.
Note :
- Add below mentioned details:
- ansible_host : internal IP of NFS server. eg. 10.12.23.21. In our reference implementation using nginx server

SSH to the nfs node:

Clone k8s-infra repo in nginx VM:

Move to the nfs directory:

Execute script to install nfs server:

Note: > * Script prompts for below mentioned user inputs: > > > ..... > Please Enter Environment Name: <envName> > ..... > ..... > ..... > [ Export the NFS Share Directory ] > exporting *:/srv/nfs/mosip/<envName> > NFS Server Path: /srv/nfs/mosip/<envName> > > > * envName: env name eg. dev/qa/uat...

Switch to your personel computer and excute below mentioned commands:

Post installation check:
- Check status of NFS Client Provisioner from your PC, make sure pointing to right kubeconfig file.

Check status of nfs-client storage class.

SSL certificate creation

For Nginx server setup, we need ssl certificate, add the same into Nginx server.
Incase valid ssl certificate is not there generate one using letsencrypt:
- SSH into the nginx server

Generate wildcard SSL certificates for your domain name.
- 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 :

Add below mentioned lines with updated details of nginx server to the hosts.ini and save.

Execute below mentoned command to open required ports:

Login to the nginx server node.
Clone k8s-infra

Provide below mentioned inputs as and when prompted
- MOSIP nginx server internal ip
- MOSIP nginx server public ip

Check Overall nginx and istio wiring

Install httpbin: This utility docker returns http headers received inside the cluster.
httpbin can be used for general debugging - to check ingress, headers etc. Make sure pointing to right kubeconfig file.

To see what is reaching the httpbin (example, replace with your domain name):

Note :
Monitoring in the sandbox environment is optional and can be deployed if required.
For production environments, alternative monitoring tools can be used.
These steps can also be skipped in development environments if monitoring is not needed.

Prometheus and Grafana and Alertmanager tools are used for cluster monitoring.
Select 'Monitoring' App from Rancher console -> Apps & Marketplaces.
In Helm options, open the YAML file and disable Nginx Ingress.

Note:

Alerting in the sandbox environment is optional and can be deployed if required.
For production environments, alternative alerting tools can be used.
These steps can also be skipped in development environments if alerting is not needed.

Install Default alerts along some of the defined custom alerts:

Alerting is installed.

Note :
Logging in the sandbox environment is optional and can be deployed if required.
For production environments, alternative logging tools can be used.
These steps can also be skipped in development environments if logging is not needed.

Inji uses and elasticsearch to collect logs from all services and reflect the same in Kibana Dashboard.

Install Rancher FluentD system : Required for screpping logs outs of all the microservices from Inji k8 cluster.
- Install Logging from Apps and marketplace within the Rancher UI.
- Select Chart Version 100.1.3+up3.17.7 from Rancher console -> Apps & Marketplaces.

Open kibana dashboard from https://kibana.sandbox.xyz.net.

Kibana --> Menu (on top left) --> Dashboard --> Select the dashboard.

This section covers the installation and configuration of essential infrastructure components required for the Inji stack, including configmaps, databases, object storage, secrets management, configuration server, and artifactory.

inji-stack-config configmap: For inji K8's env, inji-stack-config configmap in default namespace contains Domain related information. Follow below steps to add domain details for inji-stack-config configmap.
Update the domain names in inji-stack-cm.yaml correctly for your environment.

Create values.yaml

This ensures that values.yaml is available for your Helm install command and can be referenced directly during the config-server deployment.

Create a values.yaml file that will contain the configuration for the chart and send it to your config-server installation.

Review values.yaml and make sure git repository parameters are as per your installation and enable only the required environment variables.

Open the file and paste the following content into it in the same directory where values.yaml is created.

Run the Script

Once Prerequisites, Base Infrastructure, and the Core Infrastructure Setup and Configuration are complete, now you can proceed with the deployment of the Inji stack components.

For detailed deployment steps, architecture, and module-level instructions, refer to the following:

Inji Wallet

While you have a deployment environment ready, you can now proceed with the installation of Inji Certify by following the steps explained here.

Note: Before deploying Inji Certify, it is recommended to always use the latest . Each release includes enhancements, technical upgrades, and new features to ensure the best experience.

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

Where Will it Run?

Target Environment: Your main Kubernetes cluster
Deployment Method: Helm charts that pull Docker images from container registries
Access Point: Through your configured NGINX ingress at https://injicertify.sandbox.xyz.net

What Gets Installed?

Kubernetes Pods: Running Inji Certify microservices
Services: For internal communication
Ingress Rules: For external access via NGINX

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

Helm Charts Execution: Downloads and deploys Docker containers
Service Registration: Services register with config-server for configuration
Database Initialization: Creates required tables and seed data

###3 Verification Steps

Check Pod Status

Verify Service Endpoints

Test External Access

Deployment Scripts Executed Successfully
- All deployment scripts (install.sh) for Redis and Inji Certify microservices complete without errors.
- No failed Helm releases or container pull issues during deployment.

Remote Deployment: You deploy from your local machine to the remote K8s cluster
Container Registry: Docker images are pulled from public/private registries during deployment
Configuration: All configuration comes from your config-server and configmaps

If deployment fails, check:

Cluster Connectivity: kubectl cluster-info
Prerequisites: Ensure config-server, postgres, redis are running
Resources: Verify cluster has sufficient CPU/memory

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

Need help or have questions? In case you encounter any issues or have queries while using or deploying the application, please post them in the . The community and maintainers are available to assist you.

This section provides a structured, step-by-step guide to deploy Mimoto, which serves as the backend for Inji Mobile Wallet and Inji Web Wallet. Follow these instructions to ensure a successful and reproducible deployment.

Note: Before deploying mimoto, it is recommended to always use the latest released version. Each release includes enhancements, technical upgrades, and new features to ensure the best experience.

Mimoto is deployed as containerized microservices in your Kubernetes cluster.

Where Will it Run?

Target Environment: Your main Kubernetes cluster
Deployment Method: Helm charts and shell scripts that pull Docker images from container registries
Access Point: Through your configured NGINX ingress (domain as configured)

What Gets Installed?

Kubernetes Pods: Running Mimoto microservices
Services: For internal communication
Ingress Rules: For external access via NGINX/Istio

Step 1: Pre-Deployment Checklist

Before deploying the mimoto (backend for Inji Wallet), ensure the following infrastructure components and configurations are in place as mentioned below:

Step 2: Clone and Navigate to Deployment Scripts

Step 3: Install Redis (If Not Already Installed)

To install Redis, run:

Step 4: Initialize Database

Update the values file for PostgreSQL initialization as needed, then run:

Step 5: Install Partner Onboarder

To install the Partner Onboarder module:

During the execution of the install.sh script, you will be prompted to provide information for the S3 bucket, including its name and URL.

Once the job completes, log in to your S3 or NFS storage and verify the reports. There should be no failures.

Step 6: Install Mimoto

Before installing Mimoto, ensure that the database host and port are correctly configured in the values.yaml file.

To install Mimoto:

During the execution of the install.sh script, you will be prompted to specify whether a public domain and a valid SSL certificate are present on the server.

If the server does not have a public domain and valid SSL certificate, select n. This will enable an init-container with an emptyDir volume, which will download the server's self-signed SSL certificate and mount it to the Java keystore (cacerts) within the container. This is useful for deployments using self-signed SSL certificates.

Step 6: Onboarding a New Issuer for VCI

To onboard a new issuer for VCI:

Create a folder named certs in the root directory.
Inside certs, create a file named oidckeystore.p12.
Store the keys as different aliases for each issuer in this file.

For more details, refer to the official documentation or the relevant section in the repository.

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

Remote Deployment: You deploy from your local machine to the remote K8s cluster.
Container Registry: Docker images are pulled from public/private registries during deployment.
Configuration: All configuration comes from your config-server and configmaps.

Note: Screenshots for each success criteria step will be added shortly to provide a visual reference.

Deployment Scripts Executed Successfully
- All installation scripts (install.sh) for Redis, Partner Onboarder, and Mimoto complete without errors.
- No failed Helm releases or container pull issues during deployment.

If deployment fails, check:

Cluster Connectivity: kubectl cluster-info

This command checks if your local kubectl is properly configured and can communicate with the Kubernetes cluster.
It displays information about the cluster's master and services, confirming that your connection is active and functional.

Prerequisites: Ensure config-server, postgres, redis are running
Resources: Verify cluster has sufficient CPU/memory
Network: Ensure ingress and DNS are properly configured

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

This section explains how to deploy the Inji Web Wallet, which comes with a reference web UI and DataShare. This web UI serves as a sample implementation to help integrators and countries build their own customized user interface.

Note: Before deploying Inji Web Wallet, it is recommended to always use the latest . Each release includes enhancements, technical upgrades, and new features to ensure the best experience.

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

Where Will It Run?

Target Environment: Your main Kubernetes cluster
Deployment Method: Helm charts that pull Docker images from container registries
Access Point: Through your configured NGINX ingress at https://injiweb.sandbox.xyz.net (and DataShare endpoints as configured)

What Gets Installed?

Kubernetes Pods: Running Inji Web UI and DataShare microservices
Services: For internal communication
Ingress Rules: For external access via NGINX/Istio

Step 1: Pre-Deployment Checklist

Before deploying Inji Web Wallet, ensure the following infrastructure components and configurations are in place as mentioned below:

Step 2: Prepare Your Deployment Environment

From your local machine, you'll run deployment scripts that:

Connect to your Kubernetes cluster via kubectl
Deploy containerized services using Helm charts
Configure ingress rules through Istio/NGINX

Step 4: Clone and Navigate to Deployment Scripts

Step 5: Prepare Configuration

Review and update the values.yaml file for your environment (domain names, DB connection, object store endpoints, etc.).
Ensure the active_profile_env parameter in the config map of the config-server-share is set to:

Step 6: Deploy DataShare (if required)

If DataShare is a separate module, deploy it first:

Step 6: Deploy Inji Web UI

From the deploy directory:

Step 7: Verification Steps

Check pod status:
Check service endpoints:
Test external access:

Step 8: Post-Installation Configuration

Confirm that the active_profile_env in the config-server-share config map is set as described above.
Ensure DNS records for injiweb.sandbox.xyz.net and any DataShare endpoints are correctly mapped to your ingress controller.

Remote Deployment: You deploy from your local machine to the remote K8s cluster
Container Registry: Docker images are pulled from public/private registries during deployment
Configuration: All configuration comes from your config-server and configmaps

Note: Screenshots for each success criteria step will be added shortly to provide a visual reference.

Your deployment is successful if:

Pods are Running and Healthy

All pods in the injiweb namespace show STATUS = Running and READY counts match.
kubectl get pods -n injiweb shows no CrashLoopBackOff or Error.

Services are Registered and Reachable

kubectl get services -n injiweb lists expected Inji Web and DataShare services.
Each service has a valid ClusterIP or LoadBalancer.

Configuration is Applied Correctly

Ensure the active_profile_env parameter in the config map of the config-server-share is set to: default,inji-default, standalone
No config fetch errors appear in Inji Web pod logs.

Ingress/DNS is Working

DNS entries (e.g., injiweb.sandbox.xyz.net) point correctly to your ingress controller.
Running curl k https://injiweb.sandbox.xyz.net/health returns HTTP 200 with a healthy response.

DataShare Module (if deployed) is Accessible

DataShare pods are up and healthy.
DataShare endpoints are reachable and registered in Kubernetes.

No Critical Errors in Logs

Reviewing logs (kubectl logs <pod-name> -n injiweb) shows no failures during startup or runtime.

If deployment fails, check:

Cluster Connectivity: kubectl cluster-info

This command checks if your local kubectl is properly configured and can communicate with the Kubernetes cluster.
It displays information about the cluster's master and services, confirming that your connection is active and functional.

Prerequisites: Ensure config-server, postgres, redis are running
Resources: Verify cluster has sufficient CPU/memory
Network: Ensure ingress and DNS are properly configured

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

This section provides step-by-step instructions to install Inji Verify. Please follow these guidelines to make sure a successful setup in your environment.

Note: Before deploying Inji Verify, it is recommended to always use the latest . Each release includes enhancements, technical upgrades, and new features to ensure the best experience.

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

Where Will It Run??

Target Environment: Your main Kubernetes cluster
Deployment Method: Helm charts that pull Docker images from container registries
Access Point: Through your configured NGINX ingress at https://injiverify.sandbox.xyz.net

What Gets Installed?

Kubernetes Pods: Running Inji Verify microservices
Services: For internal communication
Ingress Rules: For external access via NGINX

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

Helm Charts Execution: Downloads and deploys Docker containers
Service Registration: Services register with config-server for configuration
Database Initialization: Creates required tables and seed data

Check Pod Status

Verify Service Endpoints

Test External Access

Delete all services:
Restart all services:

Remote Deployment: You deploy from your local machine to the remote K8s cluster
Container Registry: Docker images are pulled from public/private registries during deployment
Configuration: All configuration comes from your config-server and configmaps

Note: Screenshots for each success criteria step will be added shortly to provide a visual reference.

Deployment Scripts Executed Successfully
- Deployment scripts (install-all.sh) complete without errors.
- No failed Helm releases or container pull issues during deployment.

If deployment fails, check:

Cluster Connectivity: kubectl cluster-info

This command checks if your local kubectl is properly configured and can communicate with the Kubernetes cluster.
It displays information about the cluster's master and services, confirming that your connection is active and functional.

Prerequisites: Ensure config-server, postgres, redis are running
Resources: Verify cluster has sufficient CPU/memory
Network: Ensure ingress and DNS are properly configured

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

We welcome contributions from everyone!

Check to learn how you can contribute code to this application. If you have any questions or run into issues while trying out the application, feel free to post them in the — we’ll be happy to help you out.

gitRepo: uri: https://github.com/mosip/inji-config version: release-0.8.x ## Folders within the base repo where properties may be found. searchFolders: "" private: false ## User name of user who has access to the private repo. Ignore for public repo username: "" token: "" ``` ``` envVariables: - name: SPRING_CLOUD_CONFIG_SERVER_OVERRIDES_MOSIP_API_PUBLIC_HOST valueFrom: configMapKeyRef: name: inji-stack-config key: api-host enabled: true - name: SPRING_CLOUD_CONFIG_SERVER_OVERRIDES_MOSIP_API_INTERNAL_HOST valueFrom: configMapKeyRef: name: inji-stack-config key: api-internal-host enabled: true - name: SPRING_CLOUD_CONFIG_SERVER_OVERRIDES_MOSIP_PARTNER_CRYPTO_P12_PASSWORD valueFrom: secretKeyRef: key: mosip-partner-crypto-p12-password name: conf-secrets-various enabled: false - name: SPRING_CLOUD_CONFIG_SERVER_OVERRIDES_MPARTNER_DEFAULT_MOBILE_SECRET valueFrom: secretKeyRef: key: mpartner_default_mobile_secret name: keycloak-client-secrets enabled: false - name: SPRING_CLOUD_CONFIG_SERVER_OVERRIDES_KEYCLOAK_INTERNAL_URL valueFrom: configMapKeyRef: name: keycloak-host key: keycloak-internal-url enabled: false - name: SPRING_CLOUD_CONFIG_SERVER_OVERRIDES_KEYCLOAK_EXTERNAL_URL valueFrom: configMapKeyRef: name: keycloak-host key: keycloak-external-url enabled: false - name: SPRING_CLOUD_CONFIG_SERVER_OVERRIDES_KEYCLOAK_INTERNAL_HOST valueFrom: configMapKeyRef: name: keycloak-host key: keycloak-internal-host enabled: false - name: SPRING_CLOUD_CONFIG_SERVER_OVERRIDES_KEYCLOAK_EXTERNAL_HOST valueFrom: configMapKeyRef: name: keycloak-host key: keycloak-external-host enabled: false - name: SPRING_CLOUD_CONFIG_SERVER_OVERRIDES_DB_DBUSER_PASSWORD valueFrom: secretKeyRef: name: db-common-secrets key: db-dbuser-password enabled: false - name: SPRING_CLOUD_CONFIG_SERVER_OVERRIDES_S3_ACCESSKEY valueFrom: configMapKeyRef: name: s3 key: s3-user-key enabled: false - name: SPRING_CLOUD_CONFIG_SERVER_OVERRIDES_S3_REGION valueFrom: configMapKeyRef: name: s3 key: s3-region enabled: false - name: SPRING_CLOUD_CONFIG_SERVER_OVERRIDES_S3_SECRETKEY valueFrom: secretKeyRef: name: s3 key: s3-user-secret enabled: false - name: SPRING_CLOUD_CONFIG_SERVER_OVERRIDES_MOSIP_ESIGNET_HOST valueFrom: configMapKeyRef: key: esignet-host name: inji-stack-config enabled: false - name: SPRING_CLOUD_CONFIG_SERVER_OVERRIDES_MOSIP_ESIGNET_MOCK_HOST valueFrom: configMapKeyRef: key: esignet-mock-host name: inji-stack-config enabled: true - name: SPRING_CLOUD_CONFIG_SERVER_OVERRIDES_MOSIPID_IDENTITY_ESIGNET_HOST valueFrom: configMapKeyRef: key: mosipid-identity-esignet-host name: inji-stack-config enabled: false - name: SPRING_CLOUD_CONFIG_SERVER_OVERRIDES_MOSIP_ESIGNET_INSURANCE_HOST valueFrom: configMapKeyRef: key: esignet-insurance-host name: inji-stack-config enabled: false - name: SPRING_CLOUD_CONFIG_SERVER_OVERRIDES_MOSIP_INJI_DATASHARE_HOST valueFrom: configMapKeyRef: key: inji-datashare-host name: inji-stack-config enabled: false - name: SPRING_CLOUD_CONFIG_SERVER_OVERRIDES_MOSIP_INJIWEB_HOST valueFrom: configMapKeyRef: key: injiweb-host name: inji-stack-config enabled: true - name: SPRING_CLOUD_CONFIG_SERVER_OVERRIDES_MOSIP_INJIVERIFY_HOST valueFrom: configMapKeyRef: key: injiverify-host name: inji-stack-config enabled: true - name: SPRING_CLOUD_CONFIG_SERVER_OVERRIDES_MOSIP_INJICERTIFY_HOST valueFrom: configMapKeyRef: key: injicertify-host name: inji-stack-config enabled: true ``` * Create a file named `configserver.sh`: ```sh touch configserver.sh

#!/bin/bash # Installs config-server ## Usage: ./install.sh [kubeconfig] if [ $# -ge 1 ] ; then export KUBECONFIG=$1 fi NS=config-server CHART_VERSION=12.0.1 read -p "Is conf-secrets module installed?(Y/n) " yn if [ $yn = "Y" ]; then read -p "Is values.yaml for config-server chart set correctly as part of Pre-requisites?(Y/n) " yn; fi if [ $yn = "Y" ] then echo Create $NS namespace kubectl create ns $NS # set commands for error handling. set -e set -o errexit ## set -e : exit the script if any statement returns a non-true return value set -o nounset ## set -u : exit the script if you try to use an uninitialised variable set -o errtrace # trace ERR through 'time command' and other functions set -o pipefail # trace ERR through pipes echo Istio label kubectl label ns $NS istio-injection=enabled --overwrite helm repo update UTIL_URL=https://raw.githubusercontent.com/mosip/mosip-infra/master/deployment/v3/utils/copy_cm_func.sh COPY_UTIL=./copy_cm_func.sh DST_NS=config-server # DST_NS: Destination namespace wget -q $UTIL_URL -O copy_cm_func.sh && chmod +x copy_cm_func.sh echo Copy configmaps and secrets $COPY_UTIL configmap inji-stack-config default $NS if kubectl -n conf-secrets get secret conf-secrets-various >/dev/null 2>&1; then $COPY_UTIL secret conf-secrets-various conf-secrets $NS else echo "Skipping copy, conf-secrets-various secret not found" fi if kubectl -n s3 get configmap s3 >/dev/null 2>&1 && kubectl -n s3 get secret s3 >/dev/null 2>&1; then $COPY_UTIL configmap s3 s3 $NS $COPY_UTIL secret s3 s3 $NS else echo "Skipping copy, s3 config or secret not found" fi echo Installing config-server helm -n $NS install config-server mosip/config-server -f values.yaml --wait --version $CHART_VERSION echo Installed Config-server. else echo Exiting the MOSIP installation. Please meet the pre-requisites and than start again. kill -9 `ps --pid $$ -oppid=`; exit fi

Inji

Try It Out

Using Mock Data

Introduction

Use case

Resources

Overview

Video Playlist

Inji Stack: Overview

Roadmap

Supported Integrations

Project Governance

Open Source Governance Process at MOSIP

1. Overview

2. Governance Structure

Contribution

How do I contribute?

Code Contribution

Code of Conduct

Preamble

Our Pledge

Our Standards

GenderMag

What is GenderMag?

License

Setup

Contact Us

Roadmap

Supported Integrations

Contribution

How do I contribute?

Setup

Contact Us

Try It Out

License

Overview

Collab: Development Integration Environment

How to use:

Collab Guides

Synergy: Stable Integration Environment

Feedback and Support

Project Governance

Open Source Governance Process at MOSIP

1. Overview

2. Governance Structure

Inji

Use case

Code Contribution

Roles and Responsibilities

3. Contributions

Process to Contribute

Pull Request Review Process

Release process

Attribution

4. Decision-Making

Use Cases of Verifiable Credentials and Their Impact

Use Case 1: Healthcare Industry

Use Case 2: Education Sector

Use Case 3: Financial Services

Use Case 4: Travel and Immigration

Use Case 5: Employment

Use Case 6: Government Services

Benefits of Verifiable Credentials in all above mentioned scenarios:

Conclusion

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

Overview

Repositories

Setup your development machine

Code changes

Code of Conduct