In today's fast-paced, interconnected world, ensuring seamless access to essential services—such as healthcare, financial inclusion, global mobility, and social support—has never been more critical. The need for trusted identity authentication and secure data exchange is at the heart of accessing these services. Traditionally, individuals have relied on multiple physical identification documents and certificates to prove their eligibility for various rights and services. However, managing physical documents is cumbersome and exposes individuals to risks of loss, fraud, and inefficiencies. Additionally, millions of people remain excluded from the formal economy due to an outdated reliance on paper-based credentials that cannot be verified digitally.

To address this, Inji offers a transformative solution – enabling the secure issuance, digitalization, storage, exchange and seamless verification of trusted data as verifiable credentials, through a comprehensive set of tools. By shifting away from physical documents to a digital-first approach, Inji simplifies the process, enhances security, and empowers a digital economy. With Inji, individuals can experience a future where accessing essential services is as simple as a few clicks, reducing the complexity of juggling numerous physical documents while maintaining the highest level of trust and security.

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.

Introducing Inji: Enabling User-Centric Digital Credentialing

Inji, meaning "knowing" or "recognizance" in Korean, is evolving into a comprehensive digital credential stack with a strong focus on user empowerment. Inji simplifies the management and verification of credentials by providing secure solutions that work across multiple interfaces. It aims to streamline the process of creating, sharing, and verifying all types of digital and physical credentials by offering:

• Secure Issuance of Verifiable Credentials: Credentials are issued in both digital and physical formats, ensuring they are cryptographically secure and easy to share.

• User-Centric Credential Management: Inji empowers individuals by providing them with tools to securely manage and share their credentials.

• Simplified Instant Verification: It offers utilities that verify the authenticity of credentials, making the process efficient and user-friendly.

• Interoperability: By adhering to global standards like the Verifiable Credentials Data Model (W3C VC) and OpenID for Verifiable Credential Issuance (OI4VCI), Inji facilitates seamless interactions across government, social, and private sectors.

What Does Inji Include?

Inji provides a complete solution for issuing, managing and exchanging trusted data as verifiable credentials across its entire lifecycle. Key components include:

• Inji Certify: Converting data to trustworthy credentials, it enables trusted issuers to create, sign, issue, and bind credentials, in multiple formats.

• Inji Wallet: Making data trustworthy and portable, it consists of two main interfaces that cater to diverse user needs:

  • Inji Mobile: A secure, decentralized mobile wallet that enables users to download, manage, share, and verify verifiable credentials directly from their smartphones. This mobile-first approach provides a seamless, trustworthy way to handle credentials on the go.

  • Inji Web: A user-friendly web interface that complements the mobile application, allowing individuals without access to smartphones, to manage their credentials through a browser. It provides features to download, print, store, and share credentials physically, ensuring broad accessibility across different platforms.

• Inji Verify: Enabling exchange of trusted data with service providers, it is an essential tool to verify the authenticity of shared credentials.

• Inji Infra: Supports functionalities like revocation, ledger management, status checks, and federation for verifiable credentials.

• Inji Govern: Offers a governance framework to define policies, schemas, and assurance mechanisms, ensuring the security and trustworthiness of the ecosystem.

In summary, Inji provides a comprehensive solution that ensures all credential interactions - from issuance to verification - are secure, efficient, and aligned with global standards. This fosters high levels of trust at a low cost, supporting the development of a trusted digital economy. By bridging the gap between traditional and digital systems, Inji establishes a foundation for inclusive, secure, and transparent frameworks, paving the way for a more accessible and digital future for all, thereby ensuring widespread access to essential services.

Use Cases of Verifiable Credentials and Their Impact

Use Case 1: Healthcare Industry

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

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

Benefits:

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

• Enhanced Privacy and Security: Verifiable credentials use cryptography to ensure data integrity and protect sensitive medical information

Use Case 2: Education Sector

Current Challenge: Students often require verified academic transcripts and certificates when applying for further education or job opportunities, which they often carry physical transcripts or certifications. Requesting and verifying these documents can be time-consuming and prone to fraud.

Solution with Verifiable Credentials: Educational institutions can issue VCs such as digital diplomas, certificates, and transcripts. Students can share these credentials with potential employers or other educational institutions quickly and securely, streamlining verification and reducing wait times.

Benefits:

• Efficient Verification: Employers and educational institutions can instantly verify the authenticity of academic credentials without relying on manual checks or third-party verification services

• Prevention of Fraud: Verifiable credentials use cryptographic signatures to ensure the integrity and authenticity of educational documents, reducing the risk of forgery

Use Case 3: Financial Services

Current Challenge: Customers often need to prove their identity and financial history when applying for loans, opening bank accounts, or accessing other financial services. This process typically involves submitting multiple paper documents and undergoing lengthy identity verification procedures.

Solution with Verifiable Credentials: Financial institutions can issue VCs that include identity information, credit scores, and financial history. Customers can use these credentials to securely and selectively share their information with authorized institutions.

Benefits:

• Streamlined Onboarding Process: VCs enable faster and more efficient customer onboarding, reducing paperwork and administrative overhead for financial institutions

• Enhanced Data Privacy: Customers have greater control over their personal and financial data, minimizing the risk of identity theft and unauthorized access

Use Case 4: Travel and Immigration

Current Challenge: Travelers often face challenges proving their identity and vaccination status when crossing borders. Paper-based documents are prone to loss or damage, leading to delays and disruptions during travel. Travelers juggle multiple documents for border crossings (passports, visas, health certificates) leading to delays and frustration.

Solution with Verifiable Credentials: Governments and health authorities can issue verifiable credentials for vaccination records, identity verification, and travel permissions. Travelers can present these digital credentials at checkpoints or border crossings securely and efficiently. These credentials can be easily accessed via mobile wallets and verified electronically, speeding up border processing and reducing queues.

Benefits:

• Facilitated Cross-Border Travel: Verifiable credentials enable seamless verification of identity and vaccination status, reducing wait times and administrative hurdles at immigration checkpoints

• Improved Public Health Measures: Authorities can track and verify vaccination records more effectively using digital credentials, supporting efforts to manage public health crises such as pandemics

Use Case 5: Employment

• Challenge: Job seekers often face delays due to lengthy background checks and verification of employment history and skills

• Solution: Employers can issue verifiable credentials for past employment and skills acquired. Job seekers can then share these credentials with potential employers, allowing for faster verification and a smoother hiring process

Use Case 6: Government Services

• Challenge: Citizens often need to present physical documents (birth certificates, proof of residence) to access government services, leading to inefficiency and potential loss of documents

• Solution: Government agencies can issue verifiable credentials for citizen information. These credentials can be securely accessed and shared for various services, reducing administrative burdens and streamlining access

Benefits of Verifiable Credentials in all above mentioned scenarios:

• Reduced Friction: Verifiable credentials eliminate the need for physical documents, simplifying processes and speeding up transactions

• Enhanced Security: Cryptographic verification ensures the authenticity and integrity of credentials, reducing the risk of fraud

• User Control: Individuals control their data, choosing what information to share and with whom

• Improved Efficiency: Streamlined workflows and faster access to services for both users and institutions

Conclusion

Verifiable credentials offer versatile solutions across various domains by leveraging digital technologies to enhance data security, privacy, and efficiency. By addressing common challenges associated with identity verification and data sharing, verifiable credentials empower individuals and organizations to streamline processes and improve trust in digital interactions.

Inji Ecosystem Workshop

Comprehensive demonstration on Digital Identity Management and Credential Integration

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.

• Credential Management: The workshop covers how credentials are stored, secured, and validated in both Web and Wallets, emphasizing security and compliance with standards.

• Real-World Deployment and Integration: It discusses the roles of issuers and service providers in real-world deployments, the use of blockchain for security, and the potential for running AI agents for selective disclosure.

Inji Certify Credential Issuance Workshop

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.

• Docker Compose Setup: A Docker environment is set up to run the database, Inji Certify, Nginx, and Inji Web.

• Demonstration: A farmer ID is entered, authenticated, and a verifiable credential is issued based on the retrieved data.

Inji A Technical Deep Dive

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.

• API Interactions: The session explains how Inji Wallet interacts with various APIs, including those for fetching issuer lists, obtaining access tokens, and binding wallets to relying parties.

• Configuration: The webinar discusses the configuration aspects, such as setting up issuer information, defining VC templates, and configuring the connection to eSignet.

• Development and Integration: The presentation provides insights into the development process, including the use of React Native for the mobile app, the integration of native modules, and the management of data storage.

Unlocking the Value of Integrations with Inji and eSignet

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.

• Inji: A platform for managing the lifecycle of verifiable credentials.

• Real-World Impact: Understand how eSignet and Inji provide secure and efficient digital experiences.

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!

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:

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.

Feedback and Support

If you require any assistance or encounter any issues during the testing and integration process, kindly reach out to us through the support mechanism provided below.

• Provide a detailed description about the support you require or provide detailed information about the issue you have encountered, including steps to reproduce, error messages, logs and any other relevant details.

\

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.

Roles and Responsibilities

• Maintainers are individuals who have “Commit” rights; And are the primary caretakers of the code and the strategic vision of the project. They are empowered to make decisions and resolve disputes for all contributions. They are appointed by MOSIP.

• Project Lead is the chair of the committee of maintainers. They are appointed by MOSIP.

• Contributors are the people or organisations who take part actively in the project and its meetings, code, design, and test and are recognized for their contributions. The contributors are part of the GitHub Members and would be actively involved in the discussion of a PR and review. Members strongly influence the Maintainer's decision.

• Members are either individuals or persons affiliated with contributing organisations. All contributions are bound by the licensing of the project.

• Product Owner is responsible for the analysis, design, development, and implementation of business solutions to meet the needs of the organisation. He/She must have a strong understanding of the business domain, processes, and software development lifecycle Agile development methodologies).

3. Contributions

Scope of Contributions

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

• Code

• Documentation

• Design

• Raising Bugs

• Feature Request

Process to Contribute

• Code, Documentation & Design

  • All artefacts including the code are maintained in the github repository.Contributions can be made by raising a Pull Request.

• Reporting Issues & Feature Request

  • Issues and backlog are maintained in Jira and members of the project team will have access to Jira to add feature requests and report bugs

  • One off users will not have access for bug reports and feature requests. They can report the same in the community pages

  • Regular users who do not have access, can request the same and the maintainers can provide access after considerationWe use Jira to track the work associated with the project (account required). That is where issues open for community contribution can be found.Pull Request Review ProcessThe process to contribute the code is present here. Once code is submitted, it is reviewed through the following process:

Pull Request Review Process

• At least two members should have reviewed the submitted contribution for the pull request to be accepted. The maintainers may request for more reviews of the code from other relevant members.

• If the members deem the submitted code to be critical to overall product development, they can seek the inputs of the relevant product owners for the review process.

• The maintainers review the two (or more) sets of comments received from the tech leads and the submitted code before taking a decision regarding committing the code to the appropriate branch.

• The decision by the maintainer is communicated to the contributor via Jira as well as Pull Request.

• In exceptional cases such as an emergency or an urgent requirement or a very trivial but time-sensitive correction, a maintainer may - at their discretion - choose to directly review the submitted pull request and take a decision on the commit.

Release process

Attribution

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

4. Decision-Making

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.

Overview

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

Repositories

Setup your development machine

1. Fork the repository.

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

   Copy

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

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

   Copy

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

4. Make sure you never directly push upstream.

   Copy

   $ git remote set-url --push upstream no_push

5. Confirm the origin and upstream.

   Copy

   $ git remote -v

   This should display origin and upstream as below:

   Copy

   origin	https://github.com/<your_github_id>/inji.git (fetch)
   origin	https://github.com/<your_github_id>/inji.git (push)
   upstream	https://github.com/mosip/inji.git (fetch)
   upstream	https://github.com/mosip/inji.git (push)

Code changes

1. Create a new issue in GitHub.

1. Follow the issue template provided.

2. Please provide as much information as possible.

3. If you want to develop a new feature, please elaborate on the idea and discuss the design before starting development. 2. In your local repository, fetch the upstream.

$ git fetch upstream

3. On your local repo, switch to a branch if you are working on an older release or stay in main/develop branch.

$ git checkout upstream/<branch> 

4. Create a new issue branch with the name of the issue.

$ git switch -c issue-<issue number>

5. Make sure you are up-to-date with the upstream repo.

$ git pull upstream <branch> 

$ git commit -m "[#1234] Adding new feature in inji module"

7. Once again ensure that you are up-to-date with the upstream repo as it may have moved forward.

$ git pull upstream <branch> 

8. Build and test your code. Make sure to follow the coding guidelines. Provide unit test cases for the changes you have built.

9. Push to your forked repo (origin).

$ git push --set-upstream origin issue-<issue number>

10. On your forked remote repository from GitHub, create a pull request using the Contribute button. Direct the pull-request to main or any specific branch upstream.

11. Make sure the automatic tests/checks on GitHub for your pull request pass.

Inji Wallet

Inji Mobile

Q1: Jan24 - Mar24

Q2: Apr24 - Jun24

Q3: Jul24 - Sep24

Q4: Oct24 - Dec24

Inji Web

Q1: Jan24 - Mar24

Q2: Apr24 - Jun24

Q3: Jul24 - Sep24

Q4: Oct24 - Dec24

Inji-Certify

Q1: Jan24 - Mar24

Q2: Apr24 - Jun24

Q3: Jul24 - Sep24

Q4: Oct24 - Dec24

Inji -Verify

Q1: Jan24 - Mar24

Q2: Apr24 - Jun24

Q3: Jul24 - Sep24

Q4: Oct24 - Dec24

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.

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

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

Preamble

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

Our Pledge

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

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

Our Standards

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

• Demonstrating empathy and kindness toward other people

• Being respectful of differing opinions, viewpoints, and experiences

• Giving and gracefully accepting constructive feedback

• Accepting responsibility and apologizing to those affected by our mistakes, and learning from the experience

• Focusing on what is best not just for us as individuals, but for the overall community

Examples of unacceptable behaviour include:

• The use of sexualized language or imagery, and sexual attention or advances of any kind

• Trolling, insulting or derogatory comments, and personal or political attacks

• Public or private harassment

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

• Other conduct which could reasonably be considered inappropriate in a professional setting

Enforcement Responsibilities

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.

Scope

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.

Enforcement

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

Enforcement Guidelines

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

1. Correction

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.

2. Warning

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.

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

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

Attribution

The Inji Mobile application is designed to securely store all types of digital credentials, from national IDs to certificates, in one easy-to-use mobile wallet. It offers a simple way to manage and share trusted data through Verifiable Credentials (VCs), making it portable, convenient, secure, and private for users.

Key features of Inji Mobile include secure storage, seamless sharing, and offline verification capabilities including face authentication, making it an essential tool for users managing digital credentials.

Key Features and Capabilities:

• Secure Download and Storage of Verifiable Credentials (VCs): The Inji Mobile allows users to download, store, and manage their Verifiable Credentials securely. This makes it a dependable mobile solution for keeping identity credentials, ensuring users have access to their digital IDs anytime, anywhere.

• Seamless Offline Credential Sharing: Users can share their credentials with service providers without requiring internet connectivity by utilizing Bluetooth Low Energy (BLE) technology. This offline sharing supports decentralized ID verification, making it possible to share VCs even in areas with limited to no internet connectivity, ensuring the user’s credentials are always accessible. This offline capability makes it ideal for users in rural or low-connectivity areas.

• Offline Face Authentication for Secure Transactions: The app offers offline face authentication, verifying the user’s presence during credential sharing with service providers. This feature adds an additional layer of security when sharing credentials, ensuring the identity of the user is authenticated in real-time.

• QR Code-Based Access to Online Services: The wallet enables users to log in to service provider portals by scanning QR codes, simplifying access to various services. It also supports single sign-on (SSO) capabilities, allowing users to access multiple services with the same credentials securely.

• Privacy and Control Over Data Shared: Inji Mobile puts users in control of their data, allowing them to decide what information is shared with service providers. This consent-driven approach ensures that users' privacy is protected throughout all interactions.

• Enhanced Efficiency for Government Services: Inji Mobile streamlines the registration process for government benefits, such as pensions and healthcare services. It also facilitates the use of VCs during travel and at security checkpoints, such as airports, ensuring that digital IDs are always readily accessible.

• Robust Security with Verifiable Credentials: The digital credentials managed within Inji Mobile adhere to the Verifiable Credentials (VC) Data Model, ensuring the adherence to global standards for security and authenticity. Before downloading to the device, each credential is authenticated by the issuer's digital signature, and a unique HASH is generated to verify the integrity of the credential at any time.

How Inji Mobile Works:

• Inji Mobile allows users to securely obtain and manage their verifiable credentials through a simple process. Users can download their credentials by using their unique ID (such as UIN or VID for a government-issued National ID) or the card details they already have (via the KBI method).

• To validate their identity, users authenticate their request with a one-time password (OTP) sent to their registered mobile number or email.

• Once validated, the verifiable credential is securely downloaded and stored in the app.

• For added security, users have the option to authenticate their credentials through offline face verification during transactions.

• Users maintain full control over what information is shared, through the consent mechanism that comes along.

• Inji Mobile ensures that the digital signatures of the issuer are verified before the credential is stored, and it generates a unique HASH for each ID to confirm its integrity before displaying it in the app.

Technology and Integration:

To summarize, Inji Mobile is an all-in-one mobile solution for securely managing and sharing Verifiable Credentials. By offering both online and offline features, privacy protection, and seamless integration with service providers, it empowers individuals to have complete control over their digital credentials, wherever they are.

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

1. We identified two personas based on their familiarity with technology and their ability to embrace technological progress. The personas are:

   • Abi, who is either Abigail or Abishek, is 45 years old. She works as a homemaker, is literate, but not very tech- savvy. Her internet connectivity is moderate, and she does not have a personal phone.

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

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

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

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

.

Let’s go through a brief overview these components.

• eSignet: Server enables user authorization and generates Verifiable Credentials (VCs) securely from user data.

• Mimoto: This is a BFF(Backend for Frontend) for routing API calls to services.

• Tuvali: This is an SDK that transfers data securely over BLE following OpenID4VPBLE specification.

• Biometric SDK / Face Match SDK: This is an SDK used for face verification.

• Secure Key Store: This is an SDK used for key-pair generation, signing and encryption/ decryption for Android.

Wallet Application

This section intends to provide an overview of the technologies, tools and frameworks utilized to build Inji Wallet:

Native Libraries

This section intends to provide an overview of the technologies, tools and frameworks utilized to build native libraries:

Below is a comprehensive overview of the features provided by Inji Wallet.

Download, Verify and Store Verifiable Credentials

Downloading your digital credentials (IDs) with you at all times just got easier. This can be done as below:

Downloading VC using the OpenID for VC Issuance flow:

Residents can download a VC using a configured third-party issuer which complies with OpenID for VCI standard. For Inji Wallet, MOSIP IDA (National ID) and Veridonia Insurance (Insurance credentials) are example integrations.

Credential Type Selection:

Inji Wallet introduces a new feature that empowers users to select the specific type of credential they require. Upon choosing an issuer, users are presented with a list of Credential Types issued by the ID provider. This functionality provides users with flexibility and control, allowing them to download their Verifiable Credentials to their precise needs.

VC Verification:

Inji Wallet offers a robust feature for verifying Verifiable Credentials using the Digital Bazaar library. This advanced functionality ensures that the issuer's signature is validated and verified based on the proof type provided by the issuer. This step is ingrained as part of the VC download flow. Currently, the support is for the RSA signature type, providing users with reliable verification capabilities. Additionally, we are actively working to expand our support to include the Ed25519 proof type, further enhancing the security and versatility of our verification process. With these advancements, users can trust that their Verifiable Credentials are verified with precision and integrity, regardless of the proof type utilized by the issuer.

QR Code Generation:

PixelPass library is capable of generating QR codes for Verifiable Credentials with smaller size data. The library is integrated with Inji Wallet and users can now see a QR code which has Verifiable Credentials embedded in it. These QR codes, visible in the detailed view of the card, offer a convenient way for users to share their credentials with relying parties or service providers. Users can display the QR code so that the relying party / service provider can either:

• Scan the QR code displayed in the wallet app showcased by the resident.

• Upload the QR code as an image to the service provider verification website.

Reference Implementation: QR Code generation for Veridonia Insurance VC.

Sharing Verifiable Credentials without the Internet

• Inji Wallet allows users to securely share their downloaded VCs with other Inji users using Bluetooth Low Energy (BLE) technology, removing the necessity for an internet connection.

Offline authentication of shared Verifiable Credentials

• Users can verify the authenticity of their shared VCs by taking a self-portrait photograph on their mobile device. Inji Wallet compares this photograph with the image on the VCs, confirming the correct source and owner.

Streamlined SSO and User-Controlled Authentication

• Inji Wallet users have the ability to choose which downloaded VC should be enabled for online authentication and selectively share the credentials on their ID. This capability provides users with an additional layer of security and control over the utilization of their stored information.

Data backup and restore

In order to safeguard against potential data loss in case of any unprecedented circumstances such as phone / app crashes, device change etc, and to improve user experience in the Inji app, users can now utilize the Backup and Restore feature for their Verifiable Credentials (VCs).

Depending on their device platform, users can choose to store and retrieve VCs securely using either Google Drive (for Android users) or iCloud (for iOS users). This is a one-time setup process, where Android users can select their respective Google email account, while iOS users can back-up data using their default logged-in Apple account.

Security Features

Inji Wallet, as a digital Verifiable Credential wallet, implements robust measures to safeguard PII data and protect against cyber-attacks. Inji Wallet undergoes rigorous Penetration Testing and Threat Modelling by certified experts, further enhancing its resilience against cyber threats.

1. Utilization of Hardware Keystore:

   • Inji Wallet securely stores private encryption keys by utilizing the Android hardware keystore.

2. Cryptographic Protection for PII Data:

   • Inji Wallet employs industry-standard SHA-256 and Argon2 cryptographic libraries to hash and strengthen Personally Identifiable Information (PII) data. The app actively detects and responds to any suspicious activities, ensuring enhanced security of user data.

3. Automatic biometric change detection:

   • Inji Wallet automatically resets itself in case of biometric change, thereby ensuring the security of information.

Ingenious Design

Inji Wallet functions as a comprehensive repository for a diverse array of VCs, leveraging its interface design to benefit users.

• Multiple views of VCs: Users can access multiple views of VCs, ranging from a mini view to detailed insights.

• Organized UI: Inji Wallet provides a clear demarcation between downloaded and received VCs enhancing user clarity.

• Quick Access menu: Users can now directly Share, Share with Selfie directly by accessing the kebab menu from the mini view in the Home Page and the detailed view of the VC.

Also, watch the video below for a quick glimpse of the features available.

Inji Wallet utilizes multiple libraries to provide a seamless experience.

These libraries are accessible as NPM modules, allowing seamless integration with other mobile wallets.

The libraries are as follows:

1. Tuvali - Sharing via BLE SDK

2. Face Match SDK

3. Secure Keystore SDK

4. PixelPass SDK

5. VCI-client SDK

6. OpenID4VP - Online Sharing SDK

7. Telemetry SDK(coming soon)

1. Tuvali - Sharing via BLE SDK

• The transfer of downloaded Verifiable Credential from the Wallet to Verifier is facilitated by a React Native library named Tuvali.

• Tuvali enables offline VC transfer between mobile devices via Bluetooth Low Energy (BLE). The below table represents the supported roles for Android and iOS devices.

• Tuvali is actively developed and maintained by MOSIP.
• It does not support iOS for initiating the BLE exchanges, hence preventing two iOS devices from transferring VC.

2. Face Match SDK

This SDK internally employs a tflite model, which must be created by the integrating party. The model, trained using resident faces, is stored on the MOSIP file server. Inji Wallet currently utilizes the face matcher SDK (soon to be replaced by the NPM module) for offline face authentication.

The SDK is employed in two scenarios:

During Offline VC Sharing: Residents can perform selfie authentication before sharing the VC with the relying party. The app opens the camera, allowing residents to take a selfie, which is then validated against the VC image to verify the resident's presence. During Online Login: Residents can scan the QR code from the relying party portal and opt to log in using Inji Wallet for services. In this process, residents undergo selfie authentication against the VC to confirm their presence.

3. Secure Keystore SDK

The secure-keystore library is designed for creating and storing key pairs in the hardware keystore of devices. The library supports encryption, decryption, HMAC calculation, and signing with aliases created during key pair generation.

This library is available for both Android and iOS platforms:

Inji Wallet integrates with the secure-keystore library to ensure secure key management. To optimize the key size during credential download requests, Inji Wallet uses RSA-2048, ECR1, ECK1, ED25519 keys.

4. PixelPass SDK

The PixelPass library offers a powerful solution for creating and decoding QR codes for Verifiable Credentials (VCs). It is designed to optimize the size of the data encoded within a QR code, making it easier to store and share credential information. The library achieves this by utilizing advanced compression and encoding techniques, ensuring smaller QR codes that maintain the integrity and security of the data.

PixelPass uses zlib compression with a level 9 setting, which significantly reduces the data size before encoding. It then applies base45 encoding to further compress the data into a QR code-friendly format. Additionally, the library can decode any QR code data previously encoded using its own compression and encoding algorithms, ensuring seamless interoperability.

5. VCI-client SDK

VCI-Client library carries out the credential request from the consumer application (mobile wallet or web) and redirects the issuance/issuer. The library creates a request with the credential format, jwtproof of the wallet, issuer metadata and the access token received for authorization and provides VC as the response back to the consumer application for storage.

6. OpenID4VP - Online Sharing SDK

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

This library follows the below steps to share the Verifiable Presentation with the Requested Verifier:

1. Receives the Verifier's Authorization Request sent by the consumer application (mobile wallet).

2. Authenticates the Verifier using the received client_id and validates the whole Request to check if the required details are present or not and then returns the Authorization Request to the consumer application if all the validations are successful.

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

4. Constructs the vp_token without proof section and sends it back to the consumer application for generating Json Web Signature (JWS).

5. Receives the generated signature along with the other details and generates vp_token with proof section & presentation_submission.

6. Sends a POST request with generated vp_token and presentation_submission to the received Verifier's response_uri endpoint.

7. Telemetry SDK

Note: The publication of this project is currently a work in progress and has not been released yet. Stay tuned for further announcements!

Below are the guidelines and specifications for integrating any software development kit (SDK) with Inji Wallet:

1. The SDK should be implemented as a npm module that supports the React Native framework.
2. The SDK should provide simple APIs for integration purposes.

   These APIs should include an API for instantiation or initialization, such as the init or constructor API.

3. The SDK should also include additional APIs that perform the necessary actions.

4. There should be an API available to disconnect the SDK, if needed.

   If possible, it would be beneficial for these APIs to be asynchronous. This enables users to continue using the application without experiencing any UI blocking.

5. To enhance logging and traceability, the API may accept an optional parameter known as traceabilityId.

By adhering to these specifications, the integrated SDK will enhance the functionality and usability of the application.

This section contains various guides and information that could benefit the developers, system integrators, relying parties and end users.

For more information on how to get started with integrations, read through:

1. Tuvali - Sharing via BLE

2. Face Match

3. Secure Keystore

4. BLE Verifier

5. PixelPass

6. Telemetry (details coming up soon)

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

📦 Installation

iOS (Swift)

Using Swift Package Manager:

1. Open Xcode

2. Go to File > Swift Packages > Add Package Dependency

3. Use the URL: https://github.com/mosip/secure-keystore-ios-swift.git

Android (Kotlin)

Add the following in your settings.gradle.kts:

dependencyResolutionManagement {
  repositories {
    google()
    mavenCentral()
    maven("https://oss.sonatype.org/content/repositories/snapshots/")
  }
}

In build.gradle.kts:

dependencies {
  implementation("io.mosip:secure-keystore:0.3.0")
}

📘 API Documentation

• deviceSupportsHardware() => boolean Checks if the device supports secure hardware-backed keystore.

• generateKey(alias, isAuthRequired, authTimeout?) Generates a symmetric key for encryption/decryption with optional biometric auth.

• generateKeyPair(type, alias, isAuthRequired, authTimeout?) Creates a public-private key pair (RSA or EC) with optional authentication.

• encryptData(alias, data, onSuccess, onFailure) Encrypts data using a symmetric key associated with the given alias.

• decryptData(alias, encryptedText, onSuccess, onFailure) Decrypts previously encrypted data using the associated key alias.

• sign(signAlgorithm, alias, data, onSuccess, onFailure) Signs data using the specified key and signature algorithm (RSA, ECDSA are supported).

• generateHmacSha(alias, data, onSuccess, onFailure) Generates an HMAC signature using the specified alias and data.

• generateHmacSha256Key(alias) Creates a symmetric key suitable for HMAC-SHA256 operations.

• hasAlias(alias) => boolean Checks if a key exists for the specified alias.

• removeKey(alias) Deletes the key associated with the given alias from the keystore.

• removeAllKeys() Clears all keys stored in the keystore.

• retrieveKey(alias) Retrieves the public key for the specified alias.

• storeGenericKey(publicKey, privateKey, account) Stores a custom key pair in the keychain/keystore linked to an account.

• retrieveGenericKey(account) Retrieves the stored key pair associated with the specified account.

Tuvali module is based on the OpenID for Verifiable Presentations over BLE implementation to support sending vc/vp using Bluetooth Low Energy local channel. The below sections explains the APIs of the library in detail.

Firstly, for establishing the secured connection over BLE the connection params which include name and key needs to be exchanged between the two devices. This exchange of parameters can be accomplished but is not limited to by using a QR code.

For example, use a QR code generator to visually display params and a QR code scanner to get params. A mobile app that displays a QR code can act as an Verifier by including its connection params as data in the QR code and another device can act as Wallet which scans the QR code, it can extract the connection parameters and initiate a BLE connection with the advertising device.

URI Exchange and Establishing Connection

Verifier

The Verifier device generates a URI using the startAdvertisement() method and displays it as a QR code. Once the advertisement starts, the Verifier continuously advertises with a payload derived from the URI.

URI contains:

OPENID4VP://connect?name=STADONENTRY&key=8520f0098930a754748b7ddcb43ef75a0dbf3a0d26381af4eba4a98eaa9b4e6a

var verifier = Verifier()
var uri = verifier.startAdvertisement()
println(uri)

Wallet

Start Connection

The device that scans the QR code will extract the connection parameters from the QR code and set its connection parameters using the startConnection() method :

var wallet = Wallet()
wallet.startConnection(uri)

The connection param is a URI with a name & a key. The name is the client's name & the key is the verfier's public key.

OPENID4VP://connect:?name=OVPMOSIP&key=69dc92a2cc91f02258aa8094d6e2b62877f5b6498924fbaedaaa46af30abb364

• The key part of the data is the same data that will be advertised by the verifier device but in hex-encoded form.

E.g: OVPMOSIP://connect:?name=<>&key=<verifier public key>

Share data

Once the connection is established, wallet app can send the data in a secured way to the Verifier. Note: At this moment, we currently support data transfer from Wallet to Verifier only.

wallet.sendData(payload);

and verifier app can acknowledge it.

verifier.sendVerificationStatus(status);

The following sequence of actions should be performed to transfer data over BLE:

1. Verifier must start advertising by calling verifier.startAdvertisement(name) method

2. Subscribe to events using wallet.handleDataEvents

3. Initiate the secure connection using wallet.startConnection(uri). The Wallet public keys are exchanged with verifier on successful connection.

4. Wallet calls wallet.sendData(payload) to transfer requisite data over BLE.

5. Send VC response - Verifier can exchange "Accept/Reject" status to Wallet with the following message type for verifier.sendVerificationStatus method

Subscribe to events

Data received from other apps via BLE can be subscribed to using: Tuvali sends multiple events to propagate connection status, received data etc. These events can be subscribed to by calling:

on Wallet:

wallet.subscribe {
  event  ->
  // Add the code that needs to run once event is received
}

on Verifier:

verifier.subscribe {
  event  ->
  // Add the code that needs to run once data is received
}

Here are the different types of events that can be received

Common Events

Events which are emitted by both Wallet and Verifier

1. ConnectedEvent

   • on BLE connection getting established between Wallet and Verifier

2. SecureChannelEstablishedEvent

   • on completion of key exchange between Wallet and Verifier

3. ErrorEvent

   • on any error in Wallet or Verifier

4. DisconnectedEvent

   • on BLE disconnection between Wallet and Verifier

Wallet Specific Events

1. DataSentEvent

   • on completion of Data transfer from the Wallet Side

2. VerificationStatusReceivedEvent

   • on received verification status from Verifier

Verifier Specific Events

1. DataReceivedEvent

• on receiving data from the Wallet Side

Connection closure

The device on which app is running can destroy the connection by calling disconnect() method:

wallet.disconnect();
verifier.disconnect();

Tuvali & Inji Integration

The below diagram explains the series of handshakes between the Verifier and the Wallet device.

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?

PixelPass

PixelPass is a versatile and easy-to-use library designed to simplify working with QR codes and data compression. It allows you to generate QR codes from any given data with just a single function. If you’re working with JSON, PixelPass can take that data, compress it, and convert it into a compact format using CBOR encoding, making it smaller and more efficient for QR code generation. The library can also decode this compressed data, turning CBOR back into the original JSON format. Additionally, for more complex use cases, PixelPass offers the ability to map your JSON data to a specific structure, compress it, and encode it into CBOR. Later, you can also reverse this process, decoding the CBOR back into its mapped JSON structure. With these capabilities, PixelPass makes managing, compressing, and encoding data for QR codes easy and efficient.

PixelPass has NPM, Kotlin, Swift and Java artifacts available.

Features

• Compresses data using zlib with the highest compression level (level 9).

• Encodes and decodes data with the base45 format.

• For JSON data, applies CBOR encoding/decoding to achieve additional size reduction.

• With JSON and a Mapper provided, maps the JSON and then performs CBOR encoding/decoding to further shrink the data size.

Usage

1. As a node project:

npm i @mosip/pixelpass

1. As a Kotlin/Java dependency:

Gradle

implementation("io.mosip:pixelpass:0.5.0")

Maven

1. To include PixelPass in your Swift project, follow the below steps:

   1. Clone the PixelPass library locally.

   2. Create a new Swift project.

   3. Add package dependency: PixelPass

APIs

Below are the APIs provided by the PixelPass library:

generateQRCode( data, ecc , header )

The generateQRCode takes a data, ECC (Error correction level) which when not passed defaults to L and header which defaults to empty string if not passed. Returns a base64 encoded PNG image.

• data - Data needs to be compressed and encoded.

• ecc - Error Correction Level for the QR generated. defaults to "L".

• header - Data header need to be prepend to identify the encoded data. defaults to "".

generateQRData( data, header )

The generateQRData takes a valid JSON string and a header which when not passed defaults to an empty string. This API will return a base45 encoded string which is Compressed > CBOR Encoded > Base45 Encoded.

• data - Data needs to be compressed and encoded.

• header - Data header need to be prepend to identify the encoded data. defaults to "".

decode( data )

The decode will take a string as parameter and gives us decoded JSON string which is Base45 Decoded > CBOR Decoded > Decompressed.

• data - Data needs to be decoded and decompressed without header.

decodeBinary( data )

The decodeBinary will take a UInt8ByteArray as parameter and gives us unzipped string. Currently only zip binary data is only supported.

• data - Data needs to be decoded and decompressed without header.

getMappedData( jsonData, mapper, cborEnable )

The getMappedData takes 3 arguments a JSON and a map with which we will be creating a new map with keys and values mapped based on the mapper. The third parameter is an optional value to enable or disable CBOR encoding on the mapped data.

• jsonData - A JSON data.

• mapper - A Map which is used to map with the JSON.

• cborEnable - A Boolean which is used to enable or disable CBOR encoding on mapped data. Defaults to false if not provided.

The example of a converted map would look like, { "1": "207", "2": "Jhon", "3": "Honay"}

decodeMappedData( data, mapper )

The decodeMappedData takes 2 arguments a string which is CBOR Encoded or a mapped JSON and a map with which we will be creating a JSON by mapping the keys and values. If the data provided is CBOR encoded string the API will do a CBOR decode first ad then proceed with re-mapping the data.

• data - A CBOREncoded string or a mapped JSON.

• mapper - A Map which is used to map with the JSON.

The example of the returned JSON would look like, {"name": "Jhon", "id": "207", "l_name": "Honay"}

Errors / Exceptions

Shall you encounter any errors while using the APIs, please refer to the below:

1. Cannot read properties of null (reading 'length') - This error denotes that the string passed to encode is null.

2. Cannot read properties of undefined (reading 'length') - This error denotes that the string passed to encode is undefined.

3. byteArrayArg is null or undefined. - This error denotes that the string passed to encode is null or undefined.

4. utf8StringArg is null or undefined. - This error denotes that the string passed to decode is null or undefined.

5. utf8StringArg has incorrect length. - This error denotes that the string passed to decode is of invalid length.

6. Invalid character at position X. - This error denotes that the string passed to decode is invalid with an unknown character then base45 character set. Also denotes the invalid character position.

7. incorrect data check - This error denotes that the string passed to decode is invalid.

PixelPass & Inji Wallet Integration:

The below diagram shows how Inji Wallet utilises PixelPass library.

PixelPass & Inji Verify Integration:

The below diagram shows how Inji Verify utilises PixelPass library.

VCI-Client

vci-client library enables to carry out the credential request from the consumer application (mobile wallet or web) and download the VC.

Features:

• Creates a credential request with access token, issuer metadata, holder jwt proof.

• Provide credential response (VC) to the consumer application.

• Kotlin and Swift artefacts are available to integrate with the native mobile applications.

Below sections details on the steps for integrating the Kotlin and Swift packages into the app.

Android: Kotlin package for vci-client:

Repository

Installation

APIs

1. Request Credential

Request for credential from the providers (credential issuer), and receive the credential.

Parameters

Exceptions

• DownloadFailedException is thrown when the credential issuer did not respond with credential response

• NetworkRequestTimeoutException is thrown when the request is timedout

More details

An example app is added under /example folder which can be referenced for more details.

iOS: Swift package for vci-client:

Repository

Installation

1. Clone the repo

2. In your swift application go to file > add package dependency > add thehttps://github.com/mosip/inji-vci-client-ios-swift in git search bar> add package

3. Import the library and use.

APIs

1. Request Credential

Request for credential from the issuer, and receive the credential response back in string.

Parameters

Exceptions

• DownloadFailedError is thrown when the credential issuer did not respond with credential response

• NetworkRequestTimeOutError is thrown when the request is timedout

More details

An example app is added under /SwiftExample folder which can be referenced for more details. Extract the swift example app out of the library and then follow the installation steps.

VCI-Client and Inji Wallet integration:

The below diagram shows how Inji Wallet utilises vci-client library.

Overview

This document outlines the infrastructure requirements for deploying the Inji Stack in a Proof of Concept (POC) or demo sandbox environment or small scale pilot. It serves as a comprehensive reference for system architects, DevOps engineers, and IT administrators who are responsible for provisioning and configuring the virtualized infrastructure required to run Inji modules effectively.

The Inji Stack enables secure issuance, holding, and verification of Verifiable Credentials (VCs) and includes services such as Inji Web Wallet, Inji Mobile Wallet, Inji Verify, and Inji Certify. To demonstrate these capabilities effectively, a stable and scalable Kubernetes-based deployment environment is essential. To showcase these capabilities in a demo, small scale pilot or POC setting, the stack must be deployed on a Kubernetes cluster with properly allocated resources, network settings, and domain configurations.

This document outlines the necessary hardware, VM provisioning details, cluster roles, and optional components to support observability and access control.

Purpose of this Document

• Define the minimum infrastructure required for running all components of Inji Stack.

• Specify node roles, hardware configurations, and networking prerequisites.

• Provide guidelines for optional tools like Rancher and Keycloak, if Role-Based Access Control (RBAC) and observability are desired.

• Highlight key considerations around DNS setup, SSL certificates, and VM provisioning.

Who Should Use This Document?

• DevOps Engineers setting up and maintaining the Inji Stack environments.

• System Integrators or Partner Teams participating in small scale pilots, POCs or sandbox testing.

• IT Teams preparing demo infrastructure for showcasing Inji capabilities.

• Solution Architects planning how to scale from demo to production-ready deployments.

How It Helps

• Reduces ambiguity by clearly stating resource needs and cluster expectations.

• Supports repeatable deployments by defining baseline configurations.

• Acts as a starting point to scale up to a high-availability production architecture.

Cluster Roles

Cluster Composition

• The environment consists of 3 Virtual Machines (VMs) functioning as separate nodes in a Kubernetes cluster.

• Three nodes mentioned above respective two roles discussed below.

Control Plane Node

• Purpose: Acts as both the master node and the etcd plane node.

• Role: Hosts all essential Kubernetes components required to orchestrate and manage the cluster.

Worker Node

• Purpose: Serves as a dedicated worker node for running the complete Inji Stack.

• Role: Hosts all services across all modules of Inji.

Cluster-wide Role Assignment:

• All cluster nodes are assigned to all of the above-mentioned cluster roles.

  • Proper configuration and resource allocation ensure seamless functioning of the cluster.

Hardware Requirements

Production Guidelines (Optional for POC)

Optional Components (Observability and RBAC)

In case Rancher is used for cluster management and Keycloak is integrated for Role-Based Access Control (RBAC), the following infrastructure is additionally required:

Observation Cluster Setup

SSL Certificate Requirements

• Two wildcard SSL certificates are recommended:

  1. One for Inji cluster components (e.g., *.inji.example.org) mapping.

  2. (Optional) One for Observation cluster components if deployed separately.

Network Requirements

• All VMs must be able to communicate with each other over a stable private network.

• Stable internet connectivity is needed on all VMs for:

  • Docker image downloads.

  • External software updates (or access to a local Docker registry for offline setups).

• Networking interfaces must be configured as per the Hardware table requirements given above:

  • Public and private interfaces, where required.

DNS Requirements

• Access to a DNS server to map multiple subdomains under a wildcard domain (e.g., *.inji.example.org).

• Subdomain mapping enables hosting of services and components such as:

  • verify.inji.example.org

  • certify.inji.example.org

  • certify.web.example.org

  • etc.

Conclusion

This infrastructure specification provides the baseline setup needed to deploy the Inji Stack for showcasing its verifiable credentials capabilities as an end-to-end ecosystem. While the current configurations are optimized for Proof of Concept, Small scale pilot and demo scenarios, this document also points to production-ready practices for teams planning to transition to a fully operational environment.

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.

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

• The following guidelines apply to individuals who are developing the face SDK:

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

  2. Inji Wallet includes built-in telemetry, and all telemetry data must be transmitted to the designated system. Telemetry enhances Inji Wallet's observability features by capturing specific events, creating measures, and monitoring various user actions and events.

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

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

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.

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.

This guide explains the use of mock data for following:

• Inji Mobile Wallet

• Inji Web Wallet

• Inji Verify

Inji Mobile Wallet

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

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

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

Insurance Credentials:

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

• Policy id: 7070

• Name: aswin

• DOB: 19/02/2025

Inji Web Wallet

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

Inji Verify

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

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

Verifiable QR Code - Valid VC

Sample QR code - Valid VC Data

Verifiable QR Code - Expired VC

Sample QR code - Expired VC Data

Verifiable QR Code - Invalid VC

Sample QR code - Invalid VC Data

Here we present the product roadmap for the whole of 'Inji Stack' for the calendar year 2025.

The quarters are defined as follows:

• Q1: Jan'25 – Mar'25

• Q2: Apr'25 – Jun'25

• Q3: Jul'25 – Sep'25

• Q4: Oct'25 – Dec'25

Inji Wallet

Inji Mobile

Inji Web

Inji Certify

Inji Verify