# Inji ## Overview Inji is a verifiable credentialing stack that provides a way to share tamper-proof, instantly verifiable data which is cryptographically signed by a trusted issuer, and users can store them securely on their devices or browsers and share them when needed. * **Issuer**: The entity that issues the credential and makes claims about the subject (e.g., a university issuing a degree, a government issuing a passport, an employer issuing a work permit). The issuer cryptographically signs the VC. Inji's 'Issuance-module' is called [Inji Certify](/inji-certify/overview). * **Holder**: The individual or entity which possesses the credential (e.g., the student with the degree, the citizen with the passport, the employee with the work permit). The holder stores and manages their VCs. Inji's 'Holder-module' is called [Inji Wallet](/inji-wallet/inji-mobile). * **Verifier**: The entity that requests and verifies the credential to confirm a claim (e.g., an employer checking a degree, a border agent checking a passport, a landlord checking a work permit). The verifier checks the cryptographic proofs to ensure the VC's authenticity and integrity. [Inji Verify](/inji-verify/overview). Some everyday examples of Verifiable Credentials include: * A national ID issued as a digital credential * A diploma issued by a university * A background verification report from an employer * A subsidy or benefit eligibility certificate from a government agency VCs allow: * Instant verification, even offline * User control over when and how data is shared * Interoperability across platforms and borders * Reduced fraud and manual checks ![Inji's Triangle Of Trust](/files/BZ0MrRCkkk4CgM2BBPjo) 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. {% embed url="" %} ### Inji’s Key Capabilities **Secure Issuance**: Issue verifiable credentials with digital signatures, ensuring authenticity. Cross-Platform Accessibility: Available via mobile app or web interface, ensuring inclusivity for all users. Privacy-Preserving Sharing: Users control what they share, with whom, and for how long. Offline Compatibility: Works in low-connectivity or offline environments, critical for inclusion. Fast, Trusted Verification: Credentials can be verified quickly and securely, even by non-technical service providers. ### Inji Stack Components #### Inji Certify– Credential Issuance Enables trusted entities to issue digitally signed credentials. Supports: * Multiple formats: JSON-LD, SD-JWT,mDOC and many more. A tool that enables issuers to seamlessly connect with existing data sources to issue verifiable credentials. * Connecting with existing databases and offering configurable credential schemas, it caters to diverse use cases across different sectors and industries. * Revocation management * Ledger and credential status checks * Schema and credential registry management #### Inji Wallet – Credential Holding and Sharing Empowers users to manage their credentials on different devices: * Inji Mobile: Android and iOS app to download, store, and present credentials securely * Inji Web: Browser-based wallet for users without smartphones, offering print and share features #### Inji Verify – Credential Verification Allows service providers and organizations to: * Scan and validate credentials * Check credential status (validity, expiry, revocation) * Integrate with the existing relying party or service providers ### Real-World Applications
DomainExample Applications
HealthcareImmunization records, medical certifications
EducationDegrees, training certificates, learning records
Social WelfareBenefit eligibility, ration cards
FinanceKYC credentials, account onboarding
MobilityDriving licenses, transportation passes
EmploymentJob credentials, background checks
OthersMany more
### Interoperability and Standards Inji follows widely adopted open standards, ensuring flexibility and long-term sustainability: * W3C Verifiable Credentials Data Model * OpenID for Verifiable Presentation (OpenID4VP) * OpenID for Verifiable Credential Issuance (OpenID4VCI) * Claim 169 * ISO/IEC 18013-5: mDoc/mDL * IETF SD-JWT-based Verifiable Credentials * W3C based SD-JWT-based Verifiable Credentials * DID (Decentralised Identifiers) support ### Inji: How the Pieces Work Together This section will contain a clear diagram illustrating the interaction between Inji Certify, Inji Wallet (mobile + web), Inji Verify. The diagram should also show the components involved to build Inji. #### How it works? * **Issuance**: An issuer creates a digital credential with claims about a subject and cryptographically signs it. * **Holding**: The signed credential is then given to the holder, who stores it securely in a digital wallet or similar application. * **Presentation**: When needed, the holder can present the VC (or a verifiable presentation, which can include multiple VCs or selectively disclosed information) to a verifier. * **Verification**: The verifier uses the cryptographic proofs within the VC to confirm that it was issued by a trusted party and has not been tampered with. This verification often involves checking against a "Verifiable Data Registry" where public keys of issuers are stored. ![Component Diagram](/files/PJE8NvEE8YVKY8WLSbQt) ### Summary Inji provides a secure, inclusive, and interoperable solution for issuing and managing digital credentials. By enabling individuals to hold their credentials and share them when needed, Inji supports faster access to services while protecting privacy and reducing fraud. Whether you are: * A user needing better control over their identity and credentials, * An issuer needing to deliver secure digital certificates, or * A verifier needing reliable proof of information, Inji offers the tools you need to make digital credentialing simple, trusted, and universal. # Try It Out ## Overview Welcome to the "**Try It Out**" section! Here, we offer you hands-on experience to better understand how our product works and how you can leverage its features. This section will guide you through some simple steps to get started. If you're a developer or a partner interested in experiencing or integrating with Inji Web, we invite you to explore our designated sandbox environments. ### **Collab: Development Integration Environment** Collab serves as our development integration environment, featuring QA-tested dockers. It's a dedicated space where our partners and contributors can build on the platform or integrate with the latest QA-tested version of the code. This environment undergoes regular nightly builds from our engineering team, making it a hub for continuous development activities. ### **How to use:** Access resources on Collab, our sandbox environment, through the provided[ link](https://collab.mosip.net/). ### **Collab Guides** Explore the guides of the various Inji Modules from below:
Inji Mobile/files/1ZAwNeSBI0nZC375QlV3/pages/FBgVPO5zAoZISq1yrezG
Inji Web/files/aS8B2lZsPjX3UVzrFGZ5/pages/DlSGbjkqXqU3iscUeqb0
Inji Verify/files/11Pt1XSn6lIVVBcsQ7io/pages/5VcLcA6n5cSOT0BA06P5
### **Synergy: Stable Integration Environment** Synergy represents our stable environment, where the most recently released version of the MOSIP platform and applications are deployed for partners to seamlessly integrate and conduct testing. For quick access to environment related resources, please visit the provided[ link](https://synergy.mosip.net/). ### **Feedback and Support** If you require any assistance or encounter any issues during the testing and integration process, kindly reach out to us through the support mechanism provided below. * Navigate to [Community](http://community.mosip.io/). * 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. \ \\ # 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**](https://collab.mosip.net/) 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 ### 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. * Now you can self generate your own UIN Credential using the [Collab environment](https://collab.mosip.net/). * Click on the **Get UIN** button located at the top-right corner of the page. This will open the [Self Registration Form](https://self-register.collab.mosip.net/), Alternatively, you can simply click on this [link](https://self-register.collab.mosip.net/) to self register. You need to duly fill the self registration form. * On successful registration the UIN is sent to you over the email you used for registration, For more details you follow the [Generating Demo Credentials Guide](https://docs.mosip.io/1.2.0/general/collab-getting-started-guide/generating-demo-credentials). **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 Name: insuranceCredentials * DOB: 2000-01-01 * Policy Number: 12345 ### 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: 1. To obtain sample verifiable credentials embedded in a QR code, please initiate the process by following the steps to generate the QR code, click [**here**](https://docs.mosip.io/inji/inji-verify/build-and-deploy/creating-verifiable-credentials-and-generating-qr-codes)! 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

Valid Verifiable Credentials - Data Model v2.0

#### Data Model v2.0 ```json { "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" } } } ``` #### Sample QR code - Valid VC Data

Valid Verifiable Credentials - Data Model v1.1

#### Data Model v1.1 ```json { "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" } } } ``` ### **Verifiable QR Code - Expired VC**

Expired Verifiable Credentials

### **Sample QR code - Expired VC Data** ```json { "id": "did:rcw:ab01ec3f-9f67-4ce8-ade1-8fce82a9bee1", "type": [ "VerifiableCredential", "LifeInsuranceCredential", "InsuranceCredential" ], "proof": { "type": "Ed25519Signature2020", "created": "2024-05-03T12:53:39Z", "proofValue": "z4GVSorSVms65uTSLHRdqJB7Km7UuyzGzYbu9uKuwBPRLgHLmBMa8YnBczVh4id2PMsrB31kjCbe6NVLdA9jThURs", "proofPurpose": "assertionMethod", "verificationMethod": "did:web:challabeehyv.github.io:DID-Resolve:3313e611-d08a-49c8-b478-7f55eafe62f2#key-0" }, "issuer": "did:web:challabeehyv.github.io:DID-Resolve:3313e611-d08a-49c8-b478-7f55eafe62f2", "@context": [ "https://www.w3.org/2018/credentials/v1", "https://holashchand.github.io/test_project/insurance-context.json", { "LifeInsuranceCredential": { "@id": "InsuranceCredential" } }, "https://w3id.org/security/suites/ed25519-2020/v1" ], "issuanceDate": "2024-05-03T12:53:39.113Z", "expirationDate": "2024-06-02T12:53:39.110Z", "credentialSubject": { "id": "did:jwk:eyJrdHkiOiJFQyIsInVzZSI6InNpZyIsImNydiI6IlAtMjU2Iiwia2lkIjoic3pGa2cyOVFFalpiQ1VheFRfbFdiZElEU1ZQNWhlREhTeGR6UlhTOW1WZyIsIngiOiJzeVZ2Y2pEX1k0Y0xFS2NUTGR3a1dEWnR1RGpGWGxwcUtLZ2l5TDB2ZUY0IiwieSI6Ii13eGZIMDZRclRCZGljOG1yRDRBM2E0alhGREx1RnlBa0NPMm56Z3BNUGMiLCJhbGciOiJFUzI1NiJ9", "dob": "1991-08-13", "email": "challarao@beehyv.com", "gender": "Male", "mobile": "0123456789", "benefits": [ "Critical Surgery", "Full body checkup" ], "fullName": "Challarao V", "policyName": "Start Insurance Gold Premium", "policyNumber": "1234567", "policyIssuedOn": "2023-04-20T20:48:17.684Z", "policyExpiresOn": "2033-04-20T20:48:17.684Z" } } ``` ### **Verifiable QR Code - Invalid VC**

Invalid Verifiable Credential

### **Sample QR code - Invalid VC Data** ```json { "id": "did:cbse:327b6c3f-ce17-4c00-ae4f-7fb2313b0626", "type": [ "VerifiableCredential", "UniversityDegreeCredential" ], "proof": { "type": "Ed25519Signature2020", "created": "2024-05-16T07:27:43Z", "proofValue": "z56crqnnjmvDa46FqmAnVhEttqKtFMTQ1et1mM5dA3WSHtb5ncQ36sS8fG3fxw6dpvtqbqvaE5FzaqwJTBX6dGH3P", "proofPurpose": "assertionMethod", "verificationMethod": "did:web:Sreejit-K.github.io:VCTest:d40bdb68-6a8d-4b71-9c2a-f3002513ae0e#key-0" }, "issuer": "did:web:Sreejit-K.github.io:VCTest:d40bdb68-6a8d-4b71-9c2a-f3002513ae0e", "@context": [ "https://www.w3.org/2018/credentials/v1", "https://sreejit-k.github.io/VCTest/udc-context2.json", "https://w3id.org/security/suites/ed25519-2020/v1" ], "issuanceDate": "2023-02-06T11:56:27.259Z", "expirationDate": "2025-02-08T11:56:27.259Z", "credentialSubject": { "id": "did:example:2002-AR-015678", "type": "UniversityDegreeCredential", "ChildFullName": "Alex Jameson Taylor", "ChildDob": "January 15, 2003", "ChildGender": "Male", "ChildNationality": "Arandian", "ChildPlaceOfBirth": "Central Hospital, New Valera, Arandia", "FatherFullName": "Michael David Taylor", "FatherDob": "April 22, 1988", "FatherNationality": "Arandian", "MotherFullName": "Emma Louise Taylor", "MotherDob": "June 5, 1990", "MotherNationality": "Arandian", "RegistrationNumber": "2002-AR-015678", "DateOfRegistration": "January 20, 2002", "DateOfIssuance": "January 22, 2002" } } ``` {% hint style="info" %} Feel free to scan or upload these QR codes to experience the functionality firsthand. {% endhint %} # Use case ## Use Cases of Verifiable Credentials and Their Impact ### Use Case 1: Healthcare Industry **Current Challenge**: Patients often need to share medical records and test results securely across different healthcare providers. This process is cumbersome, requiring manual handling of paper documents or insecure sharing via email and other communication channels. **Solution with Verifiable Credentials**: Healthcare providers can issue VCs for vaccination records, allergies, or medication history. VCs can securely store and share medical records, test results, and vaccination history digitally. Patients can then easily share these credentials with other providers, ensuring continuity of care and faster treatment. Patients can control access to their data, ensuring only authorized healthcare providers can verify and access their information. **Benefits**: * **Reduced Friction**: Patients can easily share verified medical credentials with healthcare professionals, streamlining the consultation and treatment process * **Enhanced Privacy and Security**: Verifiable credentials use cryptography to ensure data integrity and protect sensitive medical information ### Use Case 2: Education Sector **Current Challenge**: Students often require verified academic transcripts and certificates when applying for further education or job opportunities, which they often carry physical transcripts or certifications. Requesting and verifying these documents can be time-consuming and prone to fraud. **Solution with Verifiable Credentials**: Educational institutions can issue VCs such as digital diplomas, certificates, and transcripts. Students can share these credentials with potential employers or other educational institutions quickly and securely, streamlining verification and reducing wait times. **Benefits**: * **Efficient Verification**: Employers and educational institutions can instantly verify the authenticity of academic credentials without relying on manual checks or third-party verification services * **Prevention of Fraud**: Verifiable credentials use cryptographic signatures to ensure the integrity and authenticity of educational documents, reducing the risk of forgery ### Use Case 3: Financial Services **Current Challenge**: Customers often need to prove their identity and financial history when applying for loans, opening bank accounts, or accessing other financial services. This process typically involves submitting multiple paper documents and undergoing lengthy identity verification procedures. **Solution with Verifiable Credentials**: Financial institutions can issue VCs that include identity information, credit scores, and financial history. Customers can use these credentials to securely and selectively share their information with authorized institutions. **Benefits**: * **Streamlined Onboarding Process**: VCs enable faster and more efficient customer onboarding, reducing paperwork and administrative overhead for financial institutions * **Enhanced Data Privacy**: Customers have greater control over their personal and financial data, minimizing the risk of identity theft and unauthorized access ### Use Case 4: Travel and Immigration **Current Challenge**: Travelers often face challenges proving their identity and vaccination status when crossing borders. Paper-based documents are prone to loss or damage, leading to delays and disruptions during travel. Travelers juggle multiple documents for border crossings (passports, visas, health certificates) leading to delays and frustration. **Solution with Verifiable Credentials**: Governments and health authorities can issue verifiable credentials for vaccination records, identity verification, and travel permissions. Travelers can present these digital credentials at checkpoints or border crossings securely and efficiently. These credentials can be easily accessed via mobile wallets and verified electronically, speeding up border processing and reducing queues. **Benefits**: * **Facilitated Cross-Border Travel**: Verifiable credentials enable seamless verification of identity and vaccination status, reducing wait times and administrative hurdles at immigration checkpoints * **Improved Public Health Measures**: Authorities can track and verify vaccination records more effectively using digital credentials, supporting efforts to manage public health crises such as pandemics ### Use Case 5: Employment * **Challenge**: Job seekers often face delays due to lengthy background checks and verification of employment history and skills * **Solution**: Employers can issue verifiable credentials for past employment and skills acquired. Job seekers can then share these credentials with potential employers, allowing for faster verification and a smoother hiring process ### Use Case 6: Government Services * **Challenge**: Citizens often need to present physical documents (birth certificates, proof of residence) to access government services, leading to inefficiency and potential loss of documents * **Solution**: Government agencies can issue verifiable credentials for citizen information. These credentials can be securely accessed and shared for various services, reducing administrative burdens and streamlining access ### Benefits of Verifiable Credentials in all above mentioned scenarios: * **Reduced Friction**: Verifiable credentials eliminate the need for physical documents, simplifying processes and speeding up transactions * **Enhanced Security**: Cryptographic verification ensures the authenticity and integrity of credentials, reducing the risk of fraud * **User Control**: Individuals control their data, choosing what information to share and with whom * **Improved Efficiency**: Streamlined workflows and faster access to services for both users and institutions ### Conclusion Verifiable credentials offer versatile solutions across various domains by leveraging digital technologies to enhance data security, privacy, and efficiency. By addressing common challenges associated with identity verification and data sharing, verifiable credentials empower individuals and organizations to streamline processes and improve trust in digital interactions. # 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](https://www.youtube.com/playlist?list=PLJH-POb_55z_kaiEpAzaT_H4hUdGW6QcQ) ### **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. {% embed url="" %} ### **Inji Certify** #### **Product Overview** **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. {% embed url="" %} #### **Local Setup & Deployment using Docker Compose** **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. {% embed url="" %} #### **Technical Deep Dive - Verifiable Credential Issuance** **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. {% embed url="" %} ### **Inji Mobile Wallet** #### **Product Overview** **What you'll learn**: * Comprehensive walkthrough of the **Inji Mobile Wallet** app. * Demonstrates secure storage, management, and sharing of verifiable credentials. * Covers key features: * **Selective disclosure** for privacy-preserving data sharing. * **Offline verification** via Bluetooth Low Energy (BLE). * **OpenID4VP-based interoperability** with verifiers. * **Multi-issuer and multi-credential** handling. * Highlights use cases in **travel, employment, public service delivery** and many more. {% embed url="" %} ### **Inji Web Wallet** #### **Product Overview** **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. * Showcases accessibility for users without smartphones or in assisted-use environments. {% embed url="" %} #### **Local Setup Guide** **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. {% embed url="" %} #### **Mimoto Setup** **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. {% embed url="" %} ### **Inji Verify** #### **Product Overview - Your Gateway to Trusted Verifiable Credential Verification** **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. {% embed url="" %} #### **Technical Deep Dive** **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. {% embed url="" %} *** ## Inji Ecosystem Workshop {% hint style="warning" %} **Note**: The video resources listed below are earlier recordings from webinars held in **2024**. While they are not being archived at this time, they remain available as they provide useful context and practical demonstrations that may still benefit viewers. {% endhint %} ### 1. Comprehensive demonstration on Digital Identity Management and Credential Integration {% embed url="" %} 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. ### 2. Inji Certify Credential Issuance Workshop {% embed url="" %} 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. ### 3. Inji A Technical Deep Dive {% embed url="" %} 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. ### 4. Unlocking the Value of Integrations with Inji and eSignet {% embed url="" %} 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. # Standards and Compliances # Standards and Compliances ### Overview Inji is built on **open standards** to ensure **interoperability, security, and trust** in verifiable credentials. This document consolidates all standards across Inji modules—**Certify** (issuer), **Wallet Mobile & Web** (holder), and **Verify** (verifier)—with clear separation between standard definitions and module-specific implementations. #### Why Standards Matter By adhering to open standards, Inji ensures: * **Portable Credentials**: Credentials issued by Inji can be verified by ANY W3C-compliant verifier * **Ecosystem Interoperability**: Works with Microsoft Entra, Hyperledger Aries, Trinsic, and custom implementations * **Trusted Security**: Standards define cryptographic best practices, not proprietary magic * **Vendor Independence**: No lock-in; standards-based = future-proof * **Large-Scale Adoption**: Governments, enterprises, and NGOs can integrate with confidence #### Standards Bodies & Organizations | Organization | Role | Standards Contributed | | ---------------------------------------------- | ------------------------------------- | ------------------------------------------------------------------- | | **W3C** (World Wide Web Consortium) | Global web standards body | Verifiable Credentials, DIDs, Data Integrity, Bitstring Status List | | **OpenID Foundation** | Authentication & federation standards | OpenID4VCI, OpenID4VP (credential issuance & presentation) | | **IETF** (RFC authors) | Internet engineering standards | SD-JWT, OAuth 2.0, CWT, CBOR, JWT | | **ISO** (International Standards Organization) | Hardware & document standards | ISO 18013-5/7 (mDL/mDoc for mobile documents) | | **MOSIP** (MOSIP Project) | MOSIP-specific standards | Claim 169 (QR-encoded credentials), Identity standards | **Legend**: ✅ Available | 🔲 Planned/Coming Soon | - Not Applicable | Dev In Development
StandardVersionCertifyMobileWebVerifyPrimary RFC/Link
W3C VC Data Model1.1UseUseUsehttps://www.w3.org/TR/vc-data-model/
W3C VC Data Model2.0UseUse🔲Usehttps://www.w3.org/TR/vc-data-model-2.0/
OAuth 2.0RFC 6749UseUseUse-https://tools.ietf.org/html/rfc6749
OpenID Connect1.0Via eSignetUseUse-https://openid.net/connect/
OpenID4VCIDraft 13IssuerClientClient-https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0-13.html
OpenID4VPDraft 23-ClientClientServerhttps://openid.net/specs/openid-4-verifiable-presentations-1_0-23.html
OpenID4VP-BLEDraft 23 Ext-Offline-🔲 Serverhttps://github.com/openid/OpenID4VP
W3C DIDs1.0UseUseUseUsehttps://www.w3.org/TR/did-core/
JSON-LD1.1UseUseUseUsehttps://www.w3.org/TR/json-ld11/
SD-JWTIETF DraftUseUseUseUsehttps://datatracker.ietf.org/doc/html/draft-ietf-oauth-selective-disclosure-jwt
W3C Bitstring Status List2.0UseUseUseUsehttps://www.w3.org/TR/vc-bitstring-status-list/
CBORRFC 7049UseUse-Usehttps://tools.ietf.org/html/rfc7049
CWT/COSERFC 8152/9052🔲Use-Usehttps://tools.ietf.org/html/rfc8152
Claim 169MOSIP v1.2.0🔲 v0.14Use-Usehttps://docs.mosip.io/1.2.0/readme/standards-and-specifications/mosip-standards/169-qr-code-specification
ISO 18013-5mDL🔲Use🔲🔲https://www.iso.org/standard/69084.html
ISO 18013-7mDoc🔲🔲 Dev🔲🔲 Devhttps://www.iso.org/standard/80601.html
W3C Data Integrity 2.0WD🔲-🔲-https://www.w3.org/TR/vc-data-integrity/
JWTRFC 7519UseUseUseUsehttps://tools.ietf.org/html/rfc7519
### Cross-Module Features Matrix At a glance: which feature is supported by which module?
FeatureCertifyMobileWebVerifyVersion/Notes
Issue W3C VC 1.1✅---v0.8.0+
Issue W3C VC 2.0✅---v0.11.0+
Store W3C VC 1.1-✅✅-v0.8.0+
Store W3C VC 2.0-✅🔲 v0.16.0-v0.11.0+
Verify W3C VC 1.1/2.0---✅v0.17.0+
Issue JSON-LD Credentials✅---v0.8.0+
Present JSON-LD Credentials-✅✅-v0.8.0+
Verify JSON-LD Proofs---✅v0.17.0+
Issue JWT Credentials✅---v0.8.0+
Present JWT Credentials-✅✅-v0.9.0+
Verify JWT Signatures---✅v0.17.0+
Issue SD-JWT Credentials✅---v0.13.0+
Present SD-JWT (Selective)-✅✅-v0.10.0+
Verify SD-JWT Presentations---✅v0.17.0+
OpenID4VCI Issuer✅---v0.8.0+
OpenID4VCI Client (Download)-✅✅-v0.8.0+
OpenID4VP Client (Present)-✅✅-v0.9.0+, Web v0.15.0+
OpenID4VP Server (Verify)---✅v0.17.0+
OpenID4VP-BLE (Offline)-✅-🔲 v0.18.0v0.14.0+
OAuth 2.0 Integration✅✅✅-v0.8.0+
OIDC Support (Federated Login)✅ eSignet✅✅-v0.9.0+
Publish DIDs✅---v0.8.0+
Resolve Issuer DIDs-✅✅✅v0.9.0+
Holder-Bound DIDs-🔲🔲-Future
W3C Bitstring Status List✅ Publish✅ Check✅ Check✅ Checkv0.10.0+
Issue Claim 169 QRs🔲 v0.14.0---Planned
Store Claim 169 QRs-✅--v0.10.0+
Present Claim 169 QRs-✅--v0.10.0+
Scan Claim 169 QRs---✅v0.17.0+
Verify Claim 169 Signatures-✅-✅v0.10.0+, Verify v0.17.0+
Issue ISO mDL🔲 v0.14.0+---Planned
Store mDL Credentials-✅🔲-v0.12.0+
Present mDL (NFC/BLE)-✅--v0.12.0+
Verify mDL Presentations---🔲 v0.18.0Planned
Ed25519 Signing✅---v0.8.0+
Ed25519 Verification-✅✅✅v0.8.0+
RSA Signing✅---v0.8.0+
RSA Verification-✅✅✅v0.8.0+
ECDSA Signing✅---v0.11.0+
ECDSA Verification-✅✅✅v0.11.0+
PDF Export--✅-v0.15.0+
Multi-Language Display-✅✅✅v0.11.0+ (11 languages)
SVG Credential Templates✅✅✅✅v2.0 support, v0.11.0+
Offline Credential Storage-✅✅ Guest-v0.8.0+
Revocation Checking-✅✅✅v0.10.0+
**Legend**: ✅ Available | 🔲 Planned/Coming | - Not Applicable *** ### Standards Roadmap & Timeline #### Certify Release Timeline
VersionRelease DateMajor Standards Additions
v0.8.0May 2024W3C VC 1.1, OpenID4VCI Draft 13, JSON-LD, OAuth 2.0
v0.9.0July 2024OpenID Connect (eSignet integration), Enhanced DID support
v0.10.0Sept 2024W3C Bitstring Status List, Revocation endpoints
v0.11.0Nov 2024Ed25519 (2020 spec), ECC K1/R1 signing, Enhanced crypto
v0.12.0Jan 2025SD-JWT (Draft) support, PKI integration
v0.13.0Mar 2025SD-JWT (Full), Enhanced OAuth flows
v0.14.0May 2025Claim 169 QR, Initial ISO mDL/mDoc
v0.15.0July 2025W3C Data Integrity 2.0 proofs
v0.16.0+Q4 2025+Full mDoc/mDL support, Extended crypto (P-384)
#### Mobile Release Timeline
VersionReleaseMajor Standards Additions
v0.8.0May 2024OpenID4VCI client, W3C VC reception, JSON-LD display
v0.9.0July 2024OpenID4VP client, QR presentation
v0.10.0Sept 2024Claim 169 QR storage & display, Bitstring status check
v0.11.0Nov 2024Ed25519 (2020) verification, ECDSA K1/R1, Multi-language
v0.12.0Jan 2025ISO 18013-5 mDL support, NFC presentation
v0.13.0Mar 2025Enhanced SD-JWT support, Improved revocation
v0.14.0May 2025OpenID4VP-BLE offline, Enhanced Claim 169
v0.15.0+Q3 2025+mDoc support, Data Integrity 2.0 verification
#### Web Release Timeline
VersionReleaseMajor Standards Additions
v0.8.0May 2024OpenID4VCI client, JSON-LD credentials
v0.12.0Jan 2025SD-JWT support, Enhanced auth flows
v0.15.0Q2 2025OpenID4VP support, W3C VC 2.0 planning
v0.16.0Q3 2025W3C VC 2.0 full support, Data Integrity 2.0
v0.17.0+Q4 2025+mDoc support, Extended crypto algorithms
#### Verify Release Timeline
VersionReleaseMajor Standards Additions
v0.17.0Q1 2025Claim 169 QR verification, OpenID4VP Draft 23, SD-JWT
v0.18.0Q2 2025OpenID4VP-BLE (offline), ISO mDL/mDoc verification
v0.19.0Q3 2025W3C Data Integrity 2.0 verification, Extended crypto
v0.20.0+Q4 2025+Full mDoc support, Post-quantum crypto preparation
### References #### W3C Specifications
SpecificationLinkCurrent VersionStatus
Verifiable Credentials Data Model 1.1https://www.w3.org/TR/vc-data-model/1.1W3C Recommendation
Verifiable Credentials Data Model 2.0https://www.w3.org/TR/vc-data-model-2.0/WD (Working Draft)Latest
Decentralized Identifiers (DIDs) v1.0https://www.w3.org/TR/did-core/1.0W3C Recommendation
JSON-LD 1.1https://www.w3.org/TR/json-ld11/1.1W3C Recommendation
Bitstring Status List v2.0https://www.w3.org/TR/vc-bitstring-status-list/2.0W3C Specification
Data Integrity 1.0https://www.w3.org/TR/vc-data-integrity/1.0W3C Editor's Draft
#### OpenID Foundation Specifications
SpecificationLinkVersionStatus
OpenID4VCIhttps://openid.net/specs/openid-4-verifiable-credential-issuance-1_0-13.htmlDraft 13Latest Stable
OpenID4VPhttps://openid.net/specs/openid-4-verifiable-presentations-1_0-23.htmlDraft 23Latest Stable
OpenID Connect Core 1.0https://openid.net/specs/openid-connect-core-1_0.html1.0Approved
#### IETF RFC Standards
SpecificationRFCLinkStatus
OAuth 2.0RFC 6749https://tools.ietf.org/html/rfc6749Standard
JSON Web Token (JWT)RFC 7519https://tools.ietf.org/html/rfc7519Standard
CBORRFC 7049https://tools.ietf.org/html/rfc7049Standard
COSE Signing and EncryptionRFC 8152https://tools.ietf.org/html/rfc8152Standard
EdDSA (Ed25519, Ed448)RFC 8032https://tools.ietf.org/html/rfc8032Standard
SD-JWTDrafthttps://datatracker.ietf.org/doc/html/draft-ietf-oauth-selective-disclosure-jwtInternet Draft
#### ISO Standards | Specification | ISO Reference | Link | Status | | ----------------------- | ---------------- | ----------------------------------------- | ----------- | | Mobile Driver's License | ISO 18013-5:2021 | | Published | | Mobile Document Spec | ISO 18013-7 | | In Progress | #### MOSIP Standards
SpecificationVersionLinkStatus
Claim 169: QR Code Specv1.2.0 (Latest)https://docs.mosip.io/1.2.0/readme/standards-and-specifications/mosip-standards/169-qr-code-specificationCurrent
Claim 169: QR Code Specv1.1.0https://docs.mosip.io/1.2.0/readme/standards-and-specifications/mosip-standards/169-qr-code-specification-1Archive
Claim 169: QR Code Specv1.0.0https://docs.mosip.io/1.2.0/readme/standards-and-specifications/mosip-standards/169-qr-code-specifications-1.0.0Archive
#### Related Documentation | Document | Link | Purpose | | --------------------- | ------------------------------------------------------------- | -------------------------- | | Inji Certify Overview | | Credential issuer features | | Inji Mobile Wallet | | Holder wallet features | | Inji Web Wallet | | Browser-based wallet | | Inji Verify Portal | | Credential verifier | | Release Notes | | Version history & features | *** ### Document Information **Document Version**: 2.0 (Restructured for Non-Repetition)\ **Last Updated**: March 3, 2026\ **Structure Implemented**: Standards Detail Library (single source) + Module Implementation (features only)\ **Key Improvement**: Each standard defined once; modules reference and extend with implementation details\ **Maintenance Model**: Update standard info in one place (Section 3); module features in their respective sections (4-7) # Standards and Compliances Details #### W3C Verifiable Credentials Data Model Official Specification: - v1.1 (Recommendation, 2019): - v2.0 (Working Draft, latest): Overview: Industry-standard specification for expressing credentials as JSON-LD documents with W3C-compliant proof mechanisms. Defines the structure, semantics, and verification requirements for all digital credentials. Why It Matters: - Universal credential format recognized across 30+ countries - Semantic interoperability via JSON-LD context - Foundation for all Inji credential types - Backwards compatible: v1.1 → v2.0 migration path Supported By:
ModuleStatusRole
CertifyAvailable (both v1.1 & v2.0)Issue credentials in W3C format
MobileAvailable (v1.1 & v2.0)Store, display, and present credentials
WebAvailable (v1.1, v2.0 planned v0.16.0)Download and present in browser
VerifyAvailable (both v1.1 & v2.0)Verify credential proofs and signatures
Key Aspects Across Implementation: - Supports multiple proof types: JSON-LD proofs, JWT, Data Integrity proofs - Credential structure: issuer, subject, claims, issued date, expiration - Holder binding: Proof of possession via cryptographic signatures - Selective disclosure: Latest v2.0 includes selective claim presentation. #### OAuth 2.0 & OpenID Connect Official Specifications: - OAuth 2.0 (RFC 6749): - OpenID Connect 1.0 (OpenID Foundation): Overview: OAuth 2.0 is the industry-standard authorization framework. OpenID Connect (OIDC) adds an authentication layer on top, enabling secure user login and identity delegation. Why It Matters: - Enables federation: users login via eSignet, Google, Keycloak, etc. - Credential issuance tokens (access tokens) validated via OAuth - Authorization code flow for secure credential flows - Industry standard for 15+ years Supported By:
ModuleStatusRole
CertifyAvailableAuthorization for credential issuance; OIDC login via eSignet
MobileAvailableAuthorization to download credentials from issuers
WebAvailableOAuth login (Google, OpenID providers); authorization for credential download
Verify-Not directly used (verification is post-issuance)
#### OpenID for Verifiable Credential Issuance (OpenID4VCI) Official Specification: - Draft 13 (Latest stable): Overview: OpenID Foundation standard for securely delivering verifiable credentials to wallet holders. Extends OAuth 2.0 with credential-specific flows. Why It Matters: - Standardized credential distribution protocol (not proprietary) - Multiple issuance flows: pre-authorized (fast), authorization code (secure) - Supports multiple credential formats: JSON-LD, JWT, SD-JWT, mDoc - Enable interoperability: any OpenID4VCI issuer can issue to any OpenID4VCI-compliant wallet Supported By:
ModuleStatusRole
CertifyAvailable (v0.8.0+)Issue credentials to holders via standardized protocol
MobileAvailable (v0.8.0+)Download credentials from OpenID4VCI-compliant issuers
WebAvailable (v0.8.0+)Download credentials in browser without app
Verify-Not applicable (verifier receives credentials, not issues)
#### OpenID for Verifiable Presentations (OpenID4VP) Official Specification: - Draft 23 (Latest stable): Overview: OpenID Foundation standard for requesting and receiving verifiable presentations. Enables verifiers to request credentials from holders in a standardized way. Why It Matters: - Standardized presentation protocol (holders and verifiers can interoperate) - Multiple presentation modes: cross-device (QR), same-device (app-to-app), BLE (offline) - Selective disclosure: verifier specifies which claims are needed; holder discloses only those - Replaces proprietary presentation workflows Supported By:
ModuleStatusRole
Certify-Not applicable
MobileAvailable (v0.9.0+)Present credentials to verifiers via QR, same-device, or BLE
WebAvailable (v0.15.0+)Present credentials from browser to verifier web portals
VerifyAvailable (v0.17.0+)Request and verify presentations from holders
#### OpenID4VP-BLE (Offline Presentation) Specification: - Extension to OpenID4VP Draft 23: (offline extensions) Overview: Extension to OpenID4VP enabling offline credential presentation via Bluetooth Low Energy (BLE). Allows holders to present credentials without internet connectivity. Why It Matters: - Credentials work in low-connectivity scenarios (refugee camps, remote borders, field verification) - BLE direct P2P communication: no server required - Same cryptographic validation as online presentations - Critical for humanitarian and border control use cases Supported By:
ModuleStatusRole
Certify-Not applicable
MobileAvailable (v0.14.0+)Present credentials via BLE when verifier unavailable
Web-Browser cannot use BLE (security model limitation)
VerifyPlanned (v0.18.0)Receive and validate offline BLE presentations
#### W3C Decentralized Identifiers (DIDs) Official Specification: - W3C DID Core 1.0 (Recommendation, 2021): Overview: W3C standard for creating self-sovereign, decentralized identifiers independent of any centralized directory. Format: did:method:identifier (e.g., did:mosip:123456). Why It Matters: - Issuer identity verification: verifiers can resolve issuer DIDs to public keys - Self-sovereign identity: no government or company controls the identifier - Decentralized: DID methods can use blockchains, DIRs, or proprietary registries - Cryptographic verification: public keys are resolvable and verifiable Supported By:
ModuleStatusRole
CertifyAvailable (v0.8.0+)Issuers publish DIDs and sign credentials with DID keys
MobileAvailable (v0.9.0+)Verify issuer DIDs; resolve issuer public keys for signature validation
WebAvailableVerify issuer DIDs; support for holder-bound DIDs
VerifyAvailableResolve issuer DIDs; validate signatures against DID-published keys
Supported DID Methods: - did:mosip: – MOSIP-based identifiers (primary for Inji in MOSIP deployments) - did:ion: – Layer 2 DID method (Sidetree-based, interoperable) - did:key: – Embedded key DIDs (for testing and simple cases) #### JSON-LD (Linked Data for JSON) Official Specification: - JSON-LD 1.1 (W3C Recommendation, 2020): Overview: Framework for representing linked data in JSON format using semantic contexts. Enables shared understanding of data semantics across different systems. Why It Matters: - Semantic interoperability: different systems understand the same data meaning - URI-based vocabularies: claims like name, birthDate are URIs, not ambiguous strings - Linked data: credentials can reference other credentials, forming knowledge graphs - W3C VC Data Model 1.1 recommendation Supported By:
ModuleStatusRole
CertifyAvailableCredentials issued in JSON-LD format with semantic contexts
MobileAvailableStore and display credentials with semantic understanding
WebAvailableDisplay credentials in human-readable format via JSON-LD context
VerifyAvailableVerify credentials and validate semantic claims
#### Selective Disclosure JWT (SD-JWT) Official Specification: - IETF Internet-Draft: Overview: Privacy-first JWT format where credential holder can selectively disclose claims to verifiers. Claims are salted and hashed; holder reveals only requested ones with proof. Why It Matters: - Privacy: holder doesn’t share unnecessary claims (e.g., shares age verification without exposing birthdate) - Cryptographic proof: verifier can validate disclosed claims without seeing undisclosed ones - Compact: much smaller than full credential with filtered fields - IETF standardization path (moving toward RFC status) Supported By:
ModuleStatusRole
CertifyAvailable (v0.12.0+)Issue SD-JWT credentials with selectively disclosable claims
MobileAvailable (v0.10.0+)Store SD-JWT and present only disclosed claims on verifier request
WebAvailable (v0.15.0+)Present SD-JWT credentials with selective disclosure
VerifyAvailable (v0.17.0+)Verify SD-JWT presentations and validate selective disclosure proofs
#### W3C Bitstring Status List 2.0 Official Specification: - W3C Specification: Overview: Efficient revocation mechanism for credentials. Issuer publishes a bitstring (array of bits) where each bit represents revocation status of one credential. Credentials reference their bit position. Why It Matters: - Scalable revocation: millions of credentials’ status in one compact bitstring - Privacy: doesn’t reveal which credentials are revoked (just a bitstring) - Efficient: holders check one bitstring vs querying issuer for each credential - Universal: works with any credential format Supported By:
ModuleStatusRole
CertifyAvailable (v0.10.0+)Publish revocation bitstrings; encode status list endpoint in credentials
MobileAvailable (v0.10.0+)Check bitstring status before presenting credentials
WebAvailable (v0.15.0+)Validate credential status via bitstring check
VerifyAvailable (v0.17.0+)Verify credential status before accepting presentations
#### CBOR (Concise Binary Object Representation) Official Specification: - RFC 7049: Overview: Binary data serialization format similar to JSON but more compact. Maps, arrays, strings encoded in few bytes. Foundation for QR code and offline credential encoding. Why It Matters: - Compact: CBOR payloads 30-50% smaller than JSON equivalents - QR-friendly: smaller data = more dense QR codes = easier to scan - Efficient parsing: lightweight protocol ideal for low-power devices - CWT foundation: CBOR tokens used for signed credentials Supported By:
ModuleStatusRole
CertifyAvailable (v0.14.0+)Encode Claim 169 QR credentials in CBOR format
MobileAvailable (v0.10.0+)Decode and store CBOR-encoded QR payloads
Web-Not applicable (browsers handle JSON, not CBOR directly)
VerifyAvailable (v0.17.0+)Decode CBOR QR codes; validate CBOR structure
#### CBOR Web Token (CWT) & COSE Signing Official Specification: - RFC 8152 (now 9052/9053): Overview: CBOR-based equivalent of JWT. Uses COSE (CBOR Object Signing and Encryption) for authenticated encryption and signing. Standard for signed CBOR credentials. Why It Matters: - Compact signed credentials: signatures included in CBOR payload - IANA standard: Ed25519 and P-256 signatures registered - Claim 169 standard: Claim 169 QR codes use CWT signing - Offline verification: credentials carry proofs, no server needed Supported By:
ModuleStatusRole
CertifyPlanned (v0.14.0)Issue Claim 169 credentials with CWT signatures
MobileAvailable (v0.10.0+)Verify CWT signatures on Claim 169 QR codes
Web-Not directly used (JSON-based credentials in web)
VerifyAvailable (v0.17.0+)Validate CWT signatures on Claim 169 QR presentations
#### Claim 169: MOSIP QR Code Specification Official Specification: - MOSIP v1.2.0 (Latest, Sept 2025): - v1.1.0: - v1.0.0: Overview: IANA-registered MOSIP standard for compact, cryptographically-signed identity QR codes. Encodes identity attributes in CBOR format, signed with Ed25519 or ECC, embeddable in QR codes. Why It Matters: - Humanitarian focus: v1.2.0 adds refugee-specific attributes (legal status, secondary language, location code) - Offline verification: QR contains full credential + proof; no server needed - Standardized encoding: 23 identity attributes in compact CBOR format - IANA official: Registered as IANA CWT claim, interoperable across systems Evolution: - v1.0.0 (2024): Basic 18 attributes (ID, name, DOB, gender, address, nationality, etc.) - v1.1.0 (2024): Enhanced security documentation; same 18 attributes - v1.2.0 (Sept 2025): Added 5 humanitarian attributes (legal status, secondary language, location code, country of issuance, secondary language name); expanded working group (UNHCR, GIZ, OpenSPP) Supported By:
ModuleStatusRole
CertifyPlanned (v0.14.0)Encode and sign Claim 169 QR credentials in CBOR-CWT format
MobileAvailable (v0.10.0+)Receive Claim 169 QR credentials from issuers; store and display QR blocks
Web-Not applicable (QR-based credentials are mobile-centric)
VerifyAvailable (v0.17.0+)Scan or upload Claim 169 QR codes; decode CBOR; validate signatures
Claim 169 QR Structure (v1.2.0): - Attributes 1-18: Standard identity (name, DOB, address, nationality, etc.) - Attribute 19: Full Name - Secondary Language - Attribute 20: Secondary Language Code - Attribute 21: Location Code - Attribute 22: Legal Status (refugee, asylum seeker, stateless, etc.) - Attribute 23: Country of Issuance - Encryption: CBOR-encoded, optionally encrypted - Signature: Ed25519 or ECC proof #### ISO 18013-5/7: Mobile Document Standards (mDL & mDoc) Official Specifications: - ISO 18013-5:2021 (Mobile Driver’s License): - ISO 18013-7 (Gen Proof Signatures): Overview: ISO international standards for mobile identity documents (driver licenses, general documents, travel credentials). Credentials stored in CBOR format, verified offline via NFC or QR. Why It Matters: - Government standard: used for border control, aviation, age verification - Offline verification: full credential + proof in device, no server dependency - Biometric binding: holder’s face/fingerprint linked to credential - Interoperable: any ISO 18013-compliant reader can verify (border gates, airports) Supported By:
ModuleStatusRole
CertifyPlanned (v0.14.0+)Issue ISO mDL/mDoc credentials in CBOR format
MobileAvailable (v0.12.0+)Store mDL credentials; support NFC/BLE presentation to readers
WebPlanned (v0.16.0+)Display mDoc credentials (note: NFC is not browser-available)
VerifyPlanned (v0.18.0+)Verify mDL/mDoc credentials from NFC or QR presentation
Key Difference from W3C VC: - W3C VC: JSON-LD based, semantic, flexible - ISO mDL/mDoc: Binary (CBOR) based, cryptographically compact, government-focused #### W3C Data Integrity 2.0 Official Specification: - W3C Working Draft: Overview: Emerging W3C specification for cryptographic proofs on JSON-LD documents using JWS (JSON Web Signature) formats. More flexible than JSON-LD Proofs; supports Ed25519, RSA, ECDSA. Why It Matters: - Modern proof mechanisms: moves beyond legacy JSON-LD proof suites - Standardized JWS integration: aligns with JWT/SD-JWT ecosystem - Planned for W3C VC 2.0 adoption - Backward compatible: works with existing VC infrastructure Supported By:
ModuleStatusRole
CertifyPlanned (v0.15.0+)Issue credentials with Data Integrity 2.0 proofs
MobilePlanned (v0.16.0+)Verify Data Integrity proofs on credentials
WebPlanned (v0.16.0+)Display and verify Data Integrity proofs
VerifyPlanned (v0.18.0+)Validate Data Integrity 2.0 signed credentials
#### JWT (JSON Web Token) Official Specification: - RFC 7519: Overview: Compact, self-contained format for securely transmitting information as JSON. Consists of header (algorithm), payload (claims), signature (HMAC or asymmetric). Why It Matters: - Industry standard since 2015: understood by every OAuth/OIDC system - Compact: smaller than W3C VC format, ideal for constrained networks - Stateless verification: signature validates entire token - Foundation for SD-JWT, W3C Data Integrity, JWS Supported By:
ModuleStatusRole
CertifyAvailable (v0.8.0+)Issue JWT-formatted credentials (JWT-VC format)
MobileAvailable (v0.9.0+)Store JWT credentials; verify JWT signatures
WebAvailable (v0.15.0+)Display and present JWT credentials
VerifyAvailable (v0.17.0+)Verify JWT signatures
#### Cryptographic Algorithms Supported algorithms across Inji modules: **EdDSA (Ed25519 & Ed448)** Specification: - RFC 8032: Why It Matters: - Modern elliptic curve: 10x smaller key sizes than RSA-2048 (32 bytes vs 256 bytes) - High performance: faster signing/verification than RSA - Quantum-resistant-ready: smaller key space reduces future quantum threat - W3C recommended for new implementations Support:
AlgorithmVersionCertifyMobileWebVerifyNotes
Ed255192018 SpecAvailableAvailableAvailableAvailableLegacy format, still supported
Ed255192020 SpecAvailable (v0.11.0+)AvailableAvailableAvailableEnhanced key format, recommended
**ECDSA (Elliptic Curve DSA)** Specification: - FIPS 186-4: Why It Matters: - Standardized elliptic curves: P-256 (secp256r1), secp256k1 - Balance: stronger than DSA, smaller keys than RSA - Interoperable: widely supported in blockchain and OpenID ecosystem Support:
AlgorithmCurveCertifyMobileWebVerifyNotes
ECDSAsecp256k1 (K1)Available (v0.11.0+)AvailableAvailableAvailableOpenID ecosystem standard
ECDSAP-256 (R1)Available (v0.11.0+)AvailablePlannedAvailableNIST standard
ECDSAP-384PlannedPlannedPlannedPlannedHigh-security variant
**RSA (Rivest-Shamir-Adleman)** Specification: - RFC 8017: Why It Matters: - Mature standard: 30+ years, broad compatibility - FIPS compliant: required for US government systems - Proven security: no known mathematical breakthroughs - Legacy support: many existing credentials use RSA Support:
Key SizeCertifyMobileWebVerifyNotes
RSA-2048AvailableAvailableAvailableAvailableMinimum secure size
RSA-4096AvailableAvailableAvailableAvailableHigh security, slower
Note: RSA keys are 4-8x larger than Ed25519; use Ed25519 for new credentials. # 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! * [Roadmap 2026](/readme/roadmap/roadmap-2026) * [Roadmap 2025](https://docs.inji.io/readme/roadmap/roadmap-2025) * [Roadmap 2024](https://docs.inji.io/readme/roadmap/roadmap-2024) # Roadmap 2026 & Beyond Here we present the **Inji-Stack product roadmap for 2026** and our strategic horizon forward. This roadmap outlines the planned features, progress, and release details for **Inji Stack**. > The **annual product cycle** for the Inji Stack begins in **January** and concludes in **December**. For detailed module-wise roadmaps, please refer to the respective sections; Inji Wallet ([Mobile](#inji-mobile), [Web](#inji-web)), [Inji Certify](#inji-certify) and [Inji Verify](#inji-verify). ## Inji Wallet * [Inji Mobile](#inji-mobile) * [Inji Web](#inji-web) ### Inji Mobile
Vision *Building a trust-first digital wallet experience simplified sharing, enhanced protection, and frictionless verification for every user, everywhere.* Inji Mobile Wallet’s 2026 vision is to evolve into a fully interoperable, standards-aligned verifiable credential wallet that is secure, user-centric, and future-ready. The roadmap focuses on strengthening foundational capabilities—OpenID4VP & VCI final spec compliance, advanced cryptographic support (ECC R1, BBS+), unified key management, profile creation, and end-to-end revocation across all major VC formats (SD-JWT, JWT, mDoc). These upgrades ensure the wallet remains globally interoperable while meeting the needs of governments, implementers, and ecosystems adopting Inji. We aim to deliver a highly reliable and scalable wallet that supports cross-platform verification, richer offline and BLE capabilities, multi-format rendering (SVG, PDF), and enhanced privacy models. We will be able to introduce strategic features such as Shamir’s Secret Sharing for key recovery, BLE enhancements for iOS↔iOS, mDoc revocation, and a dedicated iOS verification library later during the year. Longer-term (2027+) innovation tracks explore multi-user credentials, one-time/bulk credential patterns, consent management, DIDComm, anonymous credentials, and multi-tech-stack portability—setting the foundation for Inji as a universal, secure, and inclusive digital credential wallet for global public infrastructure.
Priority 🗓️Features 🛠️Details 📝Status 📊Release 📌
P1Presentation During Issuance.:github: 2178🟢 Completedv0.22.0
P1Claim 169 QR Code Support.:github: 2179🟢 Completedv0.22.0
P1Wallet Login & Common Key Management.:github: 2119🟠 In-Progress
P1Upgrade to OpenIDVCI final version 1.0:github: TBA🟠 In-Progress
P1Upgrade to OpenIDVP final version 1.0:github: TBA🟠 In-Progress
P1Support for ECC R1.:github: TBA🟠 In-Progress
P1Create Profile - Profiling with Single VC.:github: TBA🔵 Planned
P1Credential Refresh Support.:github: TBA🔵 Planned
P1DC API Support.:github: TBA🔵 Planned
P1W3C Data Model 2.0-based SD-JWT & JWT VC Support.:github: TBA🔵 Planned
P1IETF based SD-JWT & JWT SVG Rendering.:github: TBA🔵 Planned
P1Delegated Access Support from Issuer.:github: TBA🔵 Planned
P1Revocation of mDoc/mDL VC Format.:github: TBA🔵 Planned
P2Shamir’s secret open standard Implementation.:github: TBAMoved to 2027
### Inji Web
Vision The vision for the Inji Web roadmap is to build a secure, interoperable, and user-friendly web wallet that fully supports the next generation of global verifiable credential standards. By introducing capabilities such as W3C Data Model 2.0, SD-JWT, mDoc/mDL, revocation, credential refresh, profile management, delegated access, and offline/USSD-based sharing, Inji Web aims to offer citizens and organizations a trusted platform to receive, manage, and present credentials across diverse digital ecosystems. With enhanced privacy features like BBS+ and seamless integration with identity providers and verifier services, Inji Web will evolve into a comprehensive, inclusive, and scalable wallet experience suitable for national-level deployments and cross-sector use cases.
Priority 🗓️Features 🛠️Details📝Status 📊Release 📌
P1W3C Data Model 2.0 & SVG Render Method.:github: TBA🟢 Completedv0.16.0
P1Claim 169 QR Code Support.:github: TBA🟢 Completedv0.16.0
P1SD-JWT via OpenIDVP Flow.:github: TBA🟠 In-Progress
P1Upgrade to OpenIDVP final version 1.0:github: TBA🟠 In-Progress
P1Upgrade to OpenIDVCI final version 1.0:github: TBA🟠 In-Progress
P1

Create Profile - Profiling with Single VC (Profile Management

Multi-profile).

:github: TBA🔵 Planned
P1Revocation of Data Model 2.0 VC.:github: TBA🔵 Planned
P1Presentation During Issuance.:github: TBA🔵 Planned
P1mDoc/mDL VC Support.:github: TBA🔵 Planned
P1Pre-Auth Code Flow.:github: TBA🔵 Planned
P2Credential refresh.:github: TBA🔵 Planned
P2

USSD Support - Offline VC sharing via a feature phone

USSD Wallet.

:github: TBA🔵 Planned
P2W3C Data Model 2.0 SD-JWT & JWT VC Support.:github: TBA🔵 Planned
P2Delegated Access Support from Issuer.:github: TBAMoved to 2027
P2Enhancement to Inji Web Login: Support other ID provider login like eSignet.:github: TBAMoved to 2027
P2

BBS + Support:

  • Improve user privacy
  • 1 secret, and a domain-specific public key
:github: TBAMoved to 2027
P3Recovery of Web Wallet.:github: TBAMoved to 2027
P3Enhancement to Inji Web Login: Audit Mechanism with Inji web login.:github: TBAMoved to 2027
### Inji Certify
Vision In 2026, Inji Certify will be a globally trusted, standards-aligned digital credential issuance platform enabling secure, interoperable, and scalable verifiable credentials across ecosystems. By supporting universal credential formats, OpenID4VCI v1.0, advanced cryptography, and a robust multi-issuer architecture, Certify will simplify adoption for large-scale government and enterprise deployments. Alongside delivering policy-ready issuance, revocation, and trust framework integrations, the platform will prioritize clearing technical debt and strengthening security, maintainability, and operational reliability—ensuring Certify remains a future-ready, developer-friendly backbone for privacy-preserving digital credentials worldwide.
Priority 🗓️Feature 🛠️Details 📝Status 📊Release 📌Details - 2 📝
P1Presentation During Issuance with JSON LD VC Format.:github: 293🟢 Completed0.14.0
P1VC Issuance with mDoc/mso VC format.:github: 279🟢 Completed0.14.0
P1Pre Auth Code Issuance for JSON-LD Format.:github: 453🟢 Completed0.14.0
P1Embedding Multiple QR code in VC.:github: 491🟢 Completed0.14.0
P1Adoption of OpenIDVCI v1.0.:github: 674🟢 Completedv1.0.0-alpha.1

Multiple data providers on one instance of Certify.

Multi Issuers support: (focusing towards one DB-postgres)

  • multiple issuers with multiple cred
P1SVG Rendering - support for multiple templates rendering.:github: 737🔵 PlannedModifying system to follow the lates t version OpenIDVCI
P1Support JWT VC Format.:github: 890🔵 Planned
  • plain JWT - W3C JSON
  • Support data model 2.0
P1Multiple issuer.:github: 510🔵 Planned
  • Allowing issuer to configure mutilple template for same VC
P1Support for adoption of external key manager system to Certify.:github: TBA🔵 PlannedMoved to 2027
  • Enabling certify to adopt external key manager systems
P1Multi-lingual support for credential data (Enhancement).:github: TBA🔵 Planned
  • Support for other VC formats to incorporate in well-known
  • Support for other VC Formats with SVG Rendering
P1Credential Refreshing.:github: TBA🔵 PlannedMoved to 2027
  • Support to retire the old credential and issue the new credential
  • Support using refresh methods (credential status)
P1Support for wallet attestation client auth.:github: TBA🔵 PlannedMoved to 2027
P1Revocation of Credentials.:github: TBA🔵 Planned

Support for VC Formats:

  • SD-JWT
  • mDoc/mso
P1Presentation during Issuance for sd_jwt.:github: TBA🔵 Planned

Support for VC Formats:

  • SD-JWT
  • mDoc/mso
P1Support for VC Issuance in PDF format.:github: TBA🔵 PlannedEnabling certify to issue VC as PDF with signing
P1Pre-Auth Code for sd_jwt format.:github: 901🔵 Planned

Support for VC Formats:

  • SD-JWT
  • mDoc/mso
P2

Trust registry and verifiable data registry/

Support for keri protocol.

:github: TBA🔵 PlannedIntegrate with Gleif (keri protocol)
P2

Trust registry and verifiable data registry/

Support for dedi protocol.

:github: TBA🔵 PlannedIntegrate with DeDi
P2VC issuance with mutiple VC formats.:github: TBA🔵 PlannedMoved to 2027
  • SD-JWT as per W3C
  • Support for Data model 2.0
P2Multiple QR Codes embedded in VC.:github: TBA🔵 Planned

Support for VC Formats:

  • SD-JWT
  • mDoc/mso
P2BBS Support.:github: TBA🔵 Planned
P2Multi-proof support for single credentials. Inji Certify all have to be enhanced with multi-proof - ED, EC & BBS+.:github: TBA🔵 Planned
P2VC Generation: Create Credentials from the Request Payload.:github: TBA🔵 Planned
  • Enable creation of credentials from request payload by internal sub-systems that are authorized to call it (using W3C VC API)
  • Additionally, the signing key is stored + source data can be cached (Sunbird R).
  • This takes data + type + format as input
P3Subject Holder relationship VC.:github: TBA🔵 Planned

Indirectly holder holds VC not /only belongs to holder

Holder: a person who holds the VC but it either does not belong to the holder or sharing with another person (biometric owner is different)

use case :

  1. birth certificate of an infant
  2. Share marriage certificate
  3. Guiding elder person on usage of VC

Delegated Access Support for VC Issuance

P4VC multiple status List support.:github: TBA🔵 Planned
  • Support more than one status list per credentials such as support fot uspension along with revocation
GA Release.:github: TBA🔵 PlannedRelease of Certify with Stable version
P4Plug-ins for commonly used databases and data exchange.:github: TBA🔵 Planned
  • Reference implementation for other DB source in addition to PostgresSQL
  • Reference implementation to integrate with existing API
P4Allow bulk generation of onetime credentials.:github: TBA🔵 Planned
  1. Ability to generate multiple copies of the same credentials with different credential IDs and different keys are issued.
  2. Auto generation of credentials on a timely basis
P4Support for PDF Template and rendering (Credential Issuance).:github: TBA🔵 PlannedEnabling support for pdf-moustache for Issuer to allow VC to be issued in pdf format
P4Support for WebVH (Verified History).:github: TBA🔵 Planned
## Inji Verify
Vision By 2026, Inji Verify aims to become a universal, multilingual, and highly interoperable verification platform supporting all major credential formats including W3C JSON/JWT VCs, IETF JWT/SD-JWT, mDoc/mDL, MOSIP UIN VCs, and advanced revocation with multiple status lists backed by decentralized trust through KERI, DEDI, and global trust registries. It plans to deliver rich, branded verification outputs through SVG and PDF templatising, multi-language rendering, and support for multiple QR formats. Verification experiences aims to be seamless across online, offline, and proximity-based scenarios with OpenID4VP and OpenIDVP same-device flows, BLE presentations, offline SDKs, and server-side ECC-R1 verification. Inji Verify plans to expand platform reach through native Android/iOS apps and broad framework-compatible SDKs, making it a secure, accessible, future-ready, and developer-friendly global standard for credential verification.
Priority 🗓️Feature 🛠️Details 📝Status 📊Release 📌
P1Ability to verify Claim 169 QR Code.:github: 1365🟢 Completedv0.17.0
P1OpenID4VP - Same device flows alongside Web wallets.:github: 1437🟢 Completedv0.18.0
P1Support Server Side VC Verification: ECC- R1.:github: 1017🟢 Completedv0.18.0
P1Ability to verify JSON (W3C) VC.:github: 1018🔵 Planned
P1Upgrade to OpenIDVP final version 1.0.:github: 1019🟢 Completedv1.0.0-alpha.1
P1W3C Data Model 2.0-based JWT VC.:github: 1020🔵 Planned
P1Multi language for SVG Template rendering.:github:1021🔵 Planned
P1OpenIDVP: Same Device Flow (via DC API).:github: 2092🟠 In-Progress
P2Offline Verification SDK.:github: 1022🔵 Planned
P2BLE based verifiable presentation.:github: 1023🔵 Planned
P2Multi-Lingual Support.:github: 1024🔵 Planned
P2BBS+ Support.:github: 1025🔵 Planned
P2VC Label translation with well known.:github: 1026🔵 Planned
P3Inji Verify SDK Support apart from React applications for Wider Framework Compatibility.:github: 1027🔵 Planned
P3Ability to verify mDoc and mDL.:github: 1028🔵 Planned
P3Support for philisys QR code.:github: 1029🔵 Planned
P3Revocation for SD-JWT and JWT.:github: 1030🔵 Planned
P3

Trust registry and verifiable data registry/

Support for:

  1. keri protocol
  2. dedi protocol
:github: 1031🔵 Planned
P4IETF JWT VC Support.:github: 1032🔵 Planned
P4Native App for Inji Verify - Android device.:github: 1033🔵 Planned
P4Native App for Inji Verify - iOS device:github: 1034🔵 Planned
P4Revocation for mDoc/ mDL.:github: 1035🔵 Planned
P4Multiple QR Codes embedded in VC in a single PDF.:github: 1036🔵 Planned
P4SVG Rendering for IETF based SD-JWT & JWT.:github: 1037🔵 Planned
P4PDF Template Support.:github: 1038🔵 Planned
P4VC multiple status List support.:github: 1039🔵 Planned
P4Support for WebVH (Verified History).:github: 1040🔵 Planned
*** **Acronyms and Legends**: :github: **TBA**: 'Github Issues Link - To Be Added' # Roadmap 2025 Here we present the product roadmap for the entire **Inji Stack** for the calendar year 2025. The **annual product cycle** for the Inji Stack begins in **January** and concludes in **December**. For detailed module-wise roadmaps, please refer to the following: * [Inj Wallet](https://docs.inji.io/readme/roadmap/roadmap-2025#inji-wallet) * [Inji Mobile](https://docs.inji.io/readme/roadmap/roadmap-2025#inji-mobile) * [Inji Web](https://docs.inji.io/readme/roadmap/roadmap-2025#inji-web) * [Inji Certify](https://docs.inji.io/readme/roadmap/roadmap-2025#inji-certify) * [Inji Verify](https://docs.inji.io/readme/roadmap/roadmap-2025#inji-verify) {% hint style="warning" %} **Prioritization**: Through this roadmap the startegic or adaptive prioritization, if there is, has been indicated as below: * Add \[ **➕** ]: Added new. * Strategic priortization \[ **↑** ] : Brought ahead in schedule. * Adaptive reschedule \[ **↓** ]: Is moved to approaching quarters. {% endhint %} ## Inji Wallet
Vision In 2025, Inji Wallet will continue to ensure compatibility with diverse ecosystems by supporting multiple credential formats, such as mDoc/mDL, SD-JWT, and JWT. The wallet will also incorporate privacy-preserving mechanisms such as BBS+, selective disclosure, and one-time credentials, empowering users to retain full control over their personal information. Additionally, the wallet will enable multi-user credential sharing, addressing family-based use-cases such as ration cards and property deeds, further enhancing its versatility and real-world applicability. The wallet’s roadmap includes critical features like [**OpenIDVP**](https://openid.net/specs/openid-4-verifiable-presentations-1_0-21.html#name-overview) enhancements for cross-device and same-device flows, Shamir’s secret sharing for secure key recovery, ECC K1 and R1 key support. By enabling the seamless integration of features like credential offer endpoints and pre-authorized code flows ([**OpenID4VCI**](https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0-ID1.html#name-pre-authorized-code-flow)), Inji Wallet will cater to real-world use cases with ease. The **mobile** and **web** interfaces of Inji Wallet will support high-performance operations, maintaining accessibility even in low-connectivity environments. With robust user login and profile management features, along with integration of play integrity on Android, the wallet will ensure a scalable, secure, and privacy-focused user experience. By 2025, Inji Wallet aims to be a reliable, standards-compliant digital wallet, empowering users to manage their credentials while fostering trusted data exchange and seamless interoperability within the verifiable credentials ecosystem.
### Inji Mobile
Quarter🗓️Feature 🛠️Details 📊Status 📝Release 📌Notes 📖
Q1iOS Keystore: RSA, ECC R1/K1, Ed25519 Key Generation SupportECC_Key_Support🟢 Completedv0.15.0
Q1OpenIDVP : Cross-Device FlowOpenID4VP🟢 Completedv0.15.0
Q1Support of mDL/mDoc CredentialsmDoc/mDL_Wallet-Support🟢 Completedv0.15.0
Q2

Cross-Device Enhancements for Credential Sharing

( OpenIDVP :Verifier Metadata Management)

Cross-device-flow_Enhancements🟢 Completedv0.16.0Moved to
Q2
Q2➕VC Verifier SDK (Kotlin): ECC K1 Verification SupportECC_Key_Support🟢 Completev0.17.0Added to Q2
Q2➕Sharing of mDL/mDoc via OpenIDVPmDoc/mDL_Wallet-Support🟢 Completev0.17.0Added to Q2
Q2➕Complaint to Draft 23 of OpenIDVP SpecDraft23_OpenIDVP🟢 Completev0.17.0Added to Q2
Q2➕WLA login through deep link in iOSDeeplink_login🟢 Completev0.17.0Added to Q2
Q2↑Same Device Flow: Multiple credential requests during the presentation (OpenIDVP)OpenIDVP_SameDevice_Flow🟢 Completev0.17.0Moved to Q2 to Q3
Q3OpenID4VCI Support for credential offer endpoint and pre-authorised code flowOpenIDVCIEnhancement🟢 Completev0.18.0
Q3↓Support for SD-JWT Credentials FormatSD_JWT🟢 Completev0.19.0Moved to Q3 from Q2
Q4↓W3C Data Model 2.0 & SVG Render MethodWalletRendering & svgTemplate🟢 Completev0.20.0Moved to Q4 from Q2
Q4➕Selective Disclosure via OpenIDVPSD_JWT🟢 Completev0.20.0Added to Q4
Q4↓Credential RevocationCredential_Revocation🟢 Completev0.21.0Moved to Q4 from Q3
2026↓Presentation During Issuancepresentation_during_issuanceMoved to 2026 & Beyondv0.22.0Q4 Moved to 2026
2026↓Support for Advanced Cryptographic Keys (ECC R1)ECC_Key_SupportMoved to 2026 & BeyondNA

Q4

Moved to 2026

2026↓Support for JWT Credentials FormatJWT_VC_SupportMoved to 2026 & BeyondNA

Q4

Moved to 2026

2026↓Wallet Login with Unified Key ManagementHolder LoginMoved to 2026 & BeyondNA

Q3

Moved to 2026

2026↓Profile Creation Using a Single CredentialUser_profileMoved to 2026 & BeyondNA

Q3

Moved to 2026

2026↓Secure Key Recovery with Shamir’s Secret SharingSharmir's-OpenStandard_ImplemMoved to 2026 & BeyondNA

Q3

Moved to 2026

2027↓Advanced Privacy Features with BBS+BBS+Moved to 2026 & BeyondNA

Q3

Moved to 2026

2027↓Android App Security with Play IntegrityApp integrityMoved to 2026 & BeyondNA

Q3

Moved to 2027

2027↓Multi-User Family CredentialsMulti-user_CredentialsMoved to 2026 & BeyondNA

Q4

Moved to 2027

2027↓One-Time Use Credentials for PrivacyOne-time_CredentialsMoved to 2026 & BeyondNA

Q4

Moved to 2027

2027↓

Secure Wallet Setup with Key Binding

(SIOP)

SIOPMoved to 2026 & BeyondNA

Q1

Moved to 2027

### Inji Web
Quarter 🗓️Feature 🛠️Details 📊Status 📝Release 📌Notes 📖
Q1Enabling VC Validity for Verification🟢 Completev0.11.0
Q1Enable RSA256 Signature Suites for Guest Login(without login)🟢 Completev0.11.0
Q2Enabling customisation of PDF Template🟢 Completev0.12.0
Q3+User Login with IDPUser Login🟢 Completev0.13.0Added to Q3
Q3+Enable RSA256 Signature Suites for Login Flow🟢 Completev0.13.0
Q3↓Enable Ed25519 2018 and 2020 Signature Suites for Login FlowED25519_Key-Support🟢 Completev0.13.0
Q3↓Enable ECC K1 Signature Suites for Login FlowECC_Key_Support(Web)🟢 Completev0.13.0
Q4↓SD-JWT Credential SupportSD JWT VC🟢 Completev0.14.0Moved to Q4 from Q3
Q4+Enable Ed25519 2018 and 2020 Signature Suites for Guest Login (Without Login)🟢 Completev0.14.0Added to Q4
Q4+Enable ECC K1 Signature Suites for Guest Login (Without Login)🟢 Completev0.14.0Added to Q4
Q4+OpenIDVP Support for JSON-LD(W3C) VCs🟢 Completev0.15.0Added to Q4
2026↓Credential RevocationVC RevocationMoved to 2026 & Beyondv0.16.0

Q4

Moved to 2026

2026↓W3C Data Model 2.0 & SVG Render MethodVCRenderingMoved to 2026 & Beyondv0.16.0

Q4

Moved to 2026

2026↓OpenIDVP Support for SD-JWTSD JWT VCMoved to 2026 & BeyondNA

Q4

Moved to 2026

2026↓Support for Advanced Cryptographic Keys (ECC R1)SIOP_Key_BindingMoved to 2026 & BeyondNA

Q4

Moved to 2026

2026↓Secure Key Recovery Using Shamir’s Secret SharingSharmir's-OpenStandard_ImplemMoved to 2026 & BeyondNA

Q2

Moved to 2026

2026↓Support for mDoc/mDL CredentialsVC FormatsMoved to 2026 & BeyondNA

Q2

Moved to 2026

2026↓CBOR Credential Format SupportCBOR_VC_SupportMoved to 2026 & BeyondNA

Q2

Moved to 2026

2026↓OpenID4VCI Support for credential offer endpoint and pre-authorised code flowOpenID4VCI EnhancementsMoved to 2026 & BeyondNA

Q3

Moved to 2026

2026↓Advanced Privacy with BBS+ SupportBBS+_SupportMoved to 2026 & BeyondNA

Q3

Moved to 2026

2026↓Support for JWT CredentialsECC_Key_Support(Web)Moved to 2026 & BeyondNA

Q3

Moved to 2026

2026↓Unified Key Management for Web & MobileKey_Management_WalletMoved to 2026 & BeyondNA

Q1

Moved to 2026

2027↓One-Time-Use Credentials for PrivacyOne-time_CredentialsMoved to 2026 & BeyondNA

Q3

Moved to 2027

2027↓Multi-User Family CredentialsMulti-user_CredentialsMoved to 2026 & BeyondNA

Q3

Moved to 2027

## Inji Certify
Vision The goal of **Inji Certify** for the rear 2025 is to provide a **comprehensive and user-centric platform for issuing, managing, and verifying credentials**, tailored to meet the diverse needs of individuals, organizations, and issuers. With support for multiple credential formats (e.g., SD-JWT, mDoc/mDL), advanced cryptographic standards (ECC, BBS), and privacy-preserving mechanisms, the platform ensures secure and flexible credential handling. By enabling features like multi-issuer onboarding, deferred issuance, subject-holder relationship management, and one-click authorization during issuance, Inji Certify addresses real-world scenarios such as sharing family credentials, automating bulk credential generation, and simplifying issuer interactions. The integration of offline capabilities (e.g., printable QR-embedded credentials) and scalable architecture ensures accessibility, even in low-connectivity environments, while maintaining performance benchmarks of up to 1 million credentials per day. Inji Certify’s vision is to foster **trust and interoperability** in the digital identity ecosystem, empowering users with control over their credentials while providing issuers with a reliable and standards-compliant platform.
Quarter 🗓️Feature 🛠️Details 📊Status 📝Release 📌Notes 📖
Q1Local deployment using docker composeLocal_Deplyment🟢 Completed0.10.1
Q1Support for VC data model 2.0Data_Model_2.0🟢 Completed0.10.1
Q1Implementation of Data Provider PluginData_Provider_plugin🟢 Completed0.10.1
Q1ED25519 (2018 & 2020) VC SigningED25519_Key_Support🟢 Completed0.10.1
Q2Support for ECC K1ECC_K1_Key_Support🟢 Completed0.11.0Moved to Q2 from Q1
Q2+Support for ED25519 (2018 & 2020)ED25519_Key_Support🟢 Completed0.11.0Added to Q1
Q2+OAuth Support with external authenticationOAuth_Support🟢 Completed0.11.0Added to Q1
Q3↓Add New Credential Type to IssuerAdd_New_VC🟢 Completed0.12.0Moved to Q3 from Q2
Q3↓Support for ECC R1ECC_R1_Key_Support🟢 Completed0.12.0Moved to Q3 from Q1
Q3+Support for Data IntegrityData_Integrity🟢 Completed0.12.0Added to Q3
Q3↓Credential Revocation Mechanismrevocation_mechanism🟢 Completed0.12.0 & 0.13.0Moved to Q3 from Q1
Q3↓Credential Formats Support for - SD JWTSDJWT_VC_Format_Support🟢 Completed0.12.0 & 0.13.0Moved to Q3 from Q1
Q3↓Credential Formats Support for -mDocmDoc_Format_Support🟢 Completed0.13.0Moved to Q3 from Q2
Q3↓Pre-authorized Code Flowpre-authorized-code-flowMoved to 2026 & Beyond0.14.0Moved to Q2 from Q1
Q3↓Presentation during issuance of Credentialpresentation_during_issuanceMoved to 2026 & Beyond0.14.0Moved to Q3 from Q2
Q3+Claim 169 Support with QR Code GenerationQRCode_GenerationMoved to 2026 & Beyond0.14.0Added to Q3
Q3↓Anon Credentialanon_credDeprioritisedTBDMoved to Q3 from Q2
Q3VC Generation: Create Credentials from the Request PayloadW3C_VC_Issaunce_APIMoved to 2026 & BeyondTBD
Q3Multi-issuers: Onboarding of multiple issuersmulti-issuersMoved to 2026 & BeyondTBD
Q3Subject Holder relationship for VCsubject_holder_relationshipMoved to 2026 & BeyondTBD
Q3Allow bulk generation of onetime credentialsbulk_batch_issuanceMoved to 2026 & BeyondTBD
Q4Deferred Credential Endpointdeferred_credentialDeprioritisedTBD
Q4Multi-User Credentialsmulti_user_credDeprioritisedTBD
Q4Issue a physical credential (PDF / Printable)presentation-based-pluginDeprioritisedTBD
## Inji Verify
Vision Our **vision** for 2025 is to position Inji Verify as the go-to tool for seamless and secure credential verification. We aim to deliver easily configurable UI components for third-party verifier portals, tailored to meet the diverse needs of organizations across the globe. With support for multiple credential formats (SD-JWT, mDoc/mDL, W3C) and advanced cryptographic standards (ECC), Inji Verify ensures flexible and secure credential handling. Inji Verify fosters trust and interoperability in the digital identity ecosystem. By introducing features like multi-proof capabilities, QR Based Verifiable Presentation in Same Device, SVG Rendering post VC verification, able to identify revoked credentials during verification, able to support credential correction, verification of documents with multiple QR codes, BLE Based verifiable presentation - Inji Verify will redefine user experience and reliability. With a focus on performance , enhanced design for an intuitive look and feel, and adherence to global standards (Data Model 1.1/2.0), the GA release will set new benchmarks for stability, usability, and excellence in digital verification.
Quarter 🗓️Feature 🛠️Details 📊Status 📝Release 📌
Q1OpenIDVP: Cross Device Flow (QR code based Verifiable Presentation)OpenIDVP_CrossDeviceFlow🟢 Completed0.11.0, 0.11.1, 0.12.3
Q1Upgrades in OpenID4VP - Draft 21 specificationDraft21_OpenIDVP_adoption🟢 Completed0.11.0
Q1Inji Verify SDK: OpenID4VP- VP Verification component (cross device flow) and publish as an NPM moduleInjiVerify_SDK🟢 Completed0.12.3
Q1Migration of Inji Verify backend from H2 in memory DB to PostgreSQL DBInjiVerify_Backend_Migration🟢 Completed0.12.3
Q2Inji Verify SDK: Scan/ Upload Component and publish as an NPM moduleInjiVerify_SDK🟢 Completed0.13.0
Q2Server Setup for VC and VP Proof Verification in vc-verifier libraryVC_VP_Proof_Verification🟢 Completed0.13.0
Q3OpenIDVP Same Device Flow (via deeplink): Integrate to Inji Verify SDKOpenIDVP_Same_Device_Flow🟢 Completed0.14.0
Q3OpenID4VP Draft 23: Implement DID-based client_id SchemeOpenIDVP_Draft23_Adoption🟢 Completed0.14.0
Q3OpenID4VP: Authorization Request via request_uri for did client idOpenIDVP_Auth_Request🟢 Completed0.14.0
Q3OpenIDVP: Same Device Flow in Inji Verify SDK (mobile device)OpenIDVP: Same Device🟢 Completed0.14.0
Q4Ability to verify SD-JWT VCSD-JWT Verification🟢 Completed0.15.0
Q4Templatizing post-VC verification (SVG Rendering)SVG_Rendering🟢 Completed0.16.0
Q4Revoked CredentialsCredential_Revocation🟢 Completed0.16.0
Q4Multi lingual supportMulti lingual support🟢 Completed0.16.0
Q4MOSIP UIN VC VerificationMOSIP UIN VC🟢 Completed0.16.0
2026↓Support Server Side VC Verification: ECC- K1 and R1ECC-K1_R1_SupportMoved to 2026 & beyondTBD
2026↓Inji Verify SDK Support apart from React applications for Wider Framework CompatibilityInjiVerify_SDKMoved to 2026 & beyondTBD
2026↓Claim 169 QR CodeClaim_169_QRCodeMoved to 2026 & beyondTBD
2026↓Verify SD- JWT (W3C) VCSD_JWT_SupportMoved to 2026 & beyondTBD
2026↓Verify mDoc and mDLmDoc_mDL_SupportMoved to 2026 & beyondTBD
2026↓OpenID4VP - Cross device and same device flows alongside Web walletsOpenID4VP - Same device for Web WalletMoved to 2026 & beyondTBD
2026↓Support for Country QR code - CWT FormatCountry_QR_CodeMoved to 2026 & beyondTBD
2026↓Multi-language Support for VC during verificationMulti_Language_SupportMoved to 2026 & beyondTBD
2026↓Verify document(pdf) with multiple QR CodesMultiple_QR_VerificationMoved to 2026 & beyondTBD
2026↓Support for multi proof: Single credential should support multiple proofsOffline_SDK_VerificationMoved to 2026 & beyondTBD
2026↓GA ReleaseInjiVerify_LTS_B1Moved to 2026 & beyondTBD
2026↓Credential CorrectionCredential_CorrectionMoved to 2026 & beyondTBD
2026↓Offline Verification SDKOffline_Verification_SDKMoved to 2026 & beyondTBD
2026↓BLE based verifiable presentationInjiVerify_BLE_VerificationMoved to 2026 & beyondTBD
# Roadmap 2024 ## Inji Wallet ### Inji Mobile Q1: Jan24 - Mar24 Q2: Apr24 - Jun24 Q3: Jul24 - Sep24 Q4: Oct24 - Dec24 | **Quarter** | **Feature** | **Status** | **Feature Details** | **Release Details** | | ----------- | ------------------------------------------------------------------------------------------------------------------ | ---------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Q1-Q4 | Threat modelling. | Deprioritised | [Threat Modeling](https://mosip.atlassian.net/issues/?jql=project%3Dinjimob%20and%20Feature%20%3D%20Security_enhancements%20and%20labels%20in%20%28ThreatModelling%29) | | | Q1 | Abstract INJI features (Tuvali, Secure-keystore) in to SDK/NPM libraries | 🟢 Completed | [SDK](https://mosip.atlassian.net/issues/?jql=labels%20%3D%20Milestone2023%20AND%20Feature%20%3D%20SDK) | [vDP2](https://docs.mosip.io/inji/versions/version-inji-dp2) | | Q1 | Sunbird RC - Issuer integration | 🟢 Completed | [Sunbird-Integration](https://mosip.atlassian.net/issues/?filter=10698\&jql=project%20%3D%20INJI%20AND%20%22Feature%5BLabels%5D%22%20%3D%20Sunbird_Integration) |

v0.11.0 (Mimoto)

v0.11.0-Inji

| | Q1 | User data backup | 🟢 Completed | [Data Backup](https://mosip.atlassian.net/issues/?filter=10698\&jql=project%20%3D%20INJI%20AND%20Feature%20%3D%20UserDataBackup) | [v0.11.0-Inji](https://docs.mosip.io/inji/inji-wallet/versions/version-0.11.0-inji) | | Q1-Q2 | INJI new UI - Gendermag (P1, P2, P3) | 🟢 Completed | [GenderMag](https://mosip.atlassian.net/issues/?jql=project%20=%20inji%20AND%20issuetype%20in%20\(story,%20task,%20bug\)%20AND%20%22Feature%5BLabels%5D%22%20in%20\(GenderMag\)%20order%20by%20created%20DESC) |

v0.11.0-Inji


v0.12.0

| | Q2 | Different Views of Cards | 🟢 Completed | [UXModification](https://mosip.atlassian.net/issues/?jql=project%20=%20inji%20AND%20issuetype%20in%20\(story,%20task,%20bug\)%20AND%20%22Feature%5BLabels%5D%22%20in%20\(UXModification\)%20order%20by%20created%20DESC) | [v0.12.0](https://docs.mosip.io/inji/inji-mobile-wallet/versions/version-0.12.0) | | Q2 | VC Sharing Flow Optimisation | 🟢 Completed | | | | Q2 | Credential Type Selection | 🟢 Completed | [Credential Type Selection](https://mosip.atlassian.net/issues/?jql=project%3D%22Inji%20Mobile%22%20and%20labels%20in%20%28CredentialTypeSelection%29%20order%20by%20created%20DESC) | | | Q2 | VC Verification | 🟢 Completed | [VC Verification](https://mosip.atlassian.net/issues/?jql=project%3D%22Inji%20Mobile%22%20and%20labels%20in%20%28%22VCVerification%22%29) | | | Q2 | QR Code Generation (PixelPass) | 🟢 Completed | [QR Code Generation](https://mosip.atlassian.net/issues/?jql=project%20%3D%20injimob%20and%20%22Feature%5BLabels%5D%22%20in%20%28QRCodeGeneration%29%20order%20by%20created%20DESC) | | | Q3 |

Native artefacts:

  • inji-vci-client
  • Secure keystore
  • Tuvali
  • PixelPass
| 🟢 Completed | [Libraries](https://mosip.atlassian.net/issues/?jql=project%3D%22Inji%20Mobile%22%20and%20labels%20in%20%28library%29%20order%20by%20created%20DESC) | [v0.13.0](https://docs.mosip.io/inji/inji-mobile-wallet/versions/version-0.13.0) | | Q3 | Ease of Deployment | 🟢 Completed | [DockerCompose](https://mosip.atlassian.net/issues/?jql=project%3D%22Inji%20Mobile%22%20and%20summary%20~%20%22docker%20compose%22%20and%20type%20in%20%28story%29%20order%20by%20created%20DESC) | | | Q3 | Inji Certify Integration | 🟢 Completed | [Certify Integration](https://mosip.atlassian.net/issues/?jql=project%20%3D%20injimob%20and%20summary%20~%20certify%20order%20by%20created%20DESC) | v0.14.0 | | Q3 | Draft 13 changes of OpenID4VCI spec | 🟢 Completed | [Draft 13](https://mosip.atlassian.net/issues/?jql=project%3D%22Inji%20Mobile%22%20and%20labels%20%3D%20%22Draft13_OpenID4VCI%22) | v0.14.0 | | Q3 | Java upgrade to 21 | 🟢 Completed | [Java Upgrade](https://mosip.atlassian.net/browse/INJIMOB-857) | v0.14.0\_Mimoto: | | Q4 | OpenID4VP | 🟢 Completed | [OpenID4VP](https://mosip.atlassian.net/issues/?jql=project%20%3D%20INJI%20AND%20%22Feature%5BLabels%5D%22%20in%20\(OpenID4VP\)%20ORDER%20BY%20created%20DESC) | v0.15.0 | | Q4 | VC render spec based wallet rendering | Moved to 2025 | [Wallet Rendering](https://mosip.atlassian.net/issues/?jql=project%20%3D%20injimob%20and%20%22Feature%5BLabels%5D%22%20in%20%28WalletRendering%29%20order%20by%20created%20DESC) | NA | | Q4 | OpenID4VP for BLE: Implementation of non QR based sharing as per OpenID for BLE specification | Deprioritised | [OpenID4BLE](https://mosip.atlassian.net/issues/?filter=11234\&jql=project%20%3D%20INJI%20AND%20%22Feature%5BLabels%5D%22%20in%20\(OpenID4BLE\)%20ORDER%20BY%20created%20DESC) | NA | | Q4 | Support for different VC formats and proof types | Moved to 2025 | [VC Format & Proof types](https://mosip.atlassian.net/issues/?jql=project%20%3D%20injimob%20and%20%22Feature%5BLabels%5D%22%20in%20%28VCFormat%2C%20VCProof%29%20order%20by%20created%20DESC) | NA | | Q4 | Data Model 2.0 | Moved to 2025 | [DataModel2.0](https://mosip.atlassian.net/issues/?jql=project%3D%22Inji%20Mobile%22%20and%20%22Feature%5BLabels%5D%22%20in%20%28DataModel2.0%29%20order%20by%20created%20DESC) | NA | | Q4 | Performance Testing | Deprioritised | [Performance Testing](https://mosip.atlassian.net/issues/?jql=project%3D%22Inji%20Mobile%22%20and%20labels%20in%20%28Performance_Testing%29%20order%20by%20created%20DESC) | NA | | Q4 | Security Testing | Moved to 2025 | [Security Testing](https://mosip.atlassian.net/issues/?jql=project%3D%22Inji%20Mobile%22%20and%20labels%20in%20%28Security%29%20order%20by%20created%20DESC) | NA | | Q4 | OpenID4VCI enhancements | Moved to 2025 | [OpenID4VCIEnhancements](https://mosip.atlassian.net/issues/?jql=project%20%3D%20injimob%20and%20%22Feature%5BLabels%5D%22%20in%20%28OpenIDVCIEnhancement%29%20order%20by%20created%20DESC) | NA | | Q4 | Wallet Login | Moved to 2026 & Beyond | [Holder Login](https://mosip.atlassian.net/issues/?jql=project%20%3D%20injimob%20and%20%22Feature%5BLabels%5D%22%20in%20%28WalletLogin%29%20order%20by%20created%20DESC) | NA | | Q4 | BBS+ support | Moved to 2026 & Beyond | [BBS+](https://mosip.atlassian.net/issues/?jql=project%3D%22Inji%20Mobile%22%20and%20%22Feature%5BLabels%5D%22%20in%20%28%22BBS%2B%22%29%20order%20by%20created%20DESC) | NA | ### Inji Web Q1: Jan24 - Mar24 Q2: Apr24 - Jun24 Q3: Jul24 - Sep24 Q4: Oct24 - Dec24 | **Quarter** | **Feature** | **Status** | **Feature Details** | **Release Details** | | ----------- | --------------------------------------------------------------------------------------------------------------------- | ---------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------- | | Q2 |
  1. Fetch & download credentials in PDF format
  2. Issuer and credential type selection
| 🟢 Completed | [Fetch & Download](https://mosip.atlassian.net/issues/?jql=project%3D%22Inji%20Web%22%20and%20labels%20in%20%28%22Fetch%26Download%22%29%20and%20type%20in%20%28Story%29%20order%20by%20created%20DESC) | [v0.8.0](https://docs.mosip.io/inji/inji-web/inji-web/version-0.8.0) | | Q2 | Localization | 🟢 Completed | [Localization](https://mosip.atlassian.net/issues/?jql=project%3D%22Inji%20Web%22%20and%20labels%20in%20%28localization%29%20order%20by%20created%20DESC) | [v0.9.0](https://docs.mosip.io/inji/inji-web/inji-web/version-0.9.0) | | Q2 | Responsive View | 🟢 Completed | [Responsive UI](https://mosip.atlassian.net/issues/?jql=project%3D%22Inji%20Web%22%20and%20labels%20in%20%28responsiveUI%29%20order%20by%20created%20DESC) | [v0.9.0](https://docs.mosip.io/inji/inji-web/inji-web/version-0.9.0) | | Q2 | Theme customization | 🟢 Completed | [Theme Customization](https://mosip.atlassian.net/issues/?jql=project%3D%22Inji%20Web%22%20and%20labels%20in%20%28ThemeCustomization%29%20order%20by%20created%20DESC) | [v0.9.0](https://docs.mosip.io/inji/inji-web/inji-web/version-0.9.0) | | Q2 |

Tech Upgrades:

  1. Movement from Material UI to Tailwind
  2. Conversion of JS to TS
| 🟢 Completed | [Tech Upgrade](https://mosip.atlassian.net/issues/?jql=project%3D%22Inji%20Web%22%20and%20%22Feature%5BLabels%5D%22%20in%20%28TechUpgrade%29) | [v0.9.0](https://docs.mosip.io/inji/inji-web/inji-web/version-0.9.0) | | Q2 | QR Code in PDF | 🟢 Completed | [QR Code](https://mosip.atlassian.net/issues/?jql=project%3D%22Inji%20Web%22%20and%20%22Feature%5BLabels%5D%22%20in%20%28QRCodeGeneration%29%20order%20by%20created%20DESC) | v0.10.0 | | Q2 | Online Sharing | 🟢 Completed | [Online Share as a VP](https://mosip.atlassian.net/issues/?jql=project%3D%22Inji%20Web%22%20and%20labels%20in%20%28openid4vp%29%20order%20by%20created%20DESC) | v0.10.0 | | Q3 | Secure time bound storage | 🟢 Completed | [Time Bound storage](https://mosip.atlassian.net/issues/?jql=project%3D%22Inji%20Web%22%20and%20labels%20in%20%28SecureStorage%29%20order%20by%20created%20DESC) | v1.0.0 | | Q3 | Performance Testing | Moved to 2025 | [Performance](https://mosip.atlassian.net/issues/?jql=project%3D%22Inji%20Web%22%20and%20labels%20in%20%28Performance_Testing%29%20order%20by%20created%20DESC) | NA | | Q3 | Security Testing | Moved to 2025 | [Security](https://mosip.atlassian.net/issues/?jql=project%3D%22Inji%20Web%22%20and%20labels%20in%20%28Security%29%20order%20by%20created%20DESC) | NA | | Q3 |

Web UI enhancements:

  • Home Page
  • svg template in PDF
| Moved to 2025 | [UIEnhancements](https://mosip.atlassian.net/issues/?jql=project%3D%22Inji%20Web%22%20and%20labels%20in%20%28UIEnhancements%29%20order%20by%20created%20DESC) | NA | | Q4 | User login, VC management, profile management (profile menu) | Moved to 2025 | [User Login](https://mosip.atlassian.net/issues/?jql=project%3D%22Inji%20Web%22%20and%20labels%20in%20%28userlogin%29%20order%20by%20created%20DESC) | NA | | Q4 | VC Validation & Verification | Moved to 2025 | [VC Verification](https://mosip.atlassian.net/issues/?jql=project%3D%22Inji%20Web%22%20and%20%22Feature%5BLabels%5D%22%20in%20%28VCVerification%29%20order%20by%20created%20DESC) | NA | | Q4 | OpenID4VCI enhancements | Moved to 2025 | [OpenID4VCI Enhancements](https://mosip.atlassian.net/issues/?jql=project%3D%22Inji%20Web%22%20and%20labels%20in%20%28OpenID4VCI%29%20order%20by%20created%20DESC) | NA | | Q4 | Categorization of issuers | Moved to 2026 & Beyond | [Categorization](https://mosip.atlassian.net/issues/?jql=project%3D%22Inji%20Web%22%20and%20labels%20in%20%28categorization%29%20order%20by%20created%20DESC) | NA | | Q4 | mDoc/mDL & CBOR VC download | Moved to 2026 & Beyond | [VC Formats](https://mosip.atlassian.net/issues/?jql=project%3D%22Inji%20Web%22%20and%20labels%20in%20%28VCFormat%29%20order%20by%20created%20DESC) | NA | ## Inji-Certify Q1: Jan24 - Mar24 Q2: Apr24 - Jun24 Q3: Jul24 - Sep24 Q4: Oct24 - Dec24
QuarterFeatureStatusFeature DetailsRelease Details
Q2

Easy deployment of Inji Certify v0.8

  • Docker compose for Sunbird and eSignet for Verifiable Credential Issuance
  • Helm charts for Sunbird and eSignet.
Completedeasy_deployment_certify_v0v0.8.0
Q2

Inji Certify - Base code v0.9

  • Publish as an independent module (VCI + C)
  • VCI segregation from eSignet and moving to Inji Certify.

  • Plugin Support :

    • MOSIP Identity Plugin
    • Sunbird Plugin
    • Mock Identity Plugin
  • Implementors Draft 13 OpenIDVCI
Completedinji_certify_rel_0.9.0v0.9.0
Q3Movement to Data Model 2.0CompletedData_model_2.0v0.10.0
Q3

OpenID for Verifiable Credential Issuance - draft 13 Spec

  • Pre-Authorized Code Flow
  • Credential Offer End Point
Completedpre-authorised_code_flow+credv0.10.0
Q3

VC Generation: Create Credentials from the Request Payload

  • W3C VC Issuance API
Moved to 2025W3C_VC_Issaunce_APIv0.10.0
Q3Simplify the process of onboarding an issuer for a single entityMoved to 2025issuer_onboardingv0.11.0
Q3Multi-tenancy: Onboarding of multiple issuersMoved to 2025Multi-tenancyv0.11.0
Q3

Persistent store for credentials

  • Pre-generated credentials
  • Credentials Registry (Hosted Infra)
moved to 2025presistent_store_credentialsv0.11.0
Q4

Issue a physical credential (PDF / Printable)

  • Support PDF or other formats of presentation based on plugins - PDF, PCF, PKPASS
Moved to 2025presentation_based_pluginv0.11.0
Q4Vault Integration - Key manager supportMoved to 2025vault_key_manager_supportv0.12.0
Q4Vault - Key managementMoved to 2025vault_key_managementv0.12.0
Q4Revocation MechanismMoved to 2025revocation_mechanismv0.12.0
Q4

Discovery and Metadata

  • DNS based Well Known specifications for publishing PK, Schema, credential types and other meta data (Proposed by MOSIP and included in standards)
Moved to 2025Discovery_metadata_APIsv0.12.0
Q4

Allow Bulk/Batch Issuance

  • Issue certificates from an existing database
Moved to 2025bulk_batch_issuancev0.12.0
Q4

Deferred Credential Endpoint

  • OpenIDVCI - Draft 13
Moved to 2025Deferredv0.12.0
Q4Inji Certify - Beta 1 - LTSDeprioritisedv1.0
Q1-Q4

Extend Credentials

  • Ability to issue extension on existing credential
Moved to 2025extend_credentialsDepriortized
Q1-Q4

Credential Correction

  • Support to retire the old credential and issue the new credential
Moved to 2025credential_correctionDepriortized
Q1-Q4Credential Formats Support - Selective Disclosure - Support SD JWTMoved to 2025SD-JWTDepriortized
Q1-Q4[Credential Formats Support - Support mDocsMoved to 2025mDoc_certifyDepriortized
Q1-Q4Business models (central, third-party SaaS, self-hosted)Moved to 2025SAAS_Self-hostedDepriortized
## Inji -Verify Q1: Jan24 - Mar24 Q2: Apr24 - Jun24 Q3: Jul24 - Sep24 Q4: Oct24 - Dec24
QuarterFeatureStatusFeature DetailsRelease Details
Q2Web-based VC Verification functionalityCompletedvc_verificationv0.8.0
Q2UI/UX Enhancements based on GenderMagCompletedGenderMag_UI/UXv0.9.0
Q2Mobile Responsive Version - Upload and Scan featureCompletedmobile_responsivev0.9.0
Q2Material UI to TailwindCompletedcode_refactoringv0.9.0
Q2Bug FixesCompletedv0.9.0
Q3Request Credential - OpenIDVP - OVP FlowCompletedOpenIDVP_OVP_Flowv0.10.0
Q3Docker ComposeCompleteddocker_composev0.10.0
Q4Support for Country QR code - CWT FormatCompletedcountry_qr_codev0.11.0
Q4Verification SDKCompletedVC_Verifier_SDKv0.11.0
Q4Displaying Issuer Details post validation on UICompletedDIF_issuer_details_displayv0.11.0
Q4Multi-lingual UI Support - LocalizationCompletedmulti-lingualv0.11.0
2025Templatizing post-VC verification on Inji Verify(Render)Moved to 2025VC_renderDepritoritized
2025

Receive Credentials

(QR-based Verifiable Presentation)

Moved to 2025VP_RequestDepritoritized
2025VP requestor SDKMoved to 2025VP_requestor_SDKDepritoritized
2025Consume Data from credentialMoved to 2025consume_credentials_dataDepritoritized
2025Production Ready - Inji Verify - LTS Release 1.0.0Moved to 2025Injiverify_LTS_B1Depritoritized
2025BLE based verifiable presentationMoved to 2025InjiVerify_BLE_VerificationDepritoritized
2025Credential CorrectionMoved to 2025Credential_correctionDepritoritized
2025Revoked CredentialsMoved to 2025credential_revocationDepritoritized
2025VC Reciever SDKMoved to 2025VC_receiver_SDKDepritoritized
2025Upload document(pdf) with multiple QR CodesMoved to 2025multiple_QR_VerificationDepritoritized
2025Verify mDoc and mDLMoved to 2025mDoc_mDLDepritoritized
2025Mobile App (Login with Inbox & Logout)Moved to 2025login_functionalityDepritoritized
2025Offline Verification SDKMoved to 2025offline_verification_SDKDepritoritized
# 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. ### 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: We use [Jira](https://mosip.atlassian.net/issues/?jql=labels%20%3D%20%22BLE%22) to track the work associated with the project (account required). That is where issues open for community contribution can be found. ### Pull Request Review Process The process to contribute the code is present [here](https://github.com/mosip/tuvali/blob/master/CONTRIBUTING.md). Once code is submitted, it is reviewed through the following process: * At least two members should have reviewed the submitted contribution for the pull request to be accepted. The maintainers may request for more reviews of the code from other relevant members. * If the members deem the submitted code to be critical to overall product development, they can seek the inputs of the relevant product owners for the review process. * The maintainers review the two (or more) sets of comments received from the tech leads and the submitted code before taking a decision regarding committing the code to the appropriate branch. * The decision by the maintainer is communicated to the contributor via Jira as well as Pull Request. * In exceptional cases such as an emergency or an urgent requirement or a very trivial but time-sensitive correction, a maintainer may - at their discretion - choose to directly review the submitted pull request and take a decision on the commit. ### Release process Project Lead initiates the release process. The process can be found [here](https://docs.mosip.io/1.2.0/community/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. # Community # Calendar # 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](/readme/contribution/code-contribution). To engage with us on our community forum, visit [here](https://community.mosip.io/). # Code Contribution ## Overview The recommended Github workflow here is for developers to submit code and documentation contributions to Inji open-source repositories. ### Repositories {% embed url="" %} ## Setup your development machine 1. Fork the repository. 2. Clone the fork to your local machine. E.g.: ``` $ git clone https://github.com//inji.git ``` 3. Set the upstream project as the original from where you forked. E.g.: ``` $ cd inji $ git remote add upstream https://github.com/mosip/inji.git ``` 4. Make sure you never directly push upstream. ``` $ git remote set-url --push upstream no_push ``` 5. Confirm the origin and upstream. ``` $ git remote -v ``` This should display origin and upstream as below: ``` origin https://github.com//inji.git (fetch) origin https://github.com//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/ ``` {% hint style="info" %} You will get a warning from git. Don't worry, our next step will take care of this warning. {% endhint %} 4\. Create a new issue branch with the name of the issue. ``` $ git switch -c issue- ``` 5\. Make sure you are up-to-date with the upstream repo. ``` $ git pull upstream ``` {% hint style="info" %} You should do this quite often to ensure you are up to date. {% endhint %} 6\. Now feel free to make the change in the code or documentation. Reach out to [our community](https://community.mosip.io) for any queries. Once done with the work, commit your changes by referring to the Issue ID in the commit message. Eg: ``` $ 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 ``` 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- ``` 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. {% hint style="info" %} Most often it's the same branch in the upstream (as in Step 3). {% endhint %} 11\. Make sure the automatic tests/checks on GitHub for your pull request pass. 12\. Reviewers shall review the pull request. Reach out to the [community](https://community.mosip.io) for a faster response. # 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 * 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 Instances of abusive, harassing, or otherwise, unacceptable behaviour may be reported to the community leaders responsible for enforcement at [MOSIP](mailto:info@mosip.io). 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. ## 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 This Code of Conduct is adapted from the [Contributor Covenant](https://www.contributor-covenant.org), version 2.1, available at . Community Impact Guidelines were inspired by [Mozilla's code of conduct enforcement ladder](https://github.com/mozilla/diversity). 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** 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:
Sl NoProblem statementSolutionJira number
1

The term “scan” can be ambiguous because scanning a QR code within an app might result in a money transfer from a bank account. This perception could be influenced by cultural factors. Abi, instead of directly clicking on the “Scan” option, prefers to select her card and then look for a “Share” option. Unless external assistance is available, Abi will avoid using the “Scan” feature.

Without external assistance, unless there are instructions visibly posted on the wall, she might find it challenging to comprehend whether she needs to select the “scan” option.

The Scan Button in the Navigation Bar can now be referred to as “Share”.

INJIMOB-725

INJIMOB-702


2

On the "Retrieve your ID" screen, instead of using "VID auto population," consider using "Download ID." This change will help avoid confusion for Abi, who might expect an explanation of what VID / UIN IDs are.

On the "Home with cards view," Abi might wonder why her card displays "Activation Pending," while the other card shows Activated for online login".

In the FAQ or Help section, provide information about the various types of IDs, their locations, and instructions on how to download them using different ID methods.

Provide additional information related to "Activation Pending," and ensure clear icon translations for "Activation Done" versus "Activation Pending".

INJIMOB-698
3
  1. When the user clicks on the "Add" button, the options "Generate your card" or "Retrieve your ID" might be confusing.
  2. The description should also include an explanation of why the verification process is necessary.
  3. When the user glances at the screen, the "AID" is not immediately evident.
  1. Update main screen name to "Download your card".
  2. Update main screen description to "Select ID type and enter the MOSIP provided UIN or VID you wish to download." (Also, with a reference to upcoming OTP screen).
  3. Enhance the text to provide a heads up about the upcoming step of OTP verification, so that user is prepared to receive and enter the OTP.
  4. Update bottom line text to "Don't have UIN / VID? Get it now using your AID."
INJIMOB-697
As part of Phase2, below P1, P2 items are fixed in the v0.12.0 release of Inji Wallet:
Sl NoProblem StatementSolutionJira number
1

Screen name: Retrieve your UIN/VID on clicking Get it now using your AID link


It is confusing for Abi as she has to walk through a lot of steps to get her card. Though it is mentioned as AID, she would be happy but may / may not move forward as it is going to get UIN but not a card.

Update screen name to "Get your UIN/VID." instead of Retrieve your UIN/VIDINJIMOB-843
2

The Resend Code is unclear in the OTP screen.

  1. The Resend Code Text can be more descriptive. “Resend OTP” would be more clear than “Resend code”
  2. The Resend code is confusing as to whether it is clickable or not.
Rename “Resend code” as “Resend OTP”INJIMOB-843
3Though Tim is tech savvy, Tim will be sort of puzzled why the app needs location access as well despite a lot of other permissions provided. Tim will be unhappy and question why they are required to provide location access in order to scan a QR code.

Description can be more indicative of the specific purpose of seeking location access.


INJIMOB-785
4
  1. Abi is not so familiar with tech, when the app says share a selfie, they might not know, face auth using her photo, is going in the background. she might think it will break her privacy.
  2. Abi might be confused, as she cannot understand what is the next action to be done, from the instruction. it does not mention whether she has to click on the shutter button or it will take a picture automatically although she would perform the subgoal. Will it automatically click the selfie or do Abi need to click on the button?

For problem statement 1:

  1. Provide assurance wrt Privacy
  2. Terminology update: Face Authentication to Face Verification
  3. Acquaint user with text about "Share with selfie" feature, informing user about face authentication - Through FAQs
  4. Avoid usage of slang jargons like selfie → need confirmation from the product team on the alternative <Sasi>: Let us retain the word as that is more relatable to all.

For problem statement 2:

Enhance text: In the Face Verification screen, the text should be enhanced as "Hold the phone steady, keep your face focused in the centre and click on Capture" below the camera placeholder.


INJIMOB-784
5The description in the camera screen is not explaining about the sharing credential. Text near the scanner can mention about the “Hold the phone steady and scan the QR code to share your credential”.
  1. Enhance text in Share page while scanning QR code. Text near the scanner can mention about the “Hold the phone steady and scan the QR code to share your card."
  2. Change CTA from "Scan" to "Share"
INJIMOB-783
6

Unlock App screen:


Abi would be stressed if she doesn’t remember the passcode. As there is nothing on the screen to get help. She might not know what to do because she is risk averse.

Add text: Tap on the button to unlock you app with the PIN or biometrics - Text to be enhanced in the unlock screen to clearly call out on other options.


“To unlock the app securely, you can set up either biometric authentication, such as fingerprint or facial recognition or opt for a 6-digit Passcode for quick access.
Choose 'Use Biometrics' to enable biometric authentication or 'I'll Do Later' to set up a 6-digit passcode.”

CTAs:

Use Biometrics

I’ll Do Later


INJIMOB-778
7During the VC sharing, the successful transfer screen closes in a split second leaving the user clueless on the action status. The transition was quick, and no document is shown after the successful transfer. hence Abi is not clear if the sharing is successful or not.Consider having an Error screen with CTA, clearly indicating the next expected action > Retry

INJIMOB-745


INJIMOB-680

8

No Information related to the selfie captured process was not conveyed to the users, even in the end screen. Selfie capture process does not relate back to the ID sharing process. No message regarding what happened with the selfie clicked.


Post face capture and before initiating the sharing process, inform users about successful face verification/match - But without any CTA.


INJIMOB-722
# License The documentation is licensed under a Creative Commons Attribution 4.0 International License. [![CC license Image](https://github.com/mosip/documentation/raw/c55e1a943900038cdee9f3568409d0b2430729d9/docs/_images/by.svg)](https://github.com/mosip/documentation/blob/c55e1a943900038cdee9f3568409d0b2430729d9/docs/_images/by.svg) All Inji's core repositories are licensed under the terms of [Mozilla Public License 2.0](https://github.com/mosip/commons/blob/master/LICENSE). 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. # Announcement ## Docs got a new Address! Please note! Documentation has now moved to a new address and that is [**docs.inji.io**](https://docs.inji.io/). This means we will gradually phase out the docs from being staying available at older URL i.e. [**docs.mosip.io/inji**](https://docs.mosip.io/inji)**.** For now, both the addresses are active helping through this transition untill every user comes to know of this update. # 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](/readme/setup/infrastructure-requirements) * Deployment Architecture * Deploying Inji # Infrastructure Requirements ## **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** Refer to [**Kubernetes Core Components**](https://kubernetes.io/docs/concepts/overview/components/#core-components) for standard terminology. ### **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** | **Usage** | **VMs** | **vCPU** | **RAM** | **HDD** | **Network Interface** | | ------------------------- | ------- | -------- | ------- | ------- | --------------------- | | Inji-Cluster Worker Nodes | 3 | 8 | 32GB | 64GB | 1 Private | | Inji-Cluster NGINX | 1 | 4 | 8GB | 128GB | 1 Private + 1 Public | | Wireguard Bastion Server | 1 | 2 | 4GB | 30GB | 1 Private + 1 Public | {% hint style="warning" %} **Note:** This configuration is for Proof of Concept, Small scale pilot, demonstration and evaluation purposes only. For production deployments, follow high availability best practices as outlined in the Kubernetes or RKE documentation to be able to sustain failures. {% endhint %} ## **Production Guidelines (Optional for POC)** For reference, follow Rancher’s production-ready checklist and instruction for RKE which are mentioned here : [**Recommended Cluster Architecture - Rancher**](https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/checklist-for-production-ready-clusters/recommended-cluster-architecture). ### **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** | **Usage** | **VMs** | **vCPU** | **RAM** | **HDD** | **Network Interface** | | ------------------------- | ------- | -------- | ------- | ------- | --------------------- | | Observation Cluster Nodes | 2 | 4 | 8GB | 64GB | 1 Private | | Observation Cluster NGINX | 1 | 4 | 8GB | 64GB | 1 Private | ### **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. # 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](#inji-stack-deployment) section. ### How is this guide structured and organized? 1. [**Introduction**](#introduction): Provides an overview of the Inji stack, deployment scenarios, required skill sets, system architecture, and key considerations for on-premise deployments. 2. [**Prerequisites**](#prerequisites-for-overall-deployment): Outlines infrastructure details, hardware/software/network requirements, and initial setup steps. 3. [**Base Infrastructure Setup**](#base-infrastructure-setup): Guides you through setting up the foundational infrastructure for Inji, including Kubernetes provisioning, NGINX configuration, networking, and optionally, the observability cluster and monitoring module. 4. [**Core Infrastructure Configuration**](#core-infrastructure-components-setup): Explains the external services required—such as the database, artifactory, etc.,—and provides steps for their installation and configuration. 5. [**Inji Stack Deployment**](#inji-stack-deployment): Offers step-by-step instructions to deploy Inji modules (Certify, Wallet, Verify) along with configuration guidance. 6. [**Contribution and Community**](#contribution-and-community): 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. ### Typical Deployment Scenarios The scenarios listed below are only a few examples. Inji Stack can support many more deployment possibilities depending on the country, organization, or individual requirements. | Deployment Scenario | Modules Included | Countries / Use Case Example | | --------------------------------------------------------- | -------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------- | | Full Stack Deployment (with eSignet) | Certify, Web Wallet, Verify, Mimoto | Countries using MOSIP eSignet for authentication | | Full Stack Deployment (without eSignet / own Auth Server) | Certify, Web Wallet, Verify, Mimoto | Countries using their own authentication servers | | Module-Specific Deployment (with eSignet) | Selected modules based on requirement | Certify + Verify: Issuance & verification focus | | Module-Specific Deployment (without eSignet) | Selected modules based on requirement | Web Wallet + Mobile Wallet: Credential holding/presentation | | Hybrid Deployment | Some modules on-premise, some on cloud | Countries with regulatory/data residency constraints, for example issuer to be on-prem while the inji wallet is deployed on cloud | | Phased Rollout Deployment | Gradual deployment of modules/regions | Pilot projects or regional rollouts | ### Basic Skill-sets Required Deploying Inji Stack is easier while you have Base Infrastructure ready, still, if you want to deploy it 'On-Premise' and from scratch, this guide helps you with the instructions to achieve this. {% hint style="success" %} **Note**: The basic Skill-sets mentioned below, in fact, expects you to know the following to be able to deploy it from scratch and that too on a bare metal servers (On-Premise). This should not get intimidating as in typical scenarios we expect the infrastructure to be deployed by an experienced 'System-Admin/DevOps'. However in case you want to evangelize Inji in your organization and want to have a hands-on with the deployment, this guide helps you with the steps and instructions to achieve this. {% endhint %} * **Linux System Administration**: Proficiency in Linux command-line operations, user and permission management, and basic networking. * **Networking Fundamentals**: Knowledge of firewalls, load balancers, DNS, and secure network configuration. * **Containerisation**: Experience with Docker or similar container technologies for building and managing service containers. * **Kubernetes Administration**: Understanding of Kubernetes concepts, cluster setup, resource management, and troubleshooting. * **Helm**: Familiarity with Helm for managing Kubernetes manifests and deployments. * **Database Management**: Basic skills in managing PostgreSQL or similar databases, including initialization and schema setup. * **Configuration Management**: Ability to manage application configuration files, secrets, and certificates securely. * **Monitoring and Logging**: Understanding of logging and monitoring tools to observe system health and troubleshoot issues. * **Security Best Practices**: Awareness of secure credential handling, certificate management, and access control. * **Scripting**: Basic scripting skills (e.g., Bash, Python) for automation and operational tasks. * **Familiarity with CI/CD Pipelines**: Understanding of continuous integration and deployment processes is a plus. ### Deployment Architecture of Inji Links to the deployment architecture diagrams below take you to respective sections of this guide and illustrate the high-level deployment architecture for Inji Stack, showing how core components interact within the Kubernetes cluster, including ingress, services, and external integrations. * [Inji Certify](#deploying-inji-certify) * Inji Wallet * [Inji Web Wallet](#deploying-inji-web-wallet) * [Mimoto(backend for Wallet)](#deploying-mimoto-backend-for-inji-wallet) * [Inji Verify](#deploying-inji-verify) ### Typical Deployment Order For a smooth and error-free setup of the Inji Stack, it is recommended to follow the deployment order starting with Inji Certify, followed by mimoto backend for Inji Wallet(Mobile+Web), next the Inji Web Wallet, and finally Inji Verify. This sequence ensures that foundational services and dependencies are available before deploying modules that rely on them, leading to a more stable and seamless deployment experience. ### Deployment Considerations for On-Premise Inji Stack The section helps you to have a quick understanding of what you should expect when you go about deploying Inji-Stack, especially if you are deploying it 'On-Premise' and from scratch. * Inji modules are deployed as microservices in a Kubernetes cluster. * Wireguard is used as a trust network extension to access the admin, control, and observation panes. * Inji uses Nginx server for: * SSL termination * Reverse Proxy * CDN/Cache management * Load balancing * Kubernetes (k8's) cluster is administered using the rke tools and kubectl commands. * We have two k8's clusters: * **Observation cluster** \[Optional] - This cluster is part of the observation plane and assists with administrative tasks. By design, this is kept independent from the actual cluster as a good security practice and to ensure clear segregation of roles and responsibilities. As a best practice, this cluster or its services should be internal and should never be exposed to the external world. * Rancher is used for managing the Inji cluster. * Keycloak in this cluster is used to manage user access and rights for the observation plane. * It is recommended to configure log monitoring and network monitoring in this cluster during production deployment. * In case you have an internal container registry, then it should run here. * **Inji cluster** - This cluster runs all the Inji components and core infrastructure components like kafka, Postgres, minio, etc. * Inji Services are deployed in this cluster. ## Prerequisites for Overall Deployment While we have placed the **Prerequisites** specific to a section under respective sections itself, here, this '**Prerequisites**' lists the common ones which you will need no matter which component you are deploying such as Wireguard, PC - Tools and Utilities etc. ### Personal Computer Follow the steps mentioned here to install the required tools on your personal computer to create and manage the k8's cluster. #### Operating Systems The Inji stack can be deployed with a PC having one of the following operating systems, however for this guide we have considered a linux machine with Ubuntu 22.04 LTS. * **Linux** (Ubuntu 22.04 LTS - recommended for production deployments) * **Windows** * **macOS (OSX)** {% hint style="success" %} **Note:** Ignored scenarios are not related to particular use cases and 34 scenarios are known issues can be tracked from [INJICERT-681](https://mosip.atlassian.net/browse/INJICERT-681), [INJICERT-1118](https://mosip.atlassian.net/browse/INJICERT-1118), [INJICERT-1176](https://mosip.atlassian.net/browse/INJICERT-1176) {% endhint %} #### Tools and Utilities You should have these tools installed on your local machine from where you will be running the ansible playbooks to create and manage the k8 cluster using RKE1. * [Ansible](https://docs.ansible.com/ansible/latest/installation_guide/installation_distros.html) - version > 2.12.4 * Command line utilities: * [kubectl](https://kubernetes.io/docs/tasks/tools/#kubectl)- version 2.12.4 or higher * [helm](https://helm.sh/docs/intro/install/)- any client version above 3.0.0 and add below repos as well ``` helm repo add bitnami https://charts.bitnami.com/bitnami helm repo add mosip https://mosip.github.io/mosip-helm ``` * [rke](https://rancher.com/docs/rke/latest/en/installation/) : version: [1.3.10](https://github.com/rancher/rke/releases/tag/v1.3.10) * [Istioctl](https://istio.io/latest/docs/setup/getting-started/#download) : version: 1.15.0 * Create a directory as mosip in your PC and: * clone k8’s infra repo with tag : 1.2.0.2 (**whichever is the latest version**) inside mosip directory. `git clone https://github.com/mosip/k8s-infra -b v1.2.0.2` * clone mosip-infra with tag : 1.2.0.2 (**whichever is the latest version**) inside mosip directory. `git clone https://github.com/mosip/mosip-infra -b v1.2.0.2` * Set below mentioned variables in bashrc and excute command `source .bashrc` ``` export INJI_ROOT= export K8_ROOT=$INJI_ROOT/k8s-infra export INFRA_ROOT=$INJI_ROOT/mosip-infra ``` > Note: Above mentioned environment variables will be used throughout the installation to move between one directory to other to run install scripts. * Wireguard Client - Refer to the [Setup Wireguard Client on your PC](#setup-wireguard-client-on-your-pc) section for the instructions. ### Setting Up Wireguard {% hint style="success" %} **Note**: In case you already have VPN configured to access nodes privately please skip Wireguard installation and continue to use the same VPN. {% endhint %} 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. {% hint style="success" %} **Note**: You can also refer to [Wireguard Administrator's Guide](https://github.com/mosip/k8s-infra/blob/main/docs/wireguard-administrators-guide.md) for more on Wireguard configuration and management. {% endhint %} #### Prerequisites to Set Up Wireguard **Wireguard Bastion Host** * **VMs and Hardware Specifications** * 1 VM (ensure to set up active-passive for HA) * Specification - 2 vCPUs, 4 GB RAM, 8 GB Storage (HDD) * **Server Network Interfaces** * Private interface: On the same internal network as all other nodes (e.g., local NAT network). * Public interface: Either a direct public IP or a firewall/NAT rule forwarding UDP port 51820 to this interface's IP address. #### Setting up Wireguard VM and wireguard bastion server Before proceeding, Create a Wireguard server VM with the mentioned specification under 'Prerequisites' above. This VM will be used to set up the Wireguard server. Once the VM is ready, open the required ports on the Bastion server VM. **Open required ports in the Bastian server VM** Configure the firewall on the Bastion server virtual machine to allow network traffic through specific ports needed for your application or remote access. * `cd $K8_ROOT/wireguard/` * Create copy of `hosts.ini.sample` as `hosts.ini` and update the required details for wireguard VM * `cp hosts.ini.sample hosts.ini` {% hint style="success" %} **Note**: * Remove `[Cluster]` complete section from copied `hosts.ini` file. * Add below mentioned details: * ansible\_host : public IP of Wireguard Bastion server. eg. 100.10.20.56 * ansible\_user : user to be used for installation. In this ref-impl we use Ubuntu user. * ansible\_ssh\_private\_key\_file : path to pem key for ssh to wireguard server. eg. `~/.ssh/wireguard-ssh.pem` {% endhint %} * Execute ports.yml to enable ports on VM level using ufw:`ansible-playbook -i hosts.ini ports.yaml` {% hint style="success" %} **Note**: * Permission of the pem files to access nodes should have 400 permission. `sudo chmod 400 ~/.ssh/privkey.pem` * These ports are only needed to be opened for sharing packets over UDP. * Take necessary measure on firewall level so that the Wireguard server can be reachable on 51820/udp. {% endhint %} **Install docker** * execute docker.yml to install docker and add user to docker group: ```sh ansible-playbook -i hosts.ini docker.yaml ``` * Setup Wireguard server * SSH to wireguard VM * `ssh -i ubuntu@` * Create directory for storing wireguard config files.\ `mkdir -p wireguard/config` * Install and start wireguard server using docker as given below: ```sh sudo docker run -d \ --name=wireguard \ --cap-add=NET_ADMIN \ --cap-add=SYS_MODULE \ -e PUID=1000 \ -e PGID=1000 \ -e TZ=Asia/Calcutta \ -e PEERS=30 \ -p 51820:51820/udp \ -v /home/ubuntu/wireguard/config:/config \ -v /lib/modules:/lib/modules \ --sysctl="net.ipv4.conf.all.src_valid_mark=1" \ --restart unless-stopped \ ghcr.io/linuxserver/wireguard ``` {% hint style="success" %} **Note**: * Increase the number of peers above in case more than 30 wireguard client confs (-e PEERS=30) are needed. * Change the directory to be mounted to wireguard docker as per need. All your wireguard confs will be generated in the mounted directory (`-v /home/ubuntu/wireguard/config:/config`). {% endhint %} #### Setup Wireguard Client on your PC * Install Wireguard client on your PC using [steps](https://www.wireguard.com/install/). * Assign `wireguard.conf`: * SSH to the wireguard server VM. * `cd /home/ubuntu/wireguard/config` * assign one of the PR for yourself and use the same from the PC to connect to the server. * create `assigned.txt` file to assign the keep track of peer files allocated and update everytime some peer is allocated to someone. ``` peer1 : peername peer2 : xyz ``` * use `ls` cmd to see the list of peers. * get inside your selected peer directory, and add mentioned changes in `peer.conf`: * `cd peer1` * `nano peer1.conf` * Delete the DNS IP. * Update the allowed IP's to subnets CIDR ip . e.g. 10.10.20.0/23 * Share the updated `peer.conf` with respective peer to connect to wireguard server from Personel PC. * add `peer.conf` in your PC’s `/etc/wireguard` directory as `wg0.conf`. * start the wireguard client and check the status: ``` sudo systemctl start wg-quick@wg0 sudo systemctl status wg-quick@wg0 ``` * Once connected to wireguard, you should be now able to login using private IP’s. ## Base Infrastructure Setup ## What do we mean here by Base Infrastructure Setup? "Base Infrastructure Setup" refers to preparing all foundational resources and configurations needed before deploying the Inji stack. This includes provisioning servers/VMs, configuring networks and firewalls, setting up SSL certificates, installing Kubernetes clusters and required tools (Docker, kubectl, Helm, etc.), establishing secure access (e.g., Wireguard VPN), and deploying essential services like NGINX, storage, monitoring, and logging. It ensures the environment is ready for Inji stack installation. * **Provisioning foundational resources** required for the Inji stack, including: * Virtual machines (VMs) or servers as per hardware requirements. * Network configuration (internal connectivity, firewall rules, DNS). * SSL certificate setup for secure communications. * **Setting up Kubernetes clusters**: * Installing and configuring Kubernetes (using RKE, Rancher, etc.). * Ensuring cluster nodes are accessible and properly networked. * **Configuring supporting infrastructure**: * Installing Docker and required CLI tools (kubectl, helm, ansible, istioctl). * Setting up passwordless SSH access to all nodes. * Preparing configuration files (hosts.ini, values.yaml, etc.). * **Deploying essential services**: * Setting up NGINX for SSL termination, reverse proxy, and load balancing. * Configuring storage classes (e.g., NFS) for persistent storage. * Setting up monitoring, logging, and alerting tools (Prometheus, Grafana, Fluentd, etc.). * **Establishing secure access**: * Installing and configuring Wireguard VPN for secure cluster access. * Ensuring only authorized users can access the infrastructure. * **Importing clusters into management tools** (e.g., Rancher) for centralized administration. ### Prerequisites for Base Infrastructure Setup Before deploying any Inji Stack module, ensure that the following common prerequisites are met. These requirements apply to all modules and must be fulfilled to guarantee a smooth and successful deployment process. #### On-Prem Server Requirements > **Note:** You can deploy Inji on an environment and operating system that supports Kubernetes-based deployments. Ensure your chosen OS and infrastructure meet the prerequisites and compatibility requirements. **Note**: This guide references using **Ubuntu Server 22.04 LTS**. **Note:** For large-scale deployments or environments with strict security requirements, an on-premises setup is recommended. For pilot projects, demonstrations, or rapid prototyping, a cloud-based deployment may be more suitable. > **Note**: Virtual Machines (VMs) can use any operating system as per convenience. For this installation guide, Ubuntu OS is referenced throughout. #### VMs-Virtual Machines (Hardware, Network, Certificate and DNS) - Along with Nginx server (use Loadbalancer if required) * **VMs and Hardware Specifications** * 3 VMs (allocate etcd, control plane, and worker nodes accordingly for HA) * Specification - 8 vCPUs, 32 GB RAM, 64 GB Storage (HDD) * **Network Interfaces** * Internal interface: On the same internal network as all other nodes, with internet access. * **Wildcard SSL Certificate for the Inji K8s Cluster** * A valid wildcard SSL certificate for the domain used to access the inji Kubernetes cluster. * This certificate must be stored inside the Nginx server VM for the inji cluster. * For example, a domain like \*.sandbox.xyz.net could serve as the corresponding example. {% hint style="success" %} **Note**: Network Requirements * All the VM's should be able to communicate with each other. * Need stable Intra network connectivity between these VM's. * All the VM's should have stable internet connectivity for docker image download (in case of local setup ensure to have a locally accessible docker registry). {% endhint %} #### DNS Requirements Below is a sample mapping of domain names to their respective IP addresses and purposes for a typical Inji deployment. Update these as per your environment. * **rancher.xyz.net** * Maps to: Private IP of Nginx server or load balancer (Observation cluster) * Purpose: Rancher dashboard for monitoring and managing the Kubernetes cluster. * **keycloak.xyz.net** * Maps to: Private IP of Nginx server (Observation cluster) * Purpose: Administrative IAM tool (Keycloak) for Kubernetes administration. * **sandbox.xyz.net** * Maps to: Private IP of Nginx server (MOSIP cluster) * Purpose: Index page for links to MOSIP environment dashboards (not for production/UAT use). * **api-internal.sandbox.xyz.net** * Maps to: Private IP of Nginx server (MOSIP cluster) * Purpose: Internal APIs, accessible privately over Wireguard. * **api.sandbox.xyz.net** * Maps to: Public IP of Nginx server (MOSIP cluster) * Purpose: Publicly exposed APIs. * **iam.sandbox.xyz.net** * Maps to: Private IP of Nginx server (MOSIP cluster) * Purpose: OpenID Connect server (default: Keycloak) for service access, accessible over Wireguard. * **postgres.sandbox.xyz.net** * Maps to: Private IP of Nginx server (MOSIP cluster) * Purpose: Points to Postgres server, connect via port forwarding over Wireguard. * **injiweb.sandbox.xyz.net** * Maps to: Public IP of Nginx server (MOSIP cluster) * Purpose: Public access to Inji Web portal. * **injicertify.sandbox.xyz.net** * Maps to: Public IP of Nginx server (MOSIP cluster) * Purpose: Public access to Inji Certify portal. * **injiverify.sandbox.xyz.net** * Maps to: Public IP of Nginx server (MOSIP cluster) * Purpose: Public access to Inji Verify portal. > **Note:** Ensure all DNS records are created and point to the correct IP addresses (public or private) as per your network design. For private domains, access is typically restricted via Wireguard VPN. #### PC Requirements See the [Tools and Utilities](#tools-and-utilities) section for common prerequisites required for all deployments. ### Setting Up Kubernetes Cluster > **Note:** For detailed VM provisioning steps and hardware/network prerequisites, see the [Prerequisites](#prerequisites-for-base-infrastructure-setup) above for VM - Hardware specification and more. * Find the **kubernetes infrastructure repository** [here](https://github.com/mosip/k8s-infra/tree/v1.2.0.1) 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. * Run `env-check-setup.yaml` to check if cluster nodes are fine and doesn't have known issues in it. * `cd $K8_ROOT/rancher/on-prem` * Create copy of `hosts.ini.sample` as `hosts.ini` and update the required details for MOSIP k8 cluster nodes. * `cp hosts.ini.sample hosts.ini` > Note: > > * Ensure you are inside `on-prem` directory as mentioned above. > * ansible\_host : internal IP of nodes. eg. 100.10.20.56, 100.10.20.57 ... > * ansible\_user : user to be used for installation. In this ref-implementation we use Ubuntu user. > * ansible\_ssh\_private\_key\_file : path to pem key for ssh to wireguard server. eg. `~/.ssh/nodes-ssh.pem` * `ansible-playbook -i hosts.ini env-check-setup.yaml` * This ansible checks if localhost mapping ia already present in `/etc/hosts` file in all cluster nodes, if not it adds the same. * Setup passwordless ssh into the cluster nodes via pem keys. (Ignore if VM’s are accessible via pem’s). * Generate keys on your PC * `ssh-keygen -t rsa` * Copy the keys to remote rancher node VM’s: * `ssh-copy-id @` * SSH into the node to check password-less SSH * `ssh -i ~/.ssh/ @` * Rancher UI : (deployed in Observation K8 cluster) * Open ports and Install docker on Inji K8 Cluster node VM’s. * `cd $K8_ROOT/mosip/on-prem` * create copy of `hosts.ini.sample` as `hosts.ini` and update the required details for wireguard VM. * `cp hosts.ini.sample hosts.ini` * Update `vpc_ip` variable in `ports.yaml` with `vpc CIDR ip` to allow access only from machines inside same vpc. > Note: > > * CIDR Range will be shared by the Infra provider. > * Make sure all the nodes are covered in the provided CIDR range. (nginx server, K8 cluster nodes for observation as well as mosip). * execute `ports.yml` to enable ports on VM level using ufw: * `ansible-playbook -i hosts.ini ports.yaml` * Disable swap in cluster nodes. (Ignore if swap is already disabled) * `ansible-playbook -i hosts.ini swap.yaml` > Caution: Always verify swap status with `swapon --show` before running the playbook to avoid unnecessary operations. * execute `docker.yml` to install docker and add user to docker group: * `ansible-playbook -i hosts.ini docker.yaml` * Creating RKE Cluster Configuration file * `rke config` * Command will prompt for nodal details related to cluster, provide inputs w\.r.t below mentioned points: * `SSH Private Key Path` : * `Number of Hosts`: * `SSH Address of host` : * `SSH User of host` : ``` Is host () a Control Plane host (y/n)? [y]: y Is host () a Worker host (y/n)? [n]: y Is host () an etcd host (y/n)? [n]: y ``` * Make all the nodes Worker `host` by default. * To create an HA cluster, specify more than one host with role `Control Plane` and `etcd host`. * `Network Plugin Type` : Continue with canal as default network plugin. * For rest for other configuration opt the required or default value. * As result of rke config command `cluster.yml` file will be generated inside same directory, update the below mentioned fields: * `nano cluster.yml` * Remove the default Ingress install ``` ingress: provider: none ``` * Update the name of the kubernetes cluster in `cluster.yaml` ``` `cluster_name: sandbox-name` ``` * For production deplopyments edit the `cluster.yml`, according to this [RKE Cluster Hardening Guide](https://github.com/mosip/k8s-infra/blob/v1.2.0.1-B1/docs/rke-cluster-hardening.md). * Setup up the cluster: * Once `cluster.yml` is ready, you can bring up the kubernetes cluster using simple command. * This command assumes the `cluster.yml` file is in the same directory as where you are running the command. * `rke up` ``` INFO[0000] Building Kubernetes cluster INFO[0000] [dialer] Setup tunnel for host [10.0.0.1] INFO[0000] [network] Deploying port listener containers INFO[0000] [network] Pulling image [alpine:latest] on host [10.0.0.1] ... INFO[0101] Finished building Kubernetes cluster successfully ``` * The last line should read `Finished building Kubernetes cluster successfully` to indicate that your cluster is ready to use. * Copy the kubeconfig files ``` cp kube_config_cluster.yml $HOME/.kube/_config chmod 400 $HOME/.kube/_config ``` * To access the cluster using kubeconfig file use any one of the below method: * `cp $HOME/.kube/_config $HOME/.kube/config` **Alternatively** ``` * `export KUBECONFIG="$HOME/.kube/_config` ``` * Test cluster access: * `kubectl get nodes` * Command will result in details of the nodes of the rancher cluster. * Save Your files * Save a copy of the following files in a secure location, they are needed to maintain, troubleshoot and upgrade your cluster.: * `cluster.yml`: The RKE cluster configuration file. * `kube_config_cluster.yml`: The [Kubeconfig file](https://rke.docs.rancher.com/kubeconfig) for the cluster, this file contains credentials for full access to the cluster. * `cluster.rkestate`: The [Kubernetes Cluster State file](https://rke.docs.rancher.com/installation#kubernetes-cluster-state), this file contains credentials for full access to the cluster. ### K8s (Kubernetes) Cluster Configuration #### Ingress and Storage Class setup [**Istio**](https://istio.io/) **Ingress setup** It is a service mesh for the MOSIP K8 cluster which provides transparent layers on top of existing microservices along with powerful features enabling a uniform and more efficient way to secure, connect, and monitor services. * `cd $K8_ROOT/mosip/on-prem/istio` * `./install.sh` * This will bring up all the Istio components and the Ingress Gateways. * Check Ingress Gateway services: * `kubectl get svc -n istio-system` > Note: Response should contain service names as mentioned below. > > * `istio-ingressgateway`: external facing istio service. > * `istio-ingressgateway-internal`: internal facing istio service. > * `istiod`: Istio daemon for replicating the changes to all envoy filters. **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. ```sh cd $K8_ROOT/nfs ``` * Create a copy of hosts.ini.sample as hosts.ini. ```sh cp hosts.ini.sample 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 > * ansible\_user : user to be used for installation, in this ref-impl we use Ubuntu user. > * ansible\_ssh\_private\_key\_file : path to pem key for ssh to wireguard server. eg. `~/.ssh/wireguard-ssh.pem` . * Make sure Kubeconfig file is set correctly to point to required mosip cluster. ```sh kubectl config view ``` {% hint style="success" %} **Note**: * Output should show the cluster name to confirm you are pointing to right kubernetes cluster. * If not pointing to right K8 cluster change the kubeconfig to connect to right K8 cluster. * Enable firewall with required ports: {% endhint %} ```sh ansible-playbook -i ./hosts.ini nfs-ports.yaml ``` * SSH to the nfs node: ```sh ssh -i ~/.ssh/nfs-ssh.pem ubuntu@ ``` * Clone `k8s-infra` repo in nginx VM: ```sh git clone https://github.com/mosip/k8s-infra -b v1.2.0.1 ``` * Move to the nfs directory: ```sh cd /home/ubuntu/k8s-infra/nfs/ ``` * Execute script to install nfs server: ```sh sudo ./install-nfs-server.sh ``` > Note: > \* Script prompts for below mentioned user inputs: > > `> ..... > Please Enter Environment Name: > ..... > ..... > ..... > [ Export the NFS Share Directory ] > exporting *:/srv/nfs/mosip/ > NFS Server Path: /srv/nfs/mosip/ >` > > \* envName: env name eg. dev/qa/uat... * Switch to your personel computer and excute below mentioned commands: ```sh cd $K8_ROOT/nfs/ ``` ```sh ./install-nfs-client-provisioner.sh ``` {% hint style="success" %} 
Note: 

Script prompts for:
* NFS Server: NFS server ip for persistence.
* NFS Path : NFS path for storing the persisted data. eg. /srv/nfs/mosip/
{% endhint %} * Post installation check: * Check status of NFS Client Provisioner from your PC, make sure pointing to right kubeconfig file. ```sh kubectl -n nfs get deployment.apps/nfs-client-provisioner ``` * Check status of nfs-client storage class. ```sh kubectl get storageclass NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE longhorn (default) driver.longhorn.io Delete Immediate true 57d nfs-client cluster.local/nfs-client-provisioner Delete Immediate true 40s ``` #### Inji K8's (Kubernetes) cluster Nginx server setup **SSL certificate creation** * For Nginx server setup, we need ssl certificate, add the same into Nginx server. * Incase valid ssl certificate is not there generate one using letsencrypt: * SSH into the nginx server * Install Pre-requisites: ```sh sudo apt update -y sudo apt-get install software-properties-common -y sudo add-apt-repository ppa:deadsnakes/ppa sudo apt-get update -y sudo apt-get install python3.8 -y sudo apt install letsencrypt -y sudo apt install certbot python3-certbot-nginx -y ``` * 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. * The default challenge HTTP is changed to DNS challenge, as we require wildcard certificates. * Create a DNS record in your DNS service of type TXT with host `_acme-challenge.sandbox.xyz.net`, with the string prompted by the script. * Wait for a few minutes for the above entry to get into effect.\ \*\* Verify\*\*: `host -t TXT _acme-challenge.sandbox.mosip.net` * Press enter in the `certbot` prompt to proceed. * Certificates are created in `/etc/letsencrypt` on your machine. * Certificates created are valid for 3 months only. * `Wildcard SSL certificate` [renewal](https://github.com/mosip/k8s-infra/blob/v1.2.0.1/docs/wildcard-ssl-certs-letsencrypt.md#ssl-certificate-renewal). This will increase the validity of the certificate for next 3 months. **Nginx server setup for Inji K8's cluster** * Move to nginx directory in your local: * `cd $K8_ROOT/mosip/on-prem/nginx/` * Open required ports : * Use any editor to create new `hosts.ini` file: ```sh nano hosts.ini ``` * Add below mentioned lines with updated details of nginx server to the `hosts.ini` and save. ```sh [nginx] node-nginx ansible_host= ansible_user=root ansible_ssh_private_key_file= ``` * Execute below mentoned command to open required ports: ```sh ansible-playbook -i hosts.ini mosip/on-prem/nginx/nginx_ports.yaml ``` * Login to the nginx server node. * Clone k8s-infra ```sh cd $K8_ROOT/mosip/on-prem/nginx sudo ./install.sh ``` * Provide below mentioned inputs as and when prompted * MOSIP nginx server internal ip * MOSIP nginx server public ip * Publically accessible domains (comma seperated with no whitespaces) * SSL cert path * SSL key path * Cluster node ip's (comma seperated no whitespace) * Post installation check * `sudo systemctl status nginx` * Steps to uninstall nginx (incase it is required)\ `sudo apt purge nginx nginx-common` * **DNS mapping**: Once nginx server is installed sucessfully, create DNS mapping for observation cluster related domains as mentioned in DNS requirement section. **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. ```sh cd $K8_ROOT/utils/httpbin ./install.sh ``` * To see what is reaching the httpbin (example, replace with your domain name): ```sh curl https://api.sandbox.xyz.net/httpbin/get?show_env=true curl https://api-internal.sandbox.xyz.net/httpbin/get?show_env=true ``` #### \[Optional] Monitoring module deployment > Note : > > * Monitoring in the sandbox environment is optional and can be deployed if required. > * For production environments, alternative monitoring tools can be used. > * These steps can also be skipped in development environments if monitoring is not needed. > * Incase skipping execute below commands to install monitoring crd as the same is required by mosip services: > > ``` > helm repo add prometheus-community https://prometheus-community.github.io/helm-charts > helm repo update > kubectl create ns cattle-monitoring-system > helm -n cattle-monitoring-system install rancher-monitoring-crd mosip/rancher-monitoring-crd > ``` * 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. ``` ingressNginx: enabled: false ``` * Click on `Install`. #### \[Optional] Alerting setup **Note**: * Alerting in the sandbox environment is optional and can be deployed if required. * For production environments, alternative alerting tools can be used. * These steps can also be skipped in development environments if alerting is not needed. * Alerting is part of cluster monitoring, where alert notifications are sent to the configured email or slack channel. * Monitoring should be deployed which includes deployment of prometheus, grafana and alertmanager. * Create [slack incoming webhook](https://api.slack.com/messaging/webhooks). * After setting slack incoming webhook update `slack_api_url` and `slack_channel_name` in `alertmanager.yml`. * `cd $K8_ROOT/monitoring/alerting/` * `nano alertmanager.yml` * Update: ``` global: resolve_timeout: 5m slack_api_url: ... slack_configs: - channel: '' send_resolved: true ``` * Update `Cluster_name` in `patch-cluster-name.yaml`. * `cd $K8_ROOT/monitoring/alerting/` * `nano patch-cluster-name.yaml` * Update: ``` spec: externalLabels: cluster: ``` * Install Default alerts along some of the defined custom alerts: ``` cd $K8_ROOT/monitoring/alerting/ ./install.sh ``` * Alerting is installed. #### \[Optional] Logging module setup and installation > Note : > > * Logging in the sandbox environment is optional and can be deployed if required. > * For production environments, alternative logging tools can be used. > * These steps can also be skipped in development environments if logging is not needed. Inji uses [Rancher Fluentd](https://ranchermanager.docs.rancher.com/v2.0-v2.4/explanations/integrations-in-rancher/cluster-logging/fluentd) 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. * Configure Rancher FluentD * Create `clusteroutput` * `kubectl apply -f clusteroutput-elasticsearch.yaml` * Start `clusterFlow` * `kubectl apply -f clusterflow-elasticsearch.yaml` * Install elasticsearch, kibana and Istio addons\\ ``` cd $K8_ROOT/logging ./intall.sh ``` * set `min_age` in `elasticsearch-ilm-script.sh` and execute the same. * `min_age` : is the minimum no. of days for which indices will be stored in elasticsearch. ``` cd $K8_ROOT/logging ./elasticsearch-ilm-script.sh ``` * Inji provides set of Kibana Dashboards for checking logs and throughputs. * Brief description of these dashboards are as follows: * [01-logstash.ndjson](https://github.com/mosip/k8s-infra/blob/v1.2.0.1/logging/dashboards/01-logstash.ndjson) contains the logstash *Index* Pattern required by the rest of the dashboards. * [02-error-only-logs.ndjson](https://github.com/mosip/k8s-infra/blob/v1.2.0.1/logging/dashboards/03-service-logs.ndjson) contains a Search dashboard which shows only the error logs of the services, called `MOSIP Error Logs` dashboard. * [03-service-logs.ndjson](https://github.com/mosip/k8s-infra/blob/v1.2.0.1/logging/dashboards/03-service-logs.ndjson) contains a Search dashboard which show all logs of a particular service, called Inji Service Logs dashboard. * [04-insight.ndjson](https://github.com/mosip/k8s-infra/blob/v1.2.0.1/logging/dashboards/04-insight.ndjson) contains dashboards which show insights into Inji processes, like the number of UINs generated (total and per hr), the number of Biometric deduplications processed, number of packets uploaded etc, called `Inji Insight` dashboard. * [05-response-time.ndjson](https://github.com/mosip/documentation/blob/inji/docs/readme/setup/mosip/on-prem-installation-guidelines.md) contains dashboards which show how quickly different MOSIP Services are responding to different APIs, over time, called `Response Time` dashboard. * Import dashboards: * `cd K8_ROOT/logging` * `./load_kibana_dashboards.sh ./dashboards ` * View dashboards Open kibana dashboard from `https://kibana.sandbox.xyz.net`. Kibana --> Menu (on top left) --> Dashboard --> Select the dashboard. ## Core Infrastructure Components Setup This section covers the installation and configuration of essential infrastructure components required for the Inji stack, including configmaps, databases, object storage, secrets management, configuration server, and artifactory. ### Inji Stack Configmap: For inji K8's env * `inji-stack-config` configmap: For inji K8's env, `inji-stack-config` configmap in `default` namespace contains Domain related information. Follow below steps to add domain details for `inji-stack-config` configmap. * Update the domain names in `inji-stack-cm.yaml` correctly for your environment. {% hint style="success" %} **Note**: You can find the `inji-stack-cm.yaml` file in the deployment scripts or configuration directory of the Inji stack repository, typically under the `deploy` or `k8s` folder. If it is not present, you can create it using the sample configmap YAML provided in this guide, and then update the domain names as per your environment before applying it to your Kubernetes cluster {% endhint %} ```yaml kubectl apply -f - </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 ``` * Run the Script ```sh chmod +x configserver.sh ./configserver.sh ``` ## Inji Stack Deployment Once **Prerequisites**, **Base Infrastructure**, and the **Core Infrastructure Setup and Configuration** are complete, now you can proceed with the deployment of the Inji stack components. For detailed deployment steps, architecture, and module-level instructions, refer to the following: * [Inji Certify](#deploying-inji-certify) * Inji Wallet * [Inji Web Wallet](#deploying-inji-web-wallet) * [Mimoto(backend for Wallet)](#deploying-mimoto-backend-for-inji-wallet) * [Inji Verify](#deploying-inji-verify) ### Deploying Inji Certify While you have a deployment environment ready, you can now proceed with the installation of Inji Certify by following the steps explained here. **Note:** Before deploying Inji Certify, it is recommended to always use the latest [released version](https://docs.inji.io/inji-certify/releases). Each release includes enhancements, technical upgrades, and new features to ensure the best experience. #### Understanding the Deployment Approach for Inji Certify Inji Certify is deployed as **containerized microservices** in your Kubernetes cluster. #### Deployment Architecture for Inji Certify
**Where Will it Run?** * **Target Environment**: Your main Kubernetes cluster * **Deployment Method**: Helm charts that pull Docker images from container registries * **Access Point**: Through your configured NGINX ingress at `https://injicertify.sandbox.xyz.net` **What Gets Installed?** 1. **Kubernetes Pods**: Running Inji Certify microservices 2. **Services**: For internal communication 3. **Ingress Rules**: For external access via NGINX 4. **ConfigMaps & Secrets**: For configuration and credentials #### Deployment Process **Step 1: Pre-Deployment Checklist** Before deploying Inji Certify, ensure the following infrastructure components and configurations are in place as mentioned [above](#prerequisites) * [Base Infrastructure](#base-infrastructure-setup) * [Core Infrastructure](#core-infrastructure-components-setup) * [Inji Stack ConfigMap](#inji-stack-config-for-inji-k8s-env) * [Postgres Installation](https://github.com/mosip/mosip-infra/tree/v1.2.0.2/deployment/v3/external/postgres) * Note: Before running the Postgres install script, update the `POSTGRES_HOST` value in `install.sh` with the correct PostgreSQL host. * [Config Server Secerts](https://github.com/mosip/mosip-infra/tree/v1.2.0.2/deployment/v3/mosip/conf-secrets) * [Config Server](#config-server-installation) * [Artifactory](https://github.com/mosip/artifactory-ref-impl/tree/v1.3.0-beta.2/deploy) * Redis Installation **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** ```bash # On your local machine (connected to K8s cluster via kubectl) git clone https://github.com/mosip/inji-certify.git cd inji-certify/deploy ``` **Step 4: Deploy Redis (if not already deployed)** ```bash cd redis ./install.sh ``` **Step 5: Initialize Database** ```bash cd ../db_scripts # Update init_values.yaml with your database configuration, update the necessary parameters for your PostgreSQL database. Provide path or how to navigate to this yaml in cloned repo. ./init_db.sh ``` **Step 6: Deploy Inji Certify Microservices** ```bash cd ../inji-certify ./install.sh ``` #### What Happens During Installation 1. **Helm Charts Execution**: Downloads and deploys Docker containers 2. **Service Registration**: Services register with config-server for configuration 3. **Database Initialization**: Creates required tables and seed data 4. **Ingress Configuration**: Configures routes through Istio gateway 5. **Health Checks**: Verifies all pods are running and healthy \###3 Verification Steps **Check Pod Status** ```sh kubectl get pods -n inji-certify ``` {% hint style="success" %} Note :\ Ensure nelow mentioned services are listed in the output result of above command.\ You can even check Rancher incase deployed.\ 1\. inji-certify\ 2\. inji-softhsm {% endhint %} **Verify Service Endpoints** ```sh kubectl get services -n inji-certify ``` {% hint style="success" %} Note :\ Ensure below mentioned services are listed in the output result of above command.\ You can even check Rancher incase deployed.\ 1\. inji-certify\ 2\. inji-softhsm {% endhint %} **Test External Access** ```sh curl -k https://injicertify.sandbox.xyz.net/health ```
#### Success Criteria for Inji Certify Deployment 1. **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. 2. **Pods Running and Healthy** * All Inji Certify-related pods are in `Running` or `Completed` status. * Verified via `kubectl get pods -n inji-certify` 3. **Services Registered and Reachable** * Microservices register successfully with the config-server. * All services are listed and accessible within the cluster:`kubectl get services -n inji-certify` 4. **Database Initialized Correctly** * PostgreSQL tables and seed data are created as per `init_values.yaml`. * No database errors during initialization. 5. **Ingress Configured Properly** * Istio ingress rules are correctly applied. * Services are reachable externally through the configured gateway. 6. **External Access Verified** * Health endpoint responds successfully `curl -k https://injicertify.sandbox.xyz.net/health` * HTTP 200 response received. #### Important Notes * **Remote Deployment**: You deploy from your local machine to the remote K8s cluster * **Container Registry**: Docker images are pulled from public/private registries during deployment * **Configuration**: All configuration comes from your config-server and configmaps #### Troubleshooting If deployment fails, check: 1. **Cluster Connectivity**: `kubectl cluster-info` 2. **Prerequisites**: Ensure config-server, postgres, redis are running 3. **Resources**: Verify cluster has sufficient CPU/memory 4. **Network**: Ensure ingress and DNS are properly configured You can also refer to the [ReadMe](https://github.com/mosip/inji-certify/blob/master/deploy/README.md) 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 [MOSIP Community](https://community.mosip.io/). The community and maintainers are available to assist you. ### Deploying Mimoto backend for Inji Wallet This section provides a structured, step-by-step guide to deploy Mimoto, which serves as the backend for Inji Mobile Wallet and Inji Web Wallet. Follow these instructions to ensure a successful and reproducible deployment. **Note**: Before deploying mimoto, it is recommended to always use the latest released version. Each release includes enhancements, technical upgrades, and new features to ensure the best experience. #### Understanding the Deployment Approach of Mimoto Mimoto is deployed as **containerized microservices** in your Kubernetes cluster. **Where Will it Run?** * **Target Environment**: Your main Kubernetes cluster * **Deployment Method**: Helm charts and shell scripts that pull Docker images from container registries * **Access Point**: Through your configured NGINX ingress (domain as configured) **What Gets Installed?** 1. **Kubernetes Pods**: Running Mimoto microservices 2. **Services**: For internal communication 3. **Ingress Rules**: For external access via NGINX/Istio 4. **ConfigMaps & Secrets**: For configuration and credentials #### Deployment Process **Step 1: Pre-Deployment Checklist** Before deploying the mimoto (backend for Inji Wallet), ensure the following infrastructure components and configurations are in place as mentioned below: * [Base Infrastructure](#base-infrastructure-setup) * [Core Infrastructure](#core-infrastructure-components-setup) * [Postgres Installation](https://github.com/mosip/mosip-infra/tree/v1.2.0.2/deployment/v3/external/postgres) * Note: Before running the Postgres install script, update the POSTGRES\_HOST value in install.sh with the correct PostgreSQL host. * [Config Server Secrets](#config-server-secrets) * [Config Server Installation](#config-server-installation) * **Artifactory Installation** * For installation instructions, refer to the [artifactory installation guide](https://github.com/mosip/artifactory-ref-impl/tree/v0.10.0-INJI/deploy). * Artifactory is used to store, manage, and distribute build artifacts (such as Docker images, Helm charts, binaries, and other deployment packages) required by the Inji stack and related services. Installing Artifactory ensures that all deployment dependencies are securely managed and easily accessible during automated deployments and upgrades. * **Why install Artifactory?** * Centralizes storage of deployment artifacts for consistency and reliability. * Enables version control and traceability of all build packages. * Facilitates automated CI/CD pipelines by providing a secure and scalable repository. * Supports integration with Kubernetes, Docker, and Helm for seamless deployments. * Redis Installation **Step 2: Clone and Navigate to Deployment Scripts** ```bash # On your local machine (connected to K8s cluster via kubectl) git clone https://github.com/mosip/mimoto.git cd mimoto/deploy ``` **Step 3: Install Redis (If Not Already Installed)** To install Redis, run: ```sh cd deploy/redis ./install.sh ``` **Step 4: Initialize Database** Update the values file for PostgreSQL initialization as needed, then run: ```sh cd ../../db_scripts ./init_db.sh ``` **Step 5: Install Partner Onboarder** To install the Partner Onboarder module: ```sh cd ../partner-onboarder ./install.sh ``` 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. {% hint style="success" %} **Note:**\ If you are running the Onboarder in a separate INJI cluster, update the `extraEnvVars` section in `values.yaml` accordingly. {% endhint %} **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: ```sh cd ../deploy/mimoto ./install.sh ``` 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: 1. Create a folder named `certs` in the root directory. 2. Inside `certs`, create a file named `oidckeystore.p12`. 3. Store the keys as different aliases for each issuer in this file. For more details, refer to the official documentation or the relevant section in the repository. #### Verification Steps * **Check Pod Status:** ```sh kubectl get pods -n mimoto ``` * **Check Service Endpoints:** ```sh kubectl get services -n mimoto ``` * **Test External Access:** ```sh curl -k https:///health ``` #### Important Notes * **Remote Deployment**: You deploy from your local machine to the remote K8s cluster. * **Container Registry**: Docker images are pulled from public/private registries during deployment. * **Configuration**: All configuration comes from your config-server and configmaps. #### Success Criteria for Mimoto Deployment **Note:** Screenshots for each success criteria step will be added shortly to provide a visual reference. 1. **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. 2. **Redis Installed and Running** * Redis pod is running and healthy. * Verified via:`kubectl get pods -n mimoto` 3. **Database Initialized Correctly** * PostgreSQL tables and seed data are created as per `values.yaml`. * No database errors during initialization. 4. **Partner Onboarder Installed and Functional** * Partner Onboarder module installed without errors. * Reports are successfully generated and visible in S3 or NFS storage. * Correct S3 bucket configuration provided during installation. 5. **Mimoto Installed Successfully** * Database host and port are correctly configured in `values.yaml`. * SSL certificate handling works correctly (self-signed or public domain). * All Mimoto pods are running and healthy. 6. **Onboarding New Issuer for VCI** * `certs/oidckeystore.p12` is correctly created with all required keys and aliases. * Issuer onboarding can be verified through logs or API calls. 7. **Pods Running and Healthy** * All Mimoto-related pods are in `Running` or `Completed` status. * Verified via `kubectl get pods -n mimoto` 8. **Services Registered and Reachable** * All microservices are listed and accessible`kubectl get services -n mimoto` 9. **External Access Verified** * Health endpoint responds successfully `curl -k https:///health` * HTTP 200 response received. #### Troubleshooting If deployment fails, check: 1. **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. 2. **Prerequisites**: Ensure config-server, postgres, redis are running 3. **Resources**: Verify cluster has sufficient CPU/memory 4. **Network**: Ensure ingress and DNS are properly configured 5. **Logs**: Check pod logs for errors: `kubectl logs -n mimoto` You can also refer to the [ReadMe](https://github.com/mosip/mimoto/blob/develop/deploy/README.md) 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 [MOSIP Community](https://community.mosip.io/). The community and maintainers are available to assist you. ### Deploying Inji Web Wallet This section explains how to deploy the Inji Web Wallet, which comes with a **reference** web UI and DataShare. This web UI serves as a sample implementation to help integrators and countries build their own customized user interface. **Note**: Before deploying Inji Web Wallet, it is recommended to always use the latest [released version](https://docs.inji.io/inji-wallet/inji-web/inji-web). Each release includes enhancements, technical upgrades, and new features to ensure the best experience. #### Understanding the Deployment Approach of Inji Web Wallet Inji Web UI and dataShare are deployed as **containerized microservices** in your Kubernetes cluster. #### Deployment Architecture for Inji Web Wallet
**Where Will It Run?** * **Target Environment**: Your main Kubernetes cluster * **Deployment Method**: Helm charts that pull Docker images from container registries * **Access Point**: Through your configured NGINX ingress at `https://injiweb.sandbox.xyz.net` (and DataShare endpoints as configured) **What Gets Installed?** 1. **Kubernetes Pods**: Running Inji Web UI and DataShare microservices 2. **Services**: For internal communication 3. **Ingress Rules**: For external access via NGINX/Istio 4. **ConfigMaps & Secrets**: For configuration and credentials #### Deployment Process of Inji Web Wallet **Step 1: Pre-Deployment Checklist** Before deploying Inji Web Wallet, ensure the following infrastructure components and configurations are in place as mentioned below: * [Base Infrastructure](#base-infrastructure-setup) * [Core Infrastructure](#core-infrastructure-components-setup) * [inji-stack-config ConfigMap](#inji-stack-config-for-inji-k8s-env) * [Config Server Secrets](#config-server-secrets) * [Postgres Installation](https://github.com/mosip/mosip-infra/tree/v1.2.0.2/deployment/v3/external/postgres) * [Config Server Installation](#config-server-installation) * [Object store installation](https://github.com/mosip/mosip-infra/tree/v1.2.0.2/deployment/v3/external/object-store) * Note: Before running the minio install script, update the EXTERNAL\_HOST value in install.sh with the correct minio host. **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** ```sh git clone https://github.com/mosip/inji-web.git cd inji-web/deploy ``` **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: ``` default,inji-default,standalone ``` **Step 6: Deploy DataShare (if required)** If DataShare is a separate module, deploy it first: ```sh cd datashare ./install.sh cd .. ``` **Step 6: Deploy Inji Web UI** From the `deploy` directory: ```sh cd injiweb ./install.sh ``` **Step 7: Verification Steps** * Check pod status: ```sh kubectl get pods -n injiweb ``` * Check service endpoints: ```sh kubectl get services -n injiweb ``` * Test external access: ```sh curl -k https://injiweb.sandbox.xyz.net/health ``` **Step 8: Post-Installation Configuration** * Confirm that the `active_profile_env` in the config-server-share config map is set as described above. * Ensure DNS records for `injiweb.sandbox.xyz.net` and any DataShare endpoints are correctly mapped to your ingress controller. #### Important Notes * **Remote Deployment**: You deploy from your local machine to the remote K8s cluster * **Container Registry**: Docker images are pulled from public/private registries during deployment * **Configuration**: All configuration comes from your config-server and configmaps #### Success Criteria for Inji Web Wallet Deployment **Note:** Screenshots for each success criteria step will be added shortly to provide a visual reference. **Your deployment is successful if**: 1. 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`. 2. 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`. 3. 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. 4. 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. 5. DataShare Module (if deployed) is Accessible * DataShare pods are up and healthy. * DataShare endpoints are reachable and registered in Kubernetes. 6. No Critical Errors in Logs * Reviewing logs (`kubectl logs -n injiweb`) shows no failures during startup or runtime. #### Troubleshooting If deployment fails, check: 1. **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. 2. **Prerequisites**: Ensure config-server, postgres, redis are running 3. **Resources**: Verify cluster has sufficient CPU/memory 4. **Network**: Ensure ingress and DNS are properly configured 5. **Logs**: Check pod logs for errors: `kubectl logs -n injiweb` You can also refer to the [ReadMe](https://github.com/mosip/inji-web/blob/develop/deploy/inji-web/README.md) 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 [MOSIP Community](https://community.mosip.io/). The community and maintainers are available to assist you. ### Deploying Inji Verify This section provides step-by-step instructions to install Inji Verify. Please follow these guidelines to make sure a successful setup in your environment. **Note:** Before deploying Inji Verify, it is recommended to always use the latest [released version](https://docs.inji.io/inji-verify/releases). Each release includes enhancements, technical upgrades, and new features to ensure the best experience. #### Understanding the Deployment Approach of Inji Verify Inji Verify is deployed as **containerized microservices** in your Kubernetes cluster. #### Deployment Architecture for Inji Verify
**Where Will It Run??** * **Target Environment**: Your main Kubernetes cluster * **Deployment Method**: Helm charts that pull Docker images from container registries * **Access Point**: Through your configured NGINX ingress at `https://injiverify.sandbox.xyz.net` **What Gets Installed?** 1. **Kubernetes Pods**: Running Inji Verify microservices 2. **Services**: For internal communication 3. **Ingress Rules**: For external access via NGINX 4. **ConfigMaps & Secrets**: For configuration and credentials #### Deployment Process of Inji Verify **Step 1: Pre-Deployment Checklist** Before deploying Inji Verify, ensure the following infrastructure components and configurations are in place as mentioned [above](#prerequisites) * [Base Infrastructure](#base-infrastructure-setup) * [Core Infrastructure](#core-infrastructure-components-setup) * [inji-stack-config ConfigMap](#inji-stack-config-for-inji-k8s-env) * [Postgres Installation](https://github.com/mosip/mosip-infra/tree/v1.2.0.2/deployment/v3/external/postgres) * Note: Before running the Postgres install script, update the POSTGRES\_HOST value in install.sh with the correct PostgreSQL host. **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** ```sh git clone https://github.com/mosip/inji-verify.git cd inji-verify/deploy ``` **Step 4: Initialize Database** Update the values file for PostgreSQL initialization as needed. ```sh cd ../db_scripts # Update init_values.yaml with your database configuration, update the necessary parameters for your PostgreSQL database. ./init_db.sh cd ../deploy ``` **Step 5: Deploy Inji Verify Microservices** ```sh ./install-all.sh ``` #### What Happens During Installation 1. **Helm Charts Execution**: Downloads and deploys Docker containers 2. **Service Registration**: Services register with config-server for configuration 3. **Database Initialization**: Creates required tables and seed data 4. **Ingress Configuration**: Configures routes through Istio gateway 5. **Health Checks**: Verifies all pods are running and healthy #### Verification Steps **Check Pod Status** ```sh kubectl get pods -n inji-verify ``` **Verify Service Endpoints** ```sh kubectl get services -n inji-verify ``` **Test External Access** ```sh curl -k https://injiverify.sandbox.xyz.net/health ``` ### Managing Inji Verify Services * **Delete all services:** ```sh ./delete-all.sh ``` * **Restart all services:** ```sh ./restart-all.sh ``` #### Important Notes * **Remote Deployment**: You deploy from your local machine to the remote K8s cluster * **Container Registry**: Docker images are pulled from public/private registries during deployment * **Configuration**: All configuration comes from your config-server and configmaps #### Success Criteria for Inji Verify Deployment **Note:** Screenshots for each success criteria step will be added shortly to provide a visual reference. 1. **Deployment Scripts Executed Successfully** * Deployment scripts (`install-all.sh`) complete without errors. * No failed Helm releases or container pull issues during deployment. 2. **Pods Running and Healthy** * All Inji Verify pods are in `Running` or `Completed` status. * Verified via `kubectl get pods -n inji-verify` 3. **Services Registered and Reachable** * Microservices are registered with the config-server. * All services are listed and accessible within the cluster `kubectl get services -n inji-verify` 4. **Database Initialized Correctly** * PostgreSQL tables and seed data are created as per `init_values.yaml`. * No database errors during initialization. 5. **Ingress Configured Properly** * Istio ingress rules are correctly applied. * Services are reachable externally through the configured gateway. 6. **External Access Verified** * Health endpoint responds successfully `curl -k https://injiverify.sandbox.xyz.net/health` * HTTP 200 response received. 7. **Service Management Functional** * Ability to restart services using `./restart-all.sh`. * Ability to delete services using `./delete-all.sh`. ### Troubleshooting If deployment fails, check: 1. **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. 2. **Prerequisites**: Ensure config-server, postgres, redis are running 3. **Resources**: Verify cluster has sufficient CPU/memory 4. **Network**: Ensure ingress and DNS are properly configured 5. **Logs**: Check pod logs for errors: `kubectl logs -n inji-verify` You can also refer to the [ReadMe](https://github.com/mosip/inji-verify/blob/develop/deploy/README.md) file for deployment steps given in individual module repositories. ## Contribution and Community We welcome contributions from everyone! Check [here](https://docs.inji.io/readme/contribution/code-contribution) 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 [MOSIP Community](https://community.mosip.io/) — we’ll be happy to help you out. *** *** # 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](https://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](https://forms.gle/ycYEPRjN66a18Pk48) 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 **** — we’re happy to connect! *** # Overview ## Overview Inji Certify enables issuers to generate, sign and issue a verifiable credentials. It follows the standard of [OpenID4VCI 1.0](https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html) Specifications (Open ID For VC Issuance). It also issues VC complaints with W3C Verifiable Credentials (1.1 & 2.0). Issuers can configure credential schemas for different certificate types, generating credentials in different VC formats such JSON-LD, SD-JWT etc. ### How is the 'Inji Certify Documentation' organised? The docs follow the typical journey: understand → try → set up → build → integrate → deploy → operate. * [**Overview**](/inji-certify/overview)**:** Get the product basics and the mental model. Subsections cover capabilities and core concepts like [Features](/inji-certify/overview/features). * [**Test**](/inji-certify/functional-overview)**:** Run a working flow end-to-end before you invest in setup. Subsections cover “Try it out”, workflow, and end-user steps. * [**Setup**](/inji-certify/build-and-deploy)**:** Get Certify running locally or in a shared environment. Subsections cover local setup and a guided deployment path. * [**Develop**](/inji-certify/technical-overview)**:** Go deeper on how Certify is built and how to extend it. Subsections cover the tech stack, architecture, supported OS, and key management. * [**API**](/inji-certify/api)**:** Use the API reference to integrate wallets, clients, and surrounding services. Expect endpoint-level details, request/response shapes, and auth expectations. * [**Deploy**](broken://spaces/aY8BQ4hdzhSchZV814Ev/pages/ZNmtG0GlL4fe4bqA0rKO)**:** Jump straight to production-style deployment instructions. This points to the Kubernetes-focused deployment guide. * [**Releases**](/inji-certify/releases)**:** Track what changed between versions and what to upgrade to. Subsections include per-version notes and test reports. ### Standards, Specifications and Compliance As an OpenID4VCI 1.0 Specification compliant issuer, Inji Certify provides the following features: | Feature | Status | Description | | --------------------------- | --------- | ----------------------------------------------------------------- | | **Issuer Metadata** | Available | Publish credential issuer configuration and supported credentials | | **Access Token Validation** | Available | Validate OAuth 2.0 access tokens for secure credential requests | | **Credential Issuance** | Available | Issue signed Verifiable Credentials to digital wallets | | **Credential Binding** | Available | DID keys and JWT proof supported; CWT proof coming soon | | **VC Formats** | Available | JSON-LD , SD-JWT and mDoc/mDL supported | | **Revocation** | Partial | JSON-LD supported; SD-JWT and mDoc/mDL coming soon | | **Credential Offer Flows** | Available | Pre-authorised and authorisation code flows | To know more about features available in Inji Certify please refer to [this documentation](/inji-certify/overview/features). ## Architecture Inji Certify features a modular architecture that supports both direct issuance and proxying of VCs from external sources. It interacts with external digital wallets via APIs. For a detailed view of Inji Certify’s architecture and components, check this [link](/inji-certify/technical-overview/architecture). ## Plugin Support Inji Certify provides a **plugin-based architecture** that enables modular, extensible, and customizable credential issuance workflows. ### Types of Plugins * **VC Issuance Plugins** Handle the retrieval and alignment of Verifiable Credentials (VCs) as per standards, and manage the issuance process. * **Data Provider Plugins** Fetch raw data from various sources, generate the credential, sign it, and issue it. * Currently supported integrations: PostgresSQL and CSV files. ## Deployment Inji Certify supporting two mode of deployment to cater different users with different purpose: 1. Local Development Setup 2. Deployment with Kubernetes cluster If you are creating your own custom plugin, you can refer to [this link](https://github.com/mosip/inji-certify/blob/master/docs/Custom-Plugin-K8s.md) to know steps to deploy custom plugins using kubernetes. ## Documentation * **API Documentation:** API endpoints, base URL (`/v1/certify`), and mock server details are available via Stoplight and Swagger documentation: Inji Certify API Documentation. * **Product Documentation:** * To know more about Inji Certify in the perspective of functional and use cases you can refer to our main document: [Overview | Inji](https://docs.inji.io/inji-certify/overview) * Inji Certify is part of Inji Stack, to know more about Inji Stack you can refer to our stack document: [Inji | Inji](https://docs.inji.io/) ## Contribution & Community We welcome contributions from everyone! * [Check here](https://docs.inji.io/readme/contribution/code-contribution) 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 [MOSIP Community](https://community.mosip.io/) — we’ll be happy to help you out. # Features Inji Certify comes with a comprehensive suite of features designed to make credential issuance seamless, secure, and standards-compliant. Key features include: ## 1. Standards Based Credential Issuance Inji Certify is built to issue digital credentials that are fully compliant with globally recognized standards, ensuring interoperability across systems and jurisdictions. It: * Supports **W3C Verifiable Credentials Data Model (versions 1.1 and 2.0)** for secure, portable, and verifiable documents * Implements **OpenID for Verifiable Credential Issuance (OpenID4VCI)** for seamless and secure delivery of credentials to digital wallets * Ensures interoperability across systems and jurisdictions ## 2. Multiple Credential Support for Issuers Inji Certify allows a single issuer to manage and issue multiple types of verifiable credentials within the same ecosystem. This is especially useful for organizations running diverse programs or services under one authority. **Example scenarios:** * A **Transport Authority** issuing both *Driver's Licenses* and *Commercial Vehicle Permits* * A **University** issuing *Student ID Cards*, *Degree Certificates*, and *Transcript Credentials* * A **Health Department** issuing *Vaccination Certificates* and *Medical Practitioner Licenses* * A **Border Control Agency** issuing *Cross-Border Transport Passes* and *Work Permits* This flexibility ensures that one issuer can cater to multiple credentialing needs without managing separate systems or infrastructures. ## 3. Addition of Credential Type via API Post Onboarding Inji Certify enables issuers to expand their credential portfolio even after the initial onboarding, ensuring they can respond quickly to evolving program or policy needs. Through secure APIs, issuers can create and configure new credential types without system downtime or complex redeployments. **Key capabilities include:** * **Post-onboarding expansion** of credential types to support new use cases * **API-driven setup** for fast and seamless integration into existing workflows * **No infrastructure changes required**, minimizing operational overhead Access to comprehensive **documentation and guidelines** — *(refer to this* [*link*](https://github.com/mosip/inji-certify/blob/master/docs/Credential-Issuer-Configuration.md#credential-configuration) *for details on configuring VC types)*. ## 4. Support for Multiple Credential Formats Inji Certify provides issuers with the capability to generate verifiable credentials in multiple **industry-accepted formats**, ensuring broad interoperability across ecosystems, wallets, and verification systems. This flexibility makes it easier for organizations to adopt digital credentials without being locked into a single standard. **Currently supported formats:** * **JSON-LD Credentials** — Standards-based credentials using Linked Data Proofs, widely adopted in decentralized identity ecosystems for interoperability and verifiability * **Signed JWT (JWS)** — Compact, JSON-based credentials that enable efficient transmission and verification across web and enterprise systems * **SD-JWT (Selective Disclosure JWT)** — Privacy-preserving credentials that allow holders to selectively disclose attributes while keeping the rest private, **Note:** With the Inji Certify 0.13.0 release we have included full Insupport for SD-JWT. * **mDoc (ISO 18013-5/7)** — A mobile document format for secure, offline-verifiable digital documents * **mDL (ISO 18013-5/7)** — A mobile driver's license format, enabling secure and convenient digital driver's license presentation on mobile devices By supporting both **current and emerging standards**, Inji Certify ensures that credentials are **secure, future-ready, and interoperable** with a wide range of applications, wallets, and verification ecosystems. ## 5. Efficient Signing with Multiple Algorithms Inji Certify ensures that every credential is protected through **digital signatures**, guaranteeing authenticity, integrity, and tamper resistance. To meet diverse ecosystem and compliance needs, it offers issuers the flexibility to choose from a wide range of cryptographic signing algorithms. **Key capabilities include:** * **Configurable Signing Algorithms** — Issuers can select the signing algorithm of choice during credential setup * **Supported Options** — Includes **RSA**, **Ed25519 (2018 & 2020 specs)**, and **Elliptic Curve (ECC K1 & R1)** * **Enhanced Cryptographic Flexibility** — Support for Ed25519 and ECC Curve ensures compatibility with modern secure systems, broader wallet ecosystems, and evolving standards * **Standards Compliance** — All signatures are interoperable and verifiable across wallets and verification systems * **Security and Adaptability** — Enables issuers to stay aligned with cryptographic best practices and adapt to regional or program-specific security requirements This combination of efficiency, flexibility, and compliance ensures that credentials issued through Inji Certify remain future-ready, secure, and widely interoperable. ## 6. Plugin Support and Integration Capabilities Inji Certify is built on a **modular plugin architecture**, enabling seamless integration with identity systems, registries, data sources, and third-party services. This design makes the platform highly flexible, customizable, and easy to adopt across diverse ecosystems while simplifying both implementation and testing. **Key plugin categories include:** ### VC Issuance Plugins These plugins are responsible for generating and signing verifiable credentials. They typically connect with external identity or authentication systems, obtain the required information, and issue the VC in compliance with global standards. **Currently supported issuance plugins:** * **Sunbird Plugin** — Enables seamless integration with Sunbird-based services ### Data Provider Plugins Data Provider Plugins are responsible for fetching relevant data from external registries or data sources. The retrieved data is returned in JSON format and is used by Inji Certify to construct and issue the corresponding Verifiable Credential (VC). The data source for these plugins can be a database, a CSV file, or an external API. **Currently supported Data Provider Plugins include:** * **Mock IDA Plugin** — Provides a simulated identity data and verification environment for testing and development purposes * **Mock CSV Data Provider Plugin** — Enables data retrieval from CSV files, primarily for sandbox and test data simulation * **PostgreSQL Data Provider Plugin** — Connects to PostgreSQL databases to fetch real-time data from registries or external systems * [**MOSIP Identity Plugin**](/inji-certify/overview/features/issuance-of-national-id-as-verifiable-credentials-using-mosip-identity-plugin) — Integrates with MOSIP APIs to retrieve identity data and construct Verifiable Credentials within Inji Certify For detailed instructions on configuring the Data Provider Plugin, please refer to this [guide](https://github.com/mosip/inji-certify/blob/master/docs/Local-Development.md). Issuers can easily integrate additional custom plugins by following the detailed guidelines provided in this [link](https://github.com/mosip/inji-certify/blob/master/docs/Custom-Plugin-K8s.md). This extensible plugin framework ensures that Inji Certify can adapt to unique organizational needs without heavy customization. To know more about this feature please refer to this link: [VC Issuance vs Data Provider Plugin](https://github.com/mosip/inji-certify/blob/master/docs/VCIssuance-vs-DataProvider.md). ## 7. Revocation Mechanism (JSON-LD Only) Inji Certify introduces an initial implementation of revocation to enhance the trust and reliability of Verifiable Credentials (VCs). **Capabilities include:** * **Revocation List** — Maintains a list of revoked JSON-LD credentials * **Revocation API** — Allows issuers to mark JSON-LD credentials as revoked * **Verification API** — Enables verifiers to check whether a JSON-LD credential is valid or revoked * **Discovery API** — Provides access to the most up-to-date revocation list This release establishes the foundation for a standardized revocation mechanism in Inji Certify, with broader credential format support planned in future iterations. Click [here](https://github.com/mosip/inji-certify/blob/master/docs/VC-Revocation-Support.md) to know more about this feature. ## 8. Ledger for Issued Verifiable Credentials Inji Certify includes an optional ledger that records every Verifiable Credential (VC) issued by the system. When enabled, this ledger provides a searchable index of issued credentials, making it easier for issuers to track, audit, and manage credentials throughout their lifecycle. **Why it matters:** The ledger simplifies operations such as revocation, where the system must quickly locate the credential being revoked. With indexed search support, issuers can retrieve credentials efficiently without maintaining an external lookup system. **Key Capabilities:** * **Configurable Recording** — Issuers can choose whether or not to maintain an internal record of all issued VCs. * **Indexed Search** — The ledger supports searching issued credentials based on predefined indexes, enabling faster retrieval. * **Revocation Support** — When revocation is enabled, the ledger must be active, unless the issuer provides an external system capable of performing credential lookup. **Considerations:** If the issuer intends to use Inji Certify's built-in revocation workflow, the ledger feature must be turned on. Otherwise, the issuer is responsible for implementing their own mechanism to locate credentials during revocation. ## 9. SVG Rendering Support Inji Certify provides support for **SVG-based credential rendering**, ensuring wallets can display visually consistent and branded representations of issued credentials. **Why it matters:** With SVG rendering support powered by the renderMethod metadata and defined templates, Certify ensures that **every credential not only carries trust and verifiability, but also a consistent, secure, and issuer-branded visual identity** across all wallets. **How it works:** * **renderMethod in Metadata** — Certify includes a renderMethod parameter within the credential metadata, instructing wallets on how the credential should be visually rendered **Key Benefits:** * **Consistent Branding** — Logos, colors, and layouts can be issuer-defined, ensuring uniform credential presentation across different wallets * **Scalable & Device-Friendly** — SVG ensures high-quality rendering on any screen size, from mobile devices to large displays * **Wallet Interoperability** — By embedding the rendering method in the credential metadata, any compliant wallet can render credentials without custom logic * **Flexible Output** — Wallets can convert rendered SVGs into other formats (PNG, PDF) for sharing or offline use Please refer this [guide](https://github.com/mosip/inji-certify/blob/master/docs/Rendering-Template.md) to know more about this feature. ## 10. External Authentication Integration Inji Certify provides support for integrating with external authentication services compliant with OAuth 2.0, such as eSignet, Keycloak, and others. This allows issuers to leverage existing identity and access management solutions seamlessly. **Why it matters:** By supporting external authentication providers, Certify enables issuers to adopt the authentication mechanism that best fits their ecosystem requirements. This ensures flexibility, stronger security, and compliance with existing organizational standards. **How it works:** * **OAuth 2.0 Compliance** — Certify connects with external authentication services that follow the OAuth 2.0 standard * **Configurable Integration** — Issuers can configure Certify to integrate with different authentication providers based on their needs (e.g., eSignet for government deployments, Keycloak for open-source identity management, or other OAuth 2.0 providers) * **Seamless Authorization** — Once integrated, the external service handles user authentication, and Certify issues credentials only after successful authorization **Key Benefits:** * **Flexibility** — Issuers can choose and configure the authentication provider that suits their ecosystem * **Enhanced Security** — Leverages robust, battle-tested external identity providers for authentication * **Standards-Based** — OAuth 2.0 compliance ensures interoperability with widely adopted identity solutions * **Customizable per Issuer** — Different issuers can configure different authentication services within the same Certify deployment ## 11. VC Signing with External CA-Signed Certificates Inji Certify supports the use of externally issued, CA-signed certificates for credential signing, enabling issuers to integrate their own public key infrastructure (PKI) into the credential issuance workflow. **Key Benefits** * Trust Alignment — Credentials are signed using the issuer’s own CA-backed certificates, reinforcing alignment with local or institutional PKI policies. * Greater Adoption Flexibility — Countries and organizations can adopt Certify without restructuring their existing certificate management models. * Seamless Compliance — Using a recognized CA certificate simplifies audits and compliance checks by matching established trust and governance frameworks. * End-To-End Security — The signing process remains fully managed through the Key Manager, ensuring secure key handling while maintaining issuer-specific trust anchors. To explore the full workflow and configuration, refer to the [detailed feature document.](https://github.com/mosip/inji-certify/blob/release-0.13.x/docs/PKI-Support-and-Integration-with-SD-JWT-VC.md) For deeper insights into certificate and key lifecycle handling, see the documentation on the [Role of the Key Manager](/inji-certify/technical-overview/key-manager) in Certify. ## 12. Multi language support Inji Certify have capability to issue VC in multiple language based on the configuration done by issuer. During the VC type configuration, VC schema can be defined in multiple languages. While issuing the VC, based on the preferred language of the user, VC will be issued in that particular language. ## 13. Presentation During Issuance Inji Certify introduces support for an additional issuance mode called [Presentation During Issuance](/inji-certify/overview/features/presentation-during-issuance), enhancing trust and security in credential issuance workflows. In this mode, the issuer requests the presentation of an existing Verifiable Credential (VC) from the wallet as part of issuing a new VC. The submitted presentation is verified internally by Inji Certify, and upon successful verification, the issuance of the new VC is triggered and delivered to the wallet. This feature strengthens security, trust, and interoperability and is typically enabled using protocols such as OpenID4VCIand standards like Presentation Exchange. **Capabilities include**: * Presentation Request — Ability to request the presentation of an existing VC from the wallet * Presentation Verification — Internal verification of the submitted VC presentation * Conditional Issuance — Automatic issuance and delivery of a new VC upon successful verification 'Inji Certify 0.14.0 Release' lays the groundwork for advanced, trust-based issuance flows in Inji Certify, enabling richer and more secure credential ecosystems. ## 14. Issuance of Verifiable Credentials with QR code Inji Certify introduces '[Issuance of Verifiable Credentials with QR code](/inji-certify/overview/features/issuance-of-verifiable-credentials-with-qr-code)' support for QR-code-based VC issuance using [**169 - QR Code Specifications 1.1.0**](https://docs.mosip.io/1.2.0/readme/standards-and-specifications/mosip-standards/169-qr-code-specification-1), enabling privacy-preserving and interoperable credential issuance directly via standardised, compact QR codes. With this feature, Inji Certify can generate verifiable credentials that are encoded into CBOR Web Token (CWT) form and delivered through QR codes compliant with [**Claim 169 specifications**](https://docs.mosip.io/1.2.0/readme/standards-and-specifications/mosip-standards/169-qr-code-specification-1) — a specification for embedding identity data in QR codes that supports compact, secure, and machine-readable representation of credential data. This capability allows wallets and other consumer applications to request and obtain credentials by scanning a Claim 169-formatted QR code, improving usability in offline or low-connectivity environments and ensuring alignment with an interoperable QR standard. **Capabilities include**: * Claim 169 QR Generation — Ability to encode issued VCs into [Claim 169](https://docs.mosip.io/1.2.0/readme/standards-and-specifications/mosip-standards/169-qr-code-specification-1)–compliant QR codes * CBOR-CWT Encoding — Support for compact, privacy-preserving CBOR Web Token encoding of VC data * Standard-Based Issuance — Delivery of QR-encoded credentials that adhere to global standards for machine-readable identity 'Inji Certify 0.14.0 Release' expands Inji Certify’s issuance modalities to include QR code–centric workflows using standardised Claim 169 structures, enhancing accessibility and interoperability with ecosystem wallets and verification tools. ## 15. VC Issuance with pre authorised code (Pre Auth Code Flow) Inji Certify introduces support for the [Pre-Authorized Code Flow with Credential Offer](/inji-certify/overview/features/vc-issuance-with-pre-authorised-code-and-credential-offer), enabling streamlined and user-friendly issuance of Verifiable Credentials (VCs). This feature implements the OpenID4VCI pre-authorized code flow, where Inji Certify can issue a credential offer containing a pre-authorized code that the wallet uses to obtain an access token and then request a VC — without requiring the end user to re-authenticate during the issuance process. This flow is ideal for scenarios where the issuer has already verified the user’s identity and wants to simplify credential delivery. With this enhancement, credential offers can be delivered via QR codes, deep links, or other channels, and wallets can redeem them with or without an additional transaction code (PIN). **Capabilities include**: * Pre-Authorized Credential Offers — Generate offers that embed a pre-authorized code to streamline issuance. * Standards-Based Flow — Implements the OpenID4VCI flow for credential offer redemption and issuance. * Flexible Delivery — Support for multiple delivery methods such as QR codes and deep links. * Transaction Code Support — Optional support for requiring a PIN/transaction code during credential redemption. 'Inji Certify 0.14.0 Release' enhances Inji Certify’s interoperability with OpenID4VCI ecosystems and improves the user experience for VC issuance in trusted workflows. ## Read More Check [Inji Certify Repository](https://github.com/mosip/inji-certify/tree/master) to explore the features listed and explained above. # National ID VC Issuance ### Overview The UIN Issuance capability in **Inji Certify 0.14.0** introduces a flexible and extensible approach to credential issuance by decoupling dependency on the traditional IDA system and enabling dynamic data retrieval through a new **IDA Data Provider Plugin**. This enhancement allows Certify to fetch raw KYC data, transform it into Verifiable Credentials (VCs), and support multiple cryptographic key types and signing algorithms aligned with MOSIP standards. Instead of relying on a fixed IDA-driven issuance flow, Certify now leverages a plugin-based architecture where external data sources (such as IDA APIs) can be integrated seamlessly. This enables greater control over credential structure, claim mapping, localization, and signing behavior, making the issuance process more adaptable across different country implementations. ### Why This Feature Matters The introduction of the IDA Data Provider Plugin and enhanced issuance flow brings several key benefits: * **Flexible Data Integration:** Allows Certify to fetch raw KYC data directly from IDA APIs, enabling custom credential structures instead of relying on predefined formats. * **Expanded Cryptographic Support:** Supports multiple key types such as RSA, EC R1, ECK1, and ED, overcoming earlier limitations where only RSA-based signing was supported. * **Improved Customization:** Enables dynamic mapping of claims using templates, including support for custom claims and localized attributes (e.g., multi-language names and addresses). * **Decoupled Architecture:** Separates data fetching from credential issuance using plugin models, making the system more modular and extensible. * **Enhanced Trust & Verification:** Supports country-specific signing keys with public key verification via DID URLs, allowing issuers to validate credential authenticity independently. * **Operational Resilience:** Automatically falls back to internal key manager certificates if external signing certificates expire, ensuring uninterrupted issuance. * **Optimized QR Code Generation:** Introduces image compression via the kernel biometric API to efficiently embed photos in QR codes without performance issues. ### How It Works – Step-by-Step (Certify Perspective) The following sequence describes how Inji Certify handles UIN-based credential issuance using the new plugin-driven architecture: #### 1. Certify Initiates Data Fetch via Plugin Certify invokes the **IDA Data Provider Plugin**, which implements the DataProviderPlugin interface. The plugin uses the fetchData method to construct a request containing: * Individual ID (UIN/VID) * Required claims This request is sent to the IDA KYC Exchange API. #### 2. Authentication via OIDC The plugin retrieves an access token through an OIDC flow: * Token is obtained using e-Signet integration * Cached authentication context is used to optimize performance * Individual ID is retrieved from cache (optionally encrypted based on configuration) #### 3. KYC Data Retrieval The IDA API responds with a JSON payload containing KYC attributes such as: * Name * Gender * Address * Photo The plugin forwards this data to Certify for processing. #### 4. Claim Mapping & Credential Preparation Certify maps the retrieved KYC data into VC claims using configurable templates: * OIDC claims are transformed into VC-compatible structure * Localization is applied where available (multi-language fields) * Custom claims can be injected via mapping and policy configurations #### 5. Individual ID Processing Certify determines the type of identifier: * UIN or VID is inferred based on format/length using regex or policy rules * Encryption settings are applied based on configuration (secure vs non-secure storage) #### 6. Credential Signing Configuration Certify prepares the credential for signing: * Selects signing key (country-provided or internal key manager) * Supports multiple key types (RSA, EC, ED, etc.) * Publishes the public key via DID URL for external verification #### 7. Credential Issuance Certify generates the Verifiable Credential: * Applies the configured template and claims * Signs the credential using the selected key * Embeds compressed photo (if required for QR code) The credential is then returned to the requesting wallet or system. #### 8. Verification & Key Handling * Countries can verify issued credentials using the public key exposed via DID URL * If a country-specific certificate expires: * Certify automatically switches to internal key manager * No issuance disruption occurs * Responsibility remains with the country to rotate certificates ### Security Considerations **Secure Data Handling:** Sensitive identifiers (UIN/VID) can be encrypted based on configuration, though compatibility with e-Signet must be ensured. **OIDC-Based Authentication:** All KYC data requests are secured via access tokens obtained through OIDC flows. **Key Transparency & Trust:** Public keys published via DID URLs allow independent verification of credential signatures. **Certificate Lifecycle Management:** Automatic fallback ensures continuity, but proper monitoring and renewal of certificates is critical. ### Limitations * Encryption of individual ID may require careful alignment between e-Signet and Certify configurations. * Localization support depends on consistency of input data (e.g., language-tagged attributes). * Custom claim configuration requires validation of supported mapping properties. * Logging and alerting for certificate fallback behavior need further verification. ### Supported Capabilities * IDA API-based KYC data retrieval via plugin * Support for multiple signing algorithms and key types * Template-driven VC generation with localization support * QR code optimization with compressed images * DID-based public key exposure for verification Please refer to the relevant [GitHub technical documentation](https://github.com/inji/inji-certify/tree/master/docs) for detailed configuration, policy setup, and API‑level implementation details. # Pre-Authorized Issuance ### Overview The **Pre-Authorized Code Flow with Credential Offer** enhances the credential issuance experience by enabling wallets to obtain Verifiable Credentials (VCs) directly using a *pre-authorized code* embedded in a credential offer. This flow is part of the OpenID for Verifiable Credential Issuance (OpenID4VCI) standard, designed to streamline issuance where the issuer has already authenticated the user or established user context outside of the standard interactive authentication flow. In this flow, the Credential Issuer prepares and issues a *Credential Offer* that contains: * Credential metadata * Issuer endpoints * A *pre-authorized code* that the wallet can exchange for an access token The wallet then uses this pre-authorized code to securely request the VC from the issuer without requiring the user to authenticate again through a separate interactive login step. ### Why This Feature Matters The Pre-Authorized Code Flow brings several advantages: * **Seamless User Experience:** Eliminates the need for end-user interactive authentication (e.g., signing in) during VC issuance when prior authentication is already completed by the issuer. * **Flexible Delivery:** Credential Offers can be delivered via QR codes, deep links, or other channels, enabling both same-device and cross-device issuance experiences. * **Optional Transaction Code:** Issuers can require an additional user transaction code (PIN), adding an extra factor of security during issuance. * **Interoperability:** Aligns with OpenID4VCI standards, improving compatibility with other identity systems and wallets. ### How It Works – Step-by-Step (Certify Perspective) The following sequence describes how **Inji Certify** handles credential issuance using the Pre-Authorized Code Flow. #### 1. Certify Prepares the Credential Offer Inji Certify collects the required user claims and generates a **Credential Offer** containing: * A pre-authorized code * Credential metadata * Issuer endpoints The credential offer is exposed as a **URI** which can be sent to the user as notification or other modes. #### 2. Certify Exposes Issuer Metadata When the wallet processes the credential offer, it requests issuer metadata from Certify’s .well-known endpoint. Certify responds with discovery information, including: * Supported credential configurations * Token endpoint details * Credential endpoint details * Required parameters for token exchange This enables the wallet to understand how to interact with Certify for issuance. #### 3. Certify Receives Token Request Certify receives a back-channel token request from the wallet at the Token Endpoint. The request includes: * The pre-authorized code * An optional transaction code (PIN), if configured Certify validates the pre-authorized code and, where applicable, verifies the transaction code before proceeding. #### 4. Certify Issues Access Token Upon successful validation, Certify issues an **access token** to the wallet. This token authorizes the wallet to request the verifiable credential. #### 5. Certify Issues the Verifiable Credential Certify receives a credential request from the wallet at the Credential Endpoint, secured using the access token. Certify validates the token, constructs the Verifiable Credential based on the requested configuration, and returns the issued VC to the wallet. The wallet then securely stores the credential for the holder’s use.
### Security Considerations * **Replay Attacks:** Because the pre-authorized code can be replayed if disclosed publicly, issuers may enforce mitigations such as PIN requirements or time-limited codes. * **Metadata Validation:** Wallets must validate issuer metadata before proceeding with token exchanges to prevent malicious credential offers. ### Limitations * Client authorisation is not supported. Therefore, only a single issuance mode can be configured for an issuer. For example, if an issuer is configured to issue Verifiable Credentials using the pre-authorised flow, other modes—such as wallet-initiated issuance—will not be supported. ### Supported Issuance Modes * Pre-Authorized Code Flow **without PIN** – direct token exchange using pre-authorized code * Pre-Authorized Code Flow **with PIN** – token exchange requires both a pre-authorized code and a user transaction code Please refer to this [link](https://github.com/inji/inji-certify/tree/master/docs) to know more about the technical design and configuration. # Presentation During Issuance ### Overview The **Presentation During Issuance (PDI)** feature enhances the credential issuance experience by allowing Inji Certify to request and verify an existing Verifiable Credential (VC) from the holder’s wallet as a mandatory step before issuing a new VC. This feature is aligned with the OpenID for Verifiable Credential Issuance (OpenID4VCI) and OpenID for Verifiable Presentations (OpenID4VP) standards. In this flow, the issuer enforces a verification step during issuance, where the wallet is required to present a specific credential to validate the holder’s eligibility before issuing a VC. This approach ensures that issuance is conditional, secure, and user‑consented, while avoiding reliance on external or offline verification mechanisms. ### Why This Feature Matters Presentation During Issuance brings several advantages: * **Stronger Trust at Issuance:** Ensures that sensitive credentials (eg: Driving Licenses ) are issued only after validating an authoritative credential (eg: National ID). * **User‑Centric Verification:** The holder presents credentials directly from their wallet with explicit consent. * **Reduced Backend Dependencies:** Eliminates the need for additional backend integrations or manual checks for eligibility verification. * **Standards Alignment:** Leverages OpenID4VCI and OpenID4VP, improving interoperability across issuers and wallets. * **Privacy by Design:** Credentials are shared only for verification purposes and are not persisted beyond the issuance transaction. ### How It Works – Step‑by‑Step (Certify Perspective) The following sequence describes how Inji Certify handles Driving License issuance using the Presentation During Issuance feature. #### 1. Certify Receives Issuance Request The resident initiates the download of a **Driving License VC** from the Inji Wallet. The wallet sends an issuance request to Inji Certify using the supported OpenID4VCI issuance flow. Certify evaluates the issuance policy and determines that **National ID verification is mandatory** for Driving License issuance. #### 2. Certify Sends Presentation Request Inji Certify prepares and sends a **Presentation Request** to the wallet, specifying: * Required credential type: **National ID VC** * Required claims or attributes (if applicable) * Challenge / nonce to prevent replay attacks This request instructs the wallet to present a valid National ID credential before issuance can proceed. #### 3. Wallet Collects User Consent and Credential Upon receiving the presentation request: * The wallet discovers available credentials that satisfy the request * The resident is prompted to select their **National ID VC** * The wallet constructs a **Verifiable Presentation (VP)**, signed using the holder’s proof The generated VP is then submitted to Inji Certify. #### 4. Certify Verifies the Presentation Inji Certify validates the received Verifiable Presentation by performing: * Cryptographic signature verification * Issuer trust validation * Credential schema and claim validation * Expiry and revocation status checks * Nonce and challenge verification Only upon successful verification does Certify proceed further. #### 5. Certify Issues the Driving License VC After successful presentation verification: * Certify constructs the **Driving License Verifiable Credential** * The credential is issued to the wallet via the credential endpoint The wallet securely stores the issued Driving License VC for the resident’s use. #### 6. Issuance Completion The resident can now view and use the **Driving License VC** from their wallet. If verification fails at any stage, the issuance is terminated and an appropriate error is returned.
### Security Considerations * **Replay Protection:** Presentation requests include nonces and challenges to prevent replay attacks. * **Explicit User Consent:** Wallet requires user approval before sharing any credential. * **Minimal Disclosure:** Only required credentials and claims are requested for verification. * **No Persistent Storage:** Presented credentials are not stored beyond the verification process. ### Limitations * Client‑based authorization is not supported. * Only a single issuance mode can be configured per issuer. * If Presentation During Issuance is enabled, alternative issuance modes (e.g., simple wallet‑initiated issuance without verification) are not supported for the same issuer.) Please refer to the relevant [GitHub technical documentation](https://github.com/inji/inji-certify/tree/master/docs) for detailed configuration, policy setup, and API‑level implementation details. # Issuing VC with QR Code ### **Overview** The QR Code Embedded Verifiable Credential feature enhances the usability and privacy of digital identity by enabling Inji Certify to generate Verifiable Credentials (VCs) with embedded QR codes containing selectively disclosed identity attributes. Each QR code encapsulates identity data encoded as a CBOR Web Token (CWT), aligned with Claim 169 specifications. This allows verifiers to scan a QR code and validate only the required attributes without accessing the complete Personally Identifiable Information (PII). This feature is aligned with the W3C Verifiable Credentials Data Model and supports interoperable, privacy-preserving verification using standardized QR encoding mechanisms. ### **Why This Feature Matters** QR Code Embedded VC brings several advantages: * **Privacy by Design**: Enables selective disclosure, ensuring only required attributes are shared. * **Improved User Experience**: Simplifies verification through QR scanning without full credential sharing. * **Offline Verification Support**: QR codes enable verification even in low-connectivity environments. * **Standards Compliance**: Aligns with [Claim 169](https://docs.mosip.io/1.2.0/readme/standards-and-specifications/mosip-standards/169-qr-code-specification-1), CBOR, and CWT specifications. * **Flexible Configuration**: Issuers can define multiple QR codes with different attribute sets. ### **How It Works – Step-by-Step (Certify Perspective)** The following sequence describes how Inji Certify generates a Verifiable Credential with embedded QR codes. #### **1. Issuer Configures QR Settings** During VC type onboarding, the issuer configures: * Number of QR codes * Attributes included in each QR * Label or purpose of each QR (e.g., Age Verification, Identity Verification) These configurations are stored in the system and used during VC generation. #### **2. Certify Receives Issuance Request** The wallet initiates a VC download request. Certify: * Validates the request and authentication * Identifies the VC configuration, including QR settings #### **3. Data Retrieval and Image Processing** Certify retrieves identity data through the data provider plugin. If required: * Face image is compressed and optimized * Converted into Base64 format for embedding #### **4. QR Data Preparation** Based on configuration: * Certify selects the required attributes for each QR * Prepares structured data for QR generation The data is passed for QR encoding. #### **5. QR Encoding** The QR data is processed to: * Map attributes to Claim 169 numeric keys * Convert data into CBOR format * Encode the payload for secure transport #### **6. QR Signing (CWT Generation)** The encoded QR payload is: * Enriched with metadata such as issuer and expiry * Signed using the issuer’s configured algorithm * Converted into a CWT (CBOR Web Token) #### **7. VC Construction** Certify constructs the Verifiable Credential by: * Embedding QR codes (CWT values) * Adding identity attributes and metadata * Applying the configured template #### **8. VC Signing and Packaging** The complete VC is digitally signed to ensure integrity and authenticity. Supported formats include: * JSON-LD (W3C VC) * mDoc (ISO standards) * SD-JWT * JWT VC #### **9. Delivery to Wallet** The signed VC is sent to the wallet. The resident can: * Store the VC * Use embedded QR codes for verification ### **Feature Flow Chart** Refer to the architecture and sequence diagrams for detailed flow of QR data preparation, encoding, signing, and embedding within the VC.
### **Security Considerations** * **Selective Disclosure**: Only configured attributes are shared via QR * **Data Integrity**: QR payload is signed as a CWT * **Key Security**: Private keys are securely managed * **Minimal Exposure**: Full identity data is not shared during verification * **Image Optimization**: Biometric images are compressed to reduce payload size ### **Core Behaviors** #### **Multiple QR Codes** * Supports embedding multiple QR codes in a single VC * Each QR represents a specific verification purpose #### **Claim 169 Alignment** * QR payload follows Claim 169 mapping * Attributes are mapped to numeric identifiers as per IANA registry #### **Configurable Attribute Mapping** Issuers can define: * Attributes per QR * Attribute order * QR labels #### **Biometric Support** * Supports embedding biometric data (e.g., face image) * Image is compressed and Base64 encoded #### **QR Constraints** * QR version supported up to 23 * Face image size should be within configured limits (recommended <1KB) ### **Additional Considerations** | Aspect | Requirement | | ---------------- | ------------------------------------------------------ | | Revocation | VC may include reference to status list (out of scope) | | Versioning | Claim 169 version maintained in configuration | | Security | All QR payloads must be signed as CWT | | Interoperability | Compliant with W3C VC and MOSIP context | | Performance | Designed for scalable QR generation | ### **Limitations** * Revocation validation via QR is not supported * Claim 169 currently supports only English * Mapping of custom fields outside Claim 169 requires external handling * Offline mapping resolution is dependent on external mechanisms * QR payload size constraints may limit data inclusion * VC format supported is only JSON-LD Please refer to the relevant [GitHub technical documentation](https://github.com/inji/inji-certify/tree/master/docs) for detailed configuration, policy setup, and API‑level implementation details. # Test This section is for **hands-on exploration** and **user-facing flows** in Inji Certify. Use it when you want to validate an end-to-end issuance journey. You’ll find quick reference diagrams and functional overview. * [Workflow](/inji-certify/functional-overview/workflow): End-to-end sequence of how issuance works in Certify. * [Functional Overview](/inji-certify/functional-overview/functional-overview): Concepts, plugins, and how Certify fits together. # Try It Out Get a working Inji Certify flow up and running. Use this guide to run an end-to-end **Inji Certify** issuance flow. You’ll start from a running Certify instance. You’ll end with a credential downloaded in a wallet. ### What you’ll do * Bring up Inji Certify locally. * Configure a sample issuer and credential type. * Request and receive a credential from a wallet. ### Prerequisites * A working Inji Certify deployment. * Access to the Certify APIs. If you don’t have Certify running yet, start with [Local Setup](/inji-certify/build-and-deploy/local-setup). ### Next steps * Read the [Workflow](/inji-certify/functional-overview/workflow) to understand the moving parts. * Follow the [End User Guide](/inji-certify/functional-overview/end-user-guide) for the wallet-side steps. * Use the [API](/inji-certify/api) docs to issue credentials programmatically. # Workflow ## Workflow ```mermaid sequenceDiagram participant Client as 🌐 Client participant AuthN_AuthZ as 🔑 AuthN/AuthZ box Inji Certify #E6F3FF participant CredentialAPI as 🔗 Credential API participant TemplateEngine as ⚙️ Template Engine participant VCSigner as 🔏 VC Signer participant TemplateDB as 💾 Template Store end participant VCIssuancePlugin as 🔌 VC Issuance Plugin participant DataProviderPlugin as 🔌 Data Provider Plugin participant ExternalIssuer as 🏦 Ext. Issuer Note over VCIssuancePlugin: External Plugin Note over DataProviderPlugin: External Plugin Client->>AuthN_AuthZ: Authentication Request (OAuth2/OIDC) AuthN_AuthZ-->>Client: Authentication Response (Token) Client->>CredentialAPI: Request VC Issuance (OIDC4VCI) with Token alt Issuer Mode (DataProviderPlugin) CredentialAPI->>DataProviderPlugin: Request Data Note right of DataProviderPlugin: Get Data DataProviderPlugin-->>CredentialAPI: Return Raw Data CredentialAPI->>TemplateDB: Fetch Credential Template TemplateDB-->>CredentialAPI: Return Template CredentialAPI->>TemplateEngine: Process Template with Raw Data TemplateEngine-->>CredentialAPI: Return unsigned Credential Data CredentialAPI->>VCSigner: Sign Credential Note right of VCSigner: Sign VC VCSigner-->>CredentialAPI: Return Signed VC else Proxy Mode (VCIssuancePlugin) CredentialAPI->>VCIssuancePlugin: Forward Request Note right of VCIssuancePlugin: Internal Process:
1. Get VC from Ext. Issuer VCIssuancePlugin->>ExternalIssuer: Request VC ExternalIssuer-->>VCIssuancePlugin: Return Signed VC VCIssuancePlugin-->>CredentialAPI: Return Signed VC end CredentialAPI-->>Client: Return Final VC (OIDC4VCI) ``` ## Overview Inji Certify is a platform designed to manage and facilitate the issuance of Verifiable Credentials (VCs). It features a modular architecture that supports both direct issuance and proxying of VCs from external sources. It interacts with external digital wallets via APIs. The workflow for credential issuance in the described scenario can be summarized as follows: ### Digital Wallet (External) * Description: Digital wallets are external applications used by users to store and manage their VCs. Inji Certify does not include a built-in wallet. Instead, it provides APIs for seamless integration with various wallet providers. #### API Layer * Description: This layer serves as the entry point for all interactions with Inji Certify, including requests from external Digital Wallets. It handles routing, authorization (using OAuth2 OpenID Connect), and request validation. #### Core Layer (Internal Components within the Blue Box) This section comprises the core components responsible for VC processing: * **VC Signer**: * Description: Digitally signs Verifiable Credentials to guarantee authenticity and integrity. * **Template Engine**: * Description: Manages templates for different VC types, populating them with data before signing. * **Keymanager Service**: * Description: Securely stores and manages the cryptographic keys used for signing VCs. #### Data Sources Layer (Bottom Left)\*\* * **Description**: This layer encompasses the databases and data stores holding the information required to generate VCs in "issuer mode". #### Plugins (Middle Bottom) Inji Certify operates in two primary modes via its plugin system: * **Issuer Mode (using Data Provider Plugin)**: * **Data Provider Plugin**: Retrieves data from various sources (databases, APIs, etc.) to populate VC templates. In this mode, Inji Certify generates and issues VCs directly. * **Proxy Mode (using VC Issuance Plugin)**: * **VC Issuance Plugin**: Handles the specifics of proxying VCs issued by external sources. In this mode, Inji Certify does not generate the VC itself, but acts as a conduit for VCs issued elsewhere. * **Audit Plugin**: Logs all significant events related to VC Issuance and other events. #### External Verifiable Credentials Issuers (Bottom Right) **Description**: Represents external entities that issue VCs. Inji Certify can operate in "proxy mode" to distribute VCs from these external issuers. #### Infrastructure Components (Bottom) * **Postgres DB**: The main database. * **Cache**: The caching system. * **HSM** (Hardware Security Module): For secure key management. # End User Guide Steps to request and download credentials from a Certify issuer. This guide covers the **holder experience** when credentials are issued by a **Certify-backed issuer**. It focuses on what an end user does in a wallet. It does not cover issuer-side setup. ### What you’ll do * Pick an issuer. * Authenticate and consent. * Download the credential into a wallet. ### Wallet guides Follow the wallet that matches your user journey: * [Inji Mobile – End User Guide](/inji-wallet/inji-mobile/functional-overview/end-user-guide) * [Inji Web – End User Guide](/inji-wallet/inji-web/functional-overview/end-user-guide) ### If you’re testing end-to-end * Use [Try It Out](/inji-certify/functional-overview/try-it-out) to set up a working flow. * Use [Workflow](/inji-certify/functional-overview/workflow) when troubleshooting. # Functional Overview ## Functional Overview ### Overview Verifiable Credentials (VCs) are digital representations of physical credentials such as passports and licenses. These credentials are cryptographically signed, ensuring tamper resistance and immediate verifiability. VCs empower users by allowing them to store credentials in digital wallets and seamlessly access various services. ### How does Inji Certify work? 1. **Database Integration**: Inji Certify enables issuers to connect with existing databases to issue VCs. It assumes the source database has a primary key for each data record and information required to authenticate a user (e.g., phone, email, or other personal information). 2. **Credential Schema Configuration**: Issuers can configure their credential schemas for various types of certificates they wish to issue, ensuring alignment with W3C VC v1.1 standards. 3. **VC Issuance**: Authorized methods return VCs of an individual in linked data-proof (JSON-LD) and JWT formats. ### Verifiable Credentials Issuance with Inji Certify Inji Certify is a powerful and versatile platform designed for seamless issuance of Verifiable Credentials (VCs). It leverages a robust architecture that integrates with existing credential registries, enabling organizations to efficiently and securely issue standards-compliant VCs. Key features of Inji Certify for VC Issuance include: * **Seamless Integration:** Replaces the earlier reliance on eSignet with a seamless integration of the Sunbird RC plugin, streamlining the credential issuance process. * **Flexible Schema Definition:** Allows issuers to easily define and customize credential schemas for various credential types, ensuring compliance with W3C VC v1.1 standards and facilitating interoperability. * **Efficient Issuance:** Enables the efficient issuance of VCs in the industry-standard JSON-LD format. * **Enhanced Security:** Incorporates robust security measures to protect the integrity and confidentiality of issued credentials. ## Plugin Integration Inji Certify supports a flexible plugin architecture that allows for seamless integration with various external systems and data sources. This plugin architecture enhances the platform's adaptability and allows for customization to meet diverse credentialing needs. The plugins are categorized into two main types: ### VC Issuance Plugins * **Role:** VC Issuance Plugins are responsible for the core process of generating and issuing Verifiable Credentials (VCs). * **Functionality:** * These plugins typically interact with external identity or authentication systems (e.g., identity providers, registries) to obtain necessary information about the credential recipient (e.g., name, date of birth, unique identifiers). * They then utilize this information to generate the VC in the appropriate format (e.g., JSON-LD) according to the defined credential schema. * Finally, the plugin issues the generated VC to the recipient. * **Examples:** * **Mock Certify Plugin:** This plugin simulates a real-world scenario by interacting with the **Mosip Mock Identity System**. It retrieves sample identity data from the mock system and subsequently generates and issues VCs based on this data. This plugin is valuable for testing and development purposes. * **MOSIP IDA Certify Plugin:** This plugin integrates with the **Mosip National ID System**, a real-world identity platform. It retrieves verified identity information from the Mosip National ID System and utilizes this data to generate and issue VCs. * **Sunbird RC Certify Plugin:** This plugin interacts with the **Sunbird RC registry**, a platform for managing learning resources and learner data. It retrieves relevant data from the Sunbird RC registry, such as academic records and certifications, and generates and issues VCs based on this retrieved information. ### Data Provider Plugins * **Role:** Data Provider Plugins are responsible for fetching relevant data from external sources or registries. * **Functionality:** * These plugins connect to external data sources (e.g., databases, APIs, registries) and retrieve the necessary information about the credential recipient or the credential itself. * The retrieved data is then provided to a VC Issuance Plugin for further processing, including VC generation and issuance. * **Examples:** * **Mock CSV Data Provider Plugin:** This plugin retrieves data from a **CSV file** that acts as a sample data source or a simplified registry. It extracts relevant information from the CSV file and provides it to a connected VC Issuance Plugin. This plugin is useful for testing and development purposes, allowing for easy simulation of data from various sources. * **Postgres Data Provider Plugin:** This plugin connects to a **PostgreSQL database** that acts as a data repository. It retrieves relevant data (e.g., user profiles, academic records) from the specified tables within the PostgreSQL database and provides this data to a connected VC Issuance Plugin for further processing. ## Authentication and Credential Transfer Inji Certify employs OpenID4VCI, an extension of the OAuth 2.0 protocol, for secure and interoperable credential issuance. This mechanism ensures: 1. **Standards-Based Interaction**: Establishes compatibility with various digital wallet providers. 2. **Reliable User Authentication**: Authenticates individuals before issuing credentials. 3. **Wallet-Initiated Flow**: Supports a streamlined flow where VCs are delivered just in time upon request from the user’s wallet. # Setup The 'Setup' section offers a detailed overview of the process and steps involved in building and deploying Inji Certify. # Local Setup **Inji Certify** is a robust platform that enables issuers to connect with an existing Credential Registry to issue verifiable credentials. Issuers can configure credential schemas for various types of certificates they wish to issue. Certificates are generated in JSON-LD format as per the W3C Verifiable Credentials (VC) v1.1 standard. This guide is designed to help developers set up **Inji Certify** in their local environment, providing detailed instructions to replicate the platform's functionality for development or testing purposes. ## Getting Started To begin, visit the **Inji Certify** repository on GitHub: * **Repository Link**: [**Inji Certify Repository**](https://github.com/inji/inji-certify/tree/v1.0.0-alpha.1) The repository contains all the necessary files and instructions to set up Inji Certify on your local machine. ## Prerequisites Before proceeding with the installation, ensure you have the following installed: * Docker (26.0.0) * Docker Compose (2.25) * [**Git bash**](https://gitforwindows.org/) shell to run the scripts, if on *Windows* * [**GNU sed**](https://formulae.brew.sh/formula/gnu-sed) installed, if on *Mac* * A URL to host your DID for verifying VCs(Verifiable Credentials) can use [**GitHub pages**](https://docs.github.com/en/pages/quickstart) here or any other self-hosted server which is highly available for use by verifiers. Please visit the [**Pre-requisites**](https://github.com/inji/inji-certify/blob/v1.0.0-alpha.1/docker-compose/docker-compose-injistack/README.md) section in the ReadME file to explore in detail. ## Installation and Setup The setup involves deploying [**Inji Certify**](https://github.com/inji/inji-certify/blob/v1.0.0-alpha.1/docker-compose/docker-compose-injistack/README.md) using Docker Compose. Follow the steps given in the [**README file**](https://github.com/inji/inji-certify/blob/v1.0.0-alpha.1/README.md) within the Inji Certify repository. ## Explore Inji Certify Once the setup is complete, you can start exploring the functionality of **Inji Certify**: * **Configure Credential Schemas**: Set up schemas for various types of certificates you wish to issue. * **Interact with the System**: Test the issuance and management of credentials through our reference platform Inji Web. Please click [**here**](https://github.com/inji/inji-certify/blob/v1.0.0-alpha.1/README.md) to explore the steps! For additional configuration and usage instructions, consult the documentation included in the repository. ## Configuring Certify with Keycloak Authorization Server ### Set the Authorize URL of Certify to point to the KeyCloak Authorization server, This means configure mosip.certify.authorization.url and configure the mosip.certify.authn.issuer-uri & mosip.certify.authn.jwk-set-uri appropriately. * **General Concept**: This step configures your application ("Certify") with the essential endpoints of your chosen Identity Provider ("Keycloak"). * `mosip.certify.authorization.url`: This corresponds to the provider's standard OAuth 2.0 Authorization Endpoint, where users are redirected for login and consent. * `mosip.certify.authn.issuer-uri`: This is the standard OIDC Issuer Identifier. Your application uses this to verify the `iss` (issuer) claim in tokens it receives, ensuring they come from the expected provider. * `mosip.certify.authn.jwk-set-uri`: This is the standard OIDC JWKS URI. Your application fetches the provider's public keys from this URL to verify the digital signature of received JWTs (like ID Tokens). **Note**: Any compliant OAuth 2.0 / OIDC provider will have corresponding values for these standard endpoints, which you'd find in their documentation or OIDC discovery document (`.well-known/openid-configuration`). **Configure** `mosip.certify.identifier` to the value matching the `aud` value configured in the client. * **General Concept**: This configures your application's own identifier (`mosip.certify.identifier`) as it should appear in the `aud` (Audience) claim of tokens issued by the IdP for this specific application ("client" registration in the IdP). * **Note**: Validating the `aud` claim is a standard security measure for resource servers (like your "Certify" application) to ensure a received token was intended for them and not another application. The value is typically the Client ID or a specific Audience URI defined during application registration in the IdP. **Configure the scope correctly as per the scope of the VerifiableCredential as configured in the Keycloak client in the prior steps.** * **General Concept**: scope is a standard OAuth 2.0 parameter representing the permissions your application is requesting. * **Note**: Your application needs to be configured to request the specific scopes it requires (these might be standard OIDC scopes like openid, profile, email, or custom scopes related to specific functionalities, like Verifiable Credentials here). Importantly, these scopes must also be explicitly allowed for your application ("client") within the Identity Provider's settings (in Keycloak's client configuration in this case). **Configure the credential types to match the VC in the well known** * **General Concept**: This step is specific to the application's domain (handling Verifiable Credentials). It involves configuring the application to understand the specific types of resources it manages. * **Note**: The reference to "well known" likely points to a discovery mechanism (perhaps the OIDC discovery endpoint if extended, or a domain-specific registry/schema definition location) where these credential types are formally defined. This ensures the application's internal configuration aligns with external standards or definitions relevant to its function. ## Explore the APIs To explore all the available APIs of **Inji Certify**, refer to the [**API documentation**](https://mosip.stoplight.io/docs/inji-certify/branches/0.15.0/25f435617408e-open-api-definition) provided within the platform. This will allow you to interact with the various endpoints and understand their functionality in detail. ## Additional Resources For further insights and guidance on using **Inji Certify** effectively, refer to the following: * **Comprehensive Documentation**: Available within the repository’s [**README**](https://github.com/inji/inji-certify/blob/v1.0.0-alpha.1/README.md) file. * **Support**: Engage with the developer [**MOSIP community**](http://community.mosip.io) or seek support for any issues encountered during the setup. # Deploy Inji Certify To segregate # Develop The 'Develop' section helps you dive deeper on how Inji-Certify is built and how to extend it. Subsections cover the tech stack, architecture and key management. # Standards, Specifications and Compliance #### Standards Implemented in Certify *** #### Overview Inji Certify is the credential issuer module. It enables organizations to issue digitally signed, standards-compliant verifiable credentials at scale. Certify is the origination point for all credentials that flow through the Inji ecosystem. **W3C Verifiable Credentials Data Model** **Specification**: (See Standards Library for details) **Certify-Specific Implementation**: * **Credential Issuance**: Full support for both v1.1 and v2.0 credential structures * **Proof Types**: JSON-LD Proofs, JWT, SD-JWT, planned Data Integrity 2.0 * **Automatic Versioning**: Can issue v1.1 credentials for legacy systems or v2.0 for modern deployments * **Multi-Format Support**: Same credential content can be delivered in JSON-LD, JWT, or SD-JWT based on holder request * **SVG Rendering Templates**: v2.0 credentials can include SVG-based display templates for visual rendering in wallets * **Semantic Contexts**: Custom JSON-LD contexts for domain-specific vocabularies (e.g., educational credentials, health credentials) * **Credential Status**: Includes revocation status endpoint referencing W3C Bitstring Status List **Release Timeline**: * v0.8.0+: W3C VC 1.1 support * v0.11.0+: Full W3C VC 2.0 support * Ongoing: Enhanced proof mechanisms, new credential types *** **OAuth 2.0 & OpenID Connect** **Specification**: , (See Standards Library for details) **Certify-Specific Implementation**: * **Authorization Code Flow**: Secure user login and credential issuance authorization * **OIDC Integration**: eSignet integration for federated identity; supports Google OAuth, Keycloak, custom OIDC providers * **Token Validation**: Issued access tokens validated against configured identity provider * **Scope Management**: Fine-grained scopes for different credential types and issuance flows * **Pre-Authorized Code Flow**: Direct issuance without full OIDC flow (speed for certain deployment scenarios) * **User Binding**: Credentials bound to authenticated user identity *** **OpenID4VCI (Verifiable Credential Issuance)** **Specification**: (See Standards Library for details) **Certify-Specific Implementation**: * **Credential Endpoint** (`/credential`): Responds to credential requests from wallet holders * **Batch Issuance**: Issue multiple credentials in single request * **Multiple Formats**: Issue JSON-LD, JWT, or SD-JWT based on holder capability and issuer policy * **Credential Offer**: Generate shareable credential\_offer URIs that wallets can accept * **Authorization Server Integration**: Pluggable authorization (eSignet, Keycloak, custom OAuth 2.0) * **Deferred Issuance**: Support for issuance transactions that complete over time * **Proof Validation**: Require holders to prove key possession during issuance * **Response Metadata**: Provide issuance details (accepted algorithms, supported formats, etc.) **Release Info**: Available since v0.8.0; enhanced with each release *** **W3C DIDs (Decentralized Identifiers)** **Specification**: (See Standards Library for details) **Certify-Specific Implementation**: * **DID Publishing**: Issuers publish their DID as credential issuer identifier * **Key Publication**: DIDs resolve to public key material for signature verification * **DID Methods Supported**: did:mosip, did:ion, did:key (method-specific implementations) * **Credential Context**: All credentials include 'issuer' field with issuer DID * **Key Rotation**: Support for DID key rotation while maintaining credential validation * **Interoperability**: DIDs follow W3C DID specification for universal recognition *** **JSON-LD (Linked Data)** **Specification**: (See Standards Library for details) **Certify-Specific Implementation**: * **Credential Context**: Custom JSON-LD contexts for domain-specific vocabularies * **Semantic Mapping**: Map credential attributes to standard URIs (schema.org, FOAF, custom vocabularies) * **Linked Data Processing**: Support for @context, @id, @type in credential structure * **Extensibility**: Custom vocabularies without breaking interoperability * **Human-Readable Output**: Credentials include human-friendly labels alongside URIs *** **Selective Disclosure JWT (SD-JWT)** **Specification**: (See Standards Library for details) **Certify-Specific Implementation**: * **SD-JWT Issuance**: Issue credentials with selectively-disclosable claims * **Salt & Hash Structure**: Each claim salted and hashed for selective disclosure * **Discloser Binding**: Support for listing which claims verifier may request * **Claim Encryption**: Optional encryption of undisclosed claims * **Fallback Disclosure**: Holder can disclose claims not explicitly requested (if issuer allows) * **Release Timeline**: Drafts in v0.12.0, full support v0.13.0+ *** **W3C Bitstring Status List** **Specification**: (See Standards Library for details) **Certify-Specific Implementation**: * **Status List Publishing**: Publish credential revocation status as bitstring * **Credential Status Entry**: Credentials include reference to status list (list ID + position) * **Revocation API**: Endpoint (`/revoke`) to revoke issued credentials * **Bitstring Format**: Binary format with efficient indexing for 1M+ credentials * **Privacy Preservation**: Bitstring doesn't reveal which specific credentials are revoked * **Distribution**: Status list hosted and distributed by issuer *** **CBOR (Concise Binary Object Representation)** **Specification**: (See Standards Library for details) **Certify-Specific Implementation**: * **Claim 169 Encoding**: Encode identity attributes in CBOR format for QR embedding * **Compact Payload**: CBOR-encoded credentials 30-50% smaller than JSON * **QR Size Optimization**: Compact encoding ensures QR codes remain scannable * **Release Timeline**: Claim 169 support planned v0.14.0 *** **CWT/COSE (CBOR Web Token & Object Signing and Encryption)** **Specification**: (See Standards Library for details) **Certify-Specific Implementation**: * **Claim 169 Signing**: Sign CBOR-encoded identity QR codes with CWT/COSE signatures * **Ed25519 Signing**: Use Ed25519 algorithm for Claim 169 signatures (IANA-registered) * **Signature Validation**: Digital signatures embedded in CBOR payload for offline verification * **Release Timeline**: Planned v0.14.0 with Claim 169 support *** **Claim 169: MOSIP QR Code Specification** **Specification**: (See Standards Library for details) **Certify-Specific Implementation**: * **QR Encoding**: Encode identity credentials as Claim 169-compliant CBOR-CWT QR codes * **Attribute Support**: Support all 23 attributes (v1.2.0): * Standard 18 identity attributes (name, DOB, nationality, address, etc.) * Humanitarian focus: legal status, secondary language, location code * **Signature Schema**: Ed25519 or ECC signatures for offline verification * **QR Embedding**: Claim 169 QR can be embedded in W3C credentials as supplementary format * **Multi-QR Support**: Single credential can contain multiple Claim 169 QRs (different use cases) * **Release Timeline**: Planned v0.14.0 *** **JWT (JSON Web Token)** **Specification**: (See Standards Library for details) **Certify-Specific Implementation**: * **JWT-VC Issuance**: Issue credentials in JWT (not JSON-LD) format * **Claims in JWT**: Credential structure mapped to JWT claims structure * **Compact Distribution**: JWT smaller and faster than JSON-LD equivalent * **Signature Algorithm Selection**: Support Ed25519, RSA, ECDSA signing algorithms * **Token Expiration**: exp claim for credential lifetime management *** **Cryptographic Algorithms (Signing)** **Certify-Specific Implementation**: | Algorithm | Version | Status | Use Case | | --------- | --------- | -------------------- | --------------------------------------- | | Ed25519 | 2018 Spec | Available | Modern, high-performance signing | | Ed25519 | 2020 Spec | Available (v0.11.0+) | Enhanced key format, recommended | | RSA | 2048-bit | Available | FIPS 140-2 compliance, legacy systems | | RSA | 4096-bit | Available | High-security deployments | | ECDSA | secp256k1 | Available (v0.11.0+) | OpenID ecosystem, blockchain-compatible | | ECDSA | P-256 | Available (v0.11.0+) | NIST standard, high security | | ECDSA | P-384 | Planned | Enhanced security variant | *** **W3C Data Integrity 2.0 (Planned)** **Specification**: (See Standards Library for details) **Certify-Specific Implementation** (Planned v0.15.0+): * **JWS-Based Proofs**: Migrate from JSON-LD Proofs to JWS-based Data Integrity proofs * **Algorithm Support**: Ed25519, RSA, ECDSA with Data Integrity 2.0 format * **Canonical JSON**: Canonicalized JSON-LD before signing (prevents tampering) * **Backward Compatibility**: Continue issuing JSON-LD Proofs for legacy systems *** # Architecture Inji Certify is a platform designed to manage and facilitate the issuance of Verifiable Credentials (VCs). It features a modular architecture that supports both direct issuance and proxying of VCs from external sources. It interacts with external digital wallets via APIs.
* This layered component diagram represents the architecture of the Inji Certify system. * The diagram is organized into four distinct layers, each representing a different aspect of the system's functionality: 1. **API Layer**: * This layer serves as the entry point for external interactions with the system. * It exposes various APIs that allow clients to interact with the underlying services. 2. **VC Signer and Template Engine**: * This layer is responsible for the creation and signing of Verifiable Credentials (VCs). * The Template Engine component within this layer handles the generation of credential templates. * The VC Signer component ensures that the credentials are properly signed and verifiable. 3. **Keymanager Service**: * This layer manages cryptographic keys used for signing and verifying credentials. * It ensures the secure storage and retrieval of keys, and handles key rotation and management tasks. 4. **Plugin interaction**: * This foundational layer consists of three plugins that provide essential services to the upper layers: * **Data Provider Plugins:** These plugins fetch relevant data from external sources or registries. They retrieve the necessary information and return it to Inji Certify as a JSON object. Inji Certify then utilizes this data to generate and issue the corresponding VCs.. * **Audit Plugin**: Tracks and logs actions within the system for auditing purposes. * **VC Issuance Plugin**: Exposes API for VCI Issuance which internally connects with credential service and sends the Verifiable Credential (VC) issued by the service as a response. Each layer builds upon the services provided by the layer below it, creating a modular and scalable architecture for the Inji Certify system. # Key Manager ## Overview The Key Manager in Inji Certify is a critical component which is used as an embedded library responsible for secure cryptographic key lifecycle management. It handles: * Generation of asymmetric and symmetric keys. * Storage and encryption of private keys. * Certificate management (self-signed and externally signed). * Digital signing operations (e.g., signing Verifiable Credentials). * Key rotation and revocation. * Secure integration with hardware-backed key stores (e.g., HSM). By consolidating these cryptographic operations in one trusted service, Certify ensures the integrity, confidentiality, and long-term security of all cryptographic materials. ## Capabilities & Responsibilities Below are the main capabilities and how Key Manager supports them in Inji Certify: ### Key Generation * The Key Manager generates various types of keys: root/master keys, module-level keys, and application-specific (base) keys. * Asymmetric algorithms such as RSA, ECC, Ed25519 etc. are used based on the VC configuration. * Root and module master keys can be generated at the time of installation of Inji Certify * Base keys (application-specific) are auto-generated as needed. ### Secure Storage * Private keys are stored securely in a key store. In Inji implementation, a Hardware Security Module (HSM) is used to store root and master keys, while base keys are stored in a database encrypted by module keys. * Key metadata (aliases, identifiers) is maintained in a key-alias table; the encrypted key material resides in a key-store table. * The Key Manager supports integration with HSMs via PKCS#11 or JCE. ### Certificate Management * Self-Signed Certificates: When no external CA is provided, the Key Manager can generate self-signed certificates. For example, root key is self-signed. * CSR Generation: It supports generating CSR (Certificate Signing Requests) for any key, so that you can obtain a certificate signed by an external CA. * Uploading Externally-Signed Certificates: Once you obtain a CA-signed certificate, you can upload it to the Key Manager, updating existing certificate with CA signed certificate. ### Signing & Cryptographic Operations For signing credential (VC) issuance, the Key Manager uses the appropriate key (module or base) and the associated certificate to sign the VC payload. ### Key Rotation * Automatic Rotation: Keys have default validity periods. For example, in MOSIP, root keys are valid for \~5 years, module keys for \~3 years, base keys for \~2 years. * Forced Rotation: Admins can force key regeneration via APIs (e.g., a generateMasterKeyAPI) with a “force” flag. Existing keys are invalidated and new ones generated. * On expiry, key manager automatically generates new keys and ensures that cryptographic operations switch over to the new valid keys. * Duration of key rotation is configurable which is handled through a table named as 'key-policy-def'. * Key manager has the capability to pre generate keys before expiry. Duration for the pre generation is a configurable which is handled through a table named as 'key-policy-def'. ### Certificate Expiry Handling In case of externally CA signed certificate is used for key generation, and certificate expires, the system falls back: Key Manager re-generate keys using a self-signed certificate (or whatever default mechanism is configured). * Mitigation: To avoid lapse in trust or broken signing, users (issuer administrators) must proactively upload a new valid certificate before the current one expires. ### Integration with Hardware Security Module (HSM) The Key Manager is designed to work with HSMs, ensuring that root and module keys never leave secure hardware. * For setups without HSM, the Key Manager also supports other keystore types (PKCS12), configurable via properties. (This option is not recommended during the production environment). * Role of Key Manager Specifically in VC Signing Workflow (In Certify). * Putting the above capabilities in the context of Verifiable Credential (VC) issuance in Inji Certify: * Initial Setup (If PKI is already existing) * The system admin uses Inji Certify API which internally uses KeyManager service to generate a master signing key pair. * The admin can request a CSR from Inji Certify API for the generated signing key (via generateCSR), so they can share it to be externally singed by CA * Once the certificate is signed, they upload the CA certificate to Inji Certify, then upload their signed certificate, binding it to the key. ### Credential Issuance When Certify issues a VC, it calls Key Manager to sign the credential payload. * Key Manager uses the private key associated with the signing key (which is backed by the uploaded certificate) to compute a digital signature. * The signed VC thus has cryptographic integrity and can be verified by relying parties using the public certificate. ## Key Benefits for Inji Certify * Security & Trust: All signing keys are managed securely; private keys are never exposed, especially when using HSM. * Flexibility: Support both self-signed workflows (for simplicity) and externally-CA-signed certificates (for integration into existing PKI). * Operational Control: Administrators have full control over key lifecycles, rotation, and certificate management. * Interoperability: By using standard cryptography and certificate formats, Certify’s VCs can be validated by any compliant verifier. * Resilience: With key-rotation and fallback mechanisms, the system can recover from certificate expiry. For deeper technical details about the Key Manager component itself, you can refer to the MOSIP documentation [here](https://docs.mosip.io/1.2.0/id-lifecycle-management/supporting-components/keymanager). # Technology Stack This section intends to provide an overview of the technologies and frameworks utilized to build Inji Certify. **UI & Rest end points** The table below outlines the frameworks, tools, and technologies employed by Inji Certify | **Tool/Technology** | **Version** | **Description** | **License** | | ----------------------------------------------------- | ------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | [React JS](https://react.dev/) | 18.2v | React lets you build user interfaces out of individual pieces called components. Used for OIDC UI | [MIT License](https://github.com/facebook/react/blob/main/LICENSE) | | [Spring Boot](https://spring.io/projects/spring-boot) | 2.3.6.RELEASE | Spring Boot is an open-source Java framework used to create a Micro Service. Spring boot is used for programming standalone, production-grade Spring-based applications with minimal effort. Used for esignet-services | [Apache License](https://en.wikipedia.org/wiki/Apache_License) 2.0 | | [Nest Js](https://docs.nestjs.com/) | 9.5.0 | Nest (NestJS) is a framework for building efficient, scalable Node.js server-side applications. It uses progressive JavaScript, is built with and fully supports TypeScript. Used for Sunbird credentialing services | [MIT License](https://github.com/facebook/react/blob/main/LICENSE) | | [Java](https://www.java.com/en/) | 11 | Java is a high-level, class-based, object-oriented programming language that is designed to have as few implementation dependencies as possible. Used in eSignet-services | | | [Postgres SQL](https://www.postgresql.org/about/) | 12.1V | PostgreSQL is an advanced, enterprise-class open-source relational database that supports both SQL (relational) and JSON (non-relational) querying. | PostgreSQL License ([free and open-source](https://en.wikipedia.org/wiki/Free_and_open-source_software), [permissive](https://en.wikipedia.org/wiki/Permissive_software_license)) | **Deployment:** The table below specifies the tools needed to deploy Inji Certify: | **Tool/Technology** | **Version** | **Description** | **License** | | --------------------------------------------------------- | --------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------- | | [Docker](https://www.docker.com/) | 26 and above | Docker is a set of platform as a service (PaaS) products that use OS-level virtualization to deliver software in packages called containers. | [OpenSource License](https://www.docker.com/community/open-source/) | | [Docker Compose](https://docs.docker.com/compose/) | 2.25 and above | Docker Compose is a tool for defining and running multi-container applications. It is the key to unlocking a streamlined and efficient development and deployment experience. | [Apache License](https://en.wikipedia.org/wiki/Apache_License) 2.0 | | [Helm Chart (MOSIP)](https://github.com/mosip/mosip-helm) | depends on Inji-web version | Helm helps you manage Kubernetes applications - helps define, install, and upgrade even the most complex Kubernetes application. Charts are easy to create, version, share, and publish — so start using Helm and stop the copy-and-paste. | | # Tested Operating Systems Inji Certify is currently compatible and certified with the following browsers:
Sl NoOSVersion
1.Windows - Google ChromeVersion 124.0.6367.92
2.Mac- SafariVersion 16.6 (18615.3.12.11.2)
3.UbuntuVersion 22.04
{% hint style="info" %} **Note:** We have conducted specific testing on Ubuntu, Mac, and Windows using Google Chrome for the latest release of Inji Certify. It supports and is compatible with other operating systems and browsers, but we have specified the following list to indicate the platforms our team has thoroughly tested. {% endhint %} # API Refer to Inji Certify API Documentation here - # Releases #### **Version:** v1.0.0-alpha.1 * Name: **Release Version**: 1.0.0-alpha.1 * Date: 31st July, 2026 * [Release Notes](/inji-certify/releases/version-1.0.0-alpha.1) #### **Version: 0.14.0** * Name: **Release Version**: 0.14.0 * Date: 25th March, 2026 * [Release Notes](https://github.com/mosip/documentation/blob/inji/docs/inji-certify/releases/version-0.14.0) #### **Version: 0.13.1** * Name: **Release Version**: v0.13.1 * Date: 5th December, 2025 * [Release Notes](https://github.com/mosip/documentation/blob/inji/docs/inji-certify/releases/version-0.13.1) #### **Version: 0.13.0** * Name: Inji Certify 0.13.0 * Date: 28th November, 2025 * [Release Notes](https://github.com/mosip/documentation/blob/inji/docs/inji-certify/releases/version-0.13.0) #### **Version: 0.12.2** * Name: Inji Certify 0.12.2 * Date: 23rd October, 2025 * [Release Notes](https://github.com/mosip/documentation/blob/inji/docs/inji-certify/releases/version-0.12.2) #### **Version: 0.12.1** * Name: Inji Certify 0.12.1 * Date: 11th September, 2025 * [Release Notes](/inji-certify/releases/version-0.12.1) #### **Version: 0.12.0** * Name: Inji Certify 0.12.0 * Date: 26th August, 2025 * [Release Notes](https://github.com/mosip/documentation/blob/inji/docs/inji-certify/releases/version-0.12.0) #### **Version: 0.11.0** * Name: Inji Certify 0.11.0 * Date: 2nd May, 2025 * [Release Notes](https://github.com/mosip/documentation/blob/inji/docs/inji-certify/releases/version-0.11.0) #### **Version: 0.10.2** * Name: Inji Certify 0.10.2 * Date: 21st Feb, 2025 * [Release Notes](https://github.com/mosip/documentation/blob/inji/docs/inji-certify/releases/version-0.10.2) #### **Version: 0.10.1** * Name: Inji Certify 0.10.1 * Date: 3rd February, 2025 * [Release Notes](https://github.com/mosip/documentation/blob/inji/docs/inji-certify/releases/version-0.10.1) #### **Version: 0.9.1** * Name: Inji Certify 0.9.1 (Patch) * Date: 3rd October, 2024 * [Release Notes](https://github.com/mosip/documentation/blob/inji/docs/inji-certify/releases/version-0.9.1) #### **Version: 0.9.0** * Name: Inji Certify 0.9.0 * Date: 22nd August, 2024 * [Release Notes](https://github.com/mosip/documentation/blob/inji/docs/inji-certify/releases/version-0.9.0) #### Version: 0.8.1 * Name: Inji Certify 0.8.1 (Patch) * Date: 17th May, 2024 * [Release Notes](/inji-certify/releases/release-notes) #### Version: 0.8.0 * Name: Inji Certify 0.8.0 * Date: 30th April, 2024 * [Release Notes](/inji-certify/releases/version-0.8.0) # Version 1.0.0-alpha.1 **Release Version**: v1.0.0-alpha.1 **Release Type:** Alpha Release **Release Date:** 31st July, 2026 {% hint style="success" %} **Note** Inji Certify **v1.0.0-alpha.1** marks our formal adoption of the [**OpenID4VCI 1.0 specification**](https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html). This is an important milestone, and we want to provide clear guidance for all community members. * **Upgrading is optional but recommended for spec compliance.** This release is intended for teams ready to align with the finalized OpenID4VCI 1.0 standard. Teams running earlier Certify release versions built on draft specifications of OpenID4VCI are not mandatory to upgrade — the earlier releases can be continued without any disruption, with the option to upgrade at a time that suits your roadmap. * **For those upgrading to v1.0.0-alpha.1**, This release **does not maintain backward compatibility** with earlier draft specifications of OpenID4VCI. APIs, credential formats that have been updated or replaced are listed below wherever required. Reviewing that section before upgrading is strongly recommended. {% endhint %} ### Overview Inji Certify **v1.0.0-alpha.1** delivers comprehensive alignment with the [OpenID4VCI 1.0](https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html) specification and introduces critical enhancements to credential issuance workflows, interoperability, and system stability. This release focuses on modernizing the credential issuance architecture, removing draft implementations, and providing enhanced support for emerging credential formats. **Key Changes:** * OpenID4VCI 1.0 specification alignment (credential endpoint, well-known metadata, authorization flows) * Credential format transitions (**vc+sd-jwt** to **dc+sd-jwt**) * Addition of Nonce endpoint #### Major Features & Enhancements 1. **Credential Issuance Endpoint Enhancement**\ The credential issuance endpoint has been upgraded to full [OpenID4VCI 1.0](https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html) compliance. Requests now require a mandatory credential\_configuration\_id field, and the format field is rejected in requests as per the specification. Array-based proof JWT validation is supported, and request/response structures have been updated accordingly. Validation mechanisms have been enhanced and error handling improved throughout the issuance flow. 2. **Issuer Well-Known Metadata Update**\ The /.well-known/openid-credential-issuer endpoint response has been updated to reflect OpenID4VCI 1.0 adoption. The metadata now exposes the new nonce\_endpoint, includes updated claim display properties per the 1.0 schema, and externalizes metadata configuration for greater flexibility. The full response has been validated against the [OpenID4VCI 1.0](https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html) specification. 3. **Nonce Endpoint Implementation**\ A dedicated /nonce endpoint has been introduced for c\_nonce generation and replay attack prevention. Nonces are cryptographically generated with a configurable TTL-based expiration and stored in Redis with automatic expiry. During credential issuance, the nonce is validated and marked as used. As a result, c\_nonce has been removed from the access token response in line with the updated specification.\ **Breaking Change:** Clients must now call the /nonce endpoint separately, as c\_nonce is no longer included in the token response. 4. **Replace Credential Format: vc+sd-jwt → dc+sd-jwt**\ The vc+sd-jwt credential format has been replaced with the standardized dc+sd-jwt format as mandated by [OpenID4VCI 1.0](https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html) .\ **Breaking Change:** The vc+sd-jwt format is no longer supported and all configurations must be updated. 5. **Pre-Authorized Credential Offer API Enhancement**\ The /pre-authorized-data API has been upgraded to comply with the [OpenID4VCI 1.0](https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html) specification. The credential\_configuration\_id is now validated against issuer metadata via /.well-known/openid-credential-issuer, and claims are validated against the structures defined in the credential configuration. Unknown or unsupported claims are rejected, while existing API logic outside the claims validation scope remains unchanged. 6. **Configurable JSON-LD Context Loader with Caching**\ A Spring-managed JSON-LD `DocumentLoader` has been introduced to resolve JSON-LD `@context` IRIs during Verifiable Credential processing. It provides a configurable context registry (mapping context IRIs to classpath, file, or HTTP resources), an in-memory cache with TTL and a maximum-entry limit, startup preload of configured contexts, and controlled remote resolution guarded by a host allowlist and an opt-in toggle for unknown contexts. The W3C Credentials v1/v2 and Ed25519 Security Suite v1 contexts are bundled locally by default. This removes the runtime dependency on external context hosts, improving latency, reliability, and security (mitigating SSRF-style risks) during proof generation. Configuration lives under the new `mosip.certify.jsonld.*` namespace. See [JSON-LD Context Loader documentation](https://github.com/inji/inji-certify/blob/release-1.0.x/docs/JSON-LD-context-loader.md) for details. #### User Stories Released
FeatureDescriptionGit Id
Credential Issuance endpoint EnhancementEnhancement of Credential Issuance Endpoint to Support OpenID4VCI 1.0 Features#678
Enhance pre-authorized credential offer API , claims validationEnhance pre-authorized credential offer API , claims validation as per OpenID4VCI 1.0 issuer metadata response#845
Issuer Well-known metadata to adopt 1.0 OpenID4VCI changesUpdate Credential Issuer Well-Known Metadata for OpenID4VCI 1.0 Adoption#676
Replace format vc+sd_jwt to dc_sd_jwtReplace Credential Format from vc+sd-jwt to dc+sd-jwt for OpenID4VCI 1.0 Compliance#677
Nonce endpoint implementationImplementation of nonce_endpoint for c_nonce generation and replay attack prevention#675
### Bug Fixes The following bugs have been addressed in this release.
Bug IDDescription
#690Error message mismatch in mock -mdl use case
#686Error messages mismatch in mdoc-mdl use case(PDI)
#681Getting Canonicalization error when try to get VC intermittently
#715"uri" field is mandatory if logo is present in issuer metadata
#716nonce Should Be Optional in Verifiable Credential Issuance
#863Not able to configure Vc issuance plugin for Mosipid use cases in release-0.14.x
### Known Issues Below is the list of known issues related to the release v1.0.0-alpha.1. To access all open issues related to Inji Certify please click [here](https://github.com/inji/inji-certify/issues?q=is%3Aissue%20state%3Aopen%20-milestone%3A1.0.0-alpha.1%20label%3Abug)
Issue IDDescription
#842Validations to add "qrSignatureAlgo" in credential config API
#679Validations issues for qrsettings block in Credential config API
#878unknown_error returned for negative scenarios
#967Credential Issuer Metadata not served at spec-mandated well-known path for issuer identifiers with a path component
#966Facing issue at automating the mdocVP test cases. Getting "VP cryptographic verification failed
### Breaking Changes #### Replaced APIs & Formats 1. vc+sd-jwt format - replaced by dc+sd-jwt * **Required Action:** Update credential configurations to use dc+sd-jwt format * **Impact:** Clients must upgrade configuration or credential issuance will fail 2. c\_nonce in access token response - Removed * **Required Action:** Clients must now call /nonce endpoint to retrieve c\_nonce * **Impact:** Access token responses no longer include c\_nonce; separate endpoint call required ### Repositories Released Supported Platforms & Components | Repository | Version | | -------------------------- | ---------------------------------------------------------------------------------------- | | inji-certify | [v1.0.0-alpha.1](https://github.com/inji/digital-credential-plugins/tree/v1.0.0-alpha.1) | | inji-config | [v1.0.0-alpha.1](https://github.com/inji/inji-config/tree/v1.0.0-alpha.1) | | digital-credential-plugins | [v1.0.0-alpha.1](https://github.com/inji/inji-certify/tree/v1.0.0-alpha.1) | ### Compatible Modules | Modules | Version | | --------------------- | ------------------------------------------------------------------------------------- | | keymanager | [v1.4.0](https://github.com/mosip/keymanager/tree/v1.4.0) | | eSignet | [1.6.2](https://github.com/mosip/esignet/tree/v1.6.2) | | IDA | [1.3.0](https://github.com/mosip/id-authentication/tree/v1.3.0) | | Sunbird C | [v2.0.0](https://github.com/Sunbird-RC/sunbird-rc-core/releases/tag/v2.0.0-rc3) | | esignet-mock-services | [v0.11.2](https://github.com/mosip/esignet-mock-services/tree/v0.11.2) | | commons | [1.6.0](https://github.com/mosip/commons/tree/v1.3.0) | | mimoto | v1.0.0-alpha.1 ([Release Coming Soon](https://community.mosip.io/tag/announcement/2)) | | inji-web | v1.0.0-alpha.1 ([Release Coming Soon](https://community.mosip.io/tag/announcement/2)) | ### Documentation * [Feature Documentation](https://docs.mosip.io/inji/inji-certify/functional-overview/features) * [Local Setup](https://docs.mosip.io/inji/inji-certify/build-and-deploy/local-setup) * [API Documentation](https://mosip.stoplight.io/docs/inji-certify/branches/0.15.0/25f435617408e-open-api-definition) * [Test Report](/inji-certify/releases/version-1.0.0-alpha.1/test-report) # Test Report ## Introduction The scope of testing is to verify fitment to the specification from the perspective of Functionality, Configurability and Customizability. Verification is performed not only from the end-user perspective but also from the System Integrator (SI) point of view. Hence, the Configurability and Extensibility of the software are also assessed. This ensures the readiness of the software for use in multiple countries and diverse identity ecosystems. ### Overview and Scope Testing scope has been focused on the following features: * Inji certify Docker compose testing (Data provider CSV plugin, Data provider Postgres plugin) * Insurance, MosipId and Mock (Issuance and Data provider (Postgres plugin)), which covered Land registry, school and Farmer use case * Preauthcode * Mdoc mdl format ## Test Approach The Functional verification of Inji Certify is performed to ensure alignment with product specifications, business requirements, and the OpenID for Verifiable Credential Issuance flow. The validation covers credential generation, signing, and issuance of W3C-compliant Verifiable Credentials across supported formats such as JSON-LD and SD-JWT, along with integration of issuer configurations, credential schemas, data provider plugins, and dependent services. The testing adopts a use-case-based strategy, validating issuance workflows for configured certificate types and data sources to ensure functional stability, data integrity, interoperability, configurability, and readiness for deployment in diverse credential ecosystems. * Functionality through automation ## Test Organization **Table**: Test Organization
NameFunctional RoleResponsibilities

Nitin Hegde


QA LeadVerifying the functionality, Automation scenarios development and report preparation
Chaitanya KQA ManagerOverviewing the test execution and review of the report.
### Test Planning * Data Readiness: Validate the availability of all services along with configured identity schemas (UIN/VID) to authentication flows. ### Test Environment **Table**: Test Environment
Test Environments
Images (qainji env)
injistackqa/inji-certify-with-plugins:1.0.x
injistackqa/inji-web:develop
injistackqa/mimoto:1.0.x
injistackqa/inji-verify-service:1.0.x
injistackqa/inji-verify-ui:1.0.x
Nginx
mosipid/softhsm:v2
mosipid/kernel-config-server:1.3.0
mosipqa/postgres-init:develop
injistackqa/apitest-inji-certify:1.0.x
Images (released env)
mosipid/credential-service:1.3.0
mosipid/data-share-service:1.3.0
mosipid/data-share-service:1.3.0-beta.2 - Injiweb
mosipid/digital-card-service:1.3.0
mosipid/esignet-with-plugins:1.6.2
mosipid/mock-identity-system:0.11.2
sunbird-rc/sunbird-rc-core:v1.0.0
sunbird-rc/sunbird-rc-credential-schema:v2.0.0-rc3
sunbird-rc/sunbird-rc-credentials-service:v2.0.0-rc3
sunbird-rc/sunbird-rc-identity-service:v2.0.0-rc3
## Test Execution Report ### Test case execution summary Automation Test Execution was completed in qainji env achieving a 100% execution rate for all planned scenarios. The testing validated core functionalities with a high pass rate, while identified issues on both platforms have been logged for defect resolution. ### Automation Result * Sunbird use case
TotalPassedFailedIgnoredKnown issues
51548044720
Test Rate: 100%, With Pass Rate: 100% and Fail Rate: 0%
* Mock Use case
TotalPassedFailedIgnoredKnown issues
51521047420
Test Rate: 100%, With Pass Rate: 100% and Fail Rate: 0%
* Mock (Data provider) Land registry Use case
TotalPassedFailedIgnoredKnown issues
515249024620
Test Rate: 100%, With Pass Rate: 100% and Fail Rate: 0%
* MosipId Use case
TotalPassedFailedIgnoredKnown issues
51592040320
Test Rate: 100%, With Pass Rate: 100% and Fail Rate: 0%
* Preauth code(academic) Use case
TotalPassedFailedIgnoredKnown issues
51535046020
Test Rate: 100%, With Pass Rate: 100% and Fail Rate: 0%
* Mdoc mdl Use case
TotalPassedFailedIgnoredKnown issues
51518047720
Test Rate: 100%, With Pass Rate: 100% and Fail Rate: 0%
## Defect Metrics ### Defect Metrics for the Release 1.0.0-alpha.1 The following table depicts only the bugs which are found and not addressed in the current release. **Table**: Defect Metrics for the Release | Blocker | Critical | Major | Minor | Total | | ------- | -------- | ----- | ----- | ----- | | 0 | 1 | 0 | 0 | 1 | ## Conclusion This section summarizes the key findings of test execution. It also provides a final QA recommendation on the build's readiness for release. The functional verification for Inji Certify release version 1.0.0-alpha.1 has been successfully completed. The testing cycle achieved a 100% execution rate with a 100% pass rate across a total of 515 automation test cases. While there are 1 Critical open defects and as known issues, there are zero blocker defects that are open. Testing has demonstrated functional stability and data integrity consistent with product specifications. ### QA Approval The build has successfully met the defined exit criteria and is recommended for release. The approval is based on the following satisfied conditions: * Test Case Execution Completion: 100% of planned scenarios executed. * Defect Status: No Blocker defects remain open. * Documentation Sign-off: Reports are finalized. * Test Environment Stability: The test environment remained stable throughout the execution cycle. \ **Table**: Report is signed off details | Name | Functional Role | Responsibilities | | ----------- | --------------- | ---------------- | | Chaitanya K | QA Manager |


| ## Appendix This includes additional reference information for the report. It contains a history of document versions and a list of acronyms and their meanings. ### Appendix A: Versions
VersionDateAuthorReviewers
V1.028/07/2026Nitin HegdeChaitanya K
### Appendix B: Acronyms | Acronym | Literal Translation | | --------- | ------------------------------------- | | MOSIP | Modular Open-Source Identity Platform | | UIN | Unique Identification Number | | VID | Virtual Identification | | SVG | Scalable Vector Graphics | | SD-JWT | Selective Disclosure - JSON Web Token | | VC | Verifiable Credentials | | OpenID4VC | OpenID for Verifiable Credentials | Refer to the github link for more on reports [here](https://github.com/inji/test-management/tree/master/inji-certify/1.0.0-alpha.1).\
# Version 0.14.0 **Release Version**: v0.14.0 **Release Type:** Developer Release **Release Date:** 25th March, 2026 #### Overview Inji Certify v0.14.0 introduces key enhancements to credential issuance workflows, interoperability, and user experience. This release focuses on strengthening OpenID4VCI flows, expanding support for emerging credential formats, and improving system usability and integration capabilities. Major updates include support for presentation during issuance, mDoc/mDL credentials, Pre-Authorized Code flow, enhanced error handling, QR code embedding in credentials, and seamless integration with MOSIP for data-driven credential generation. #### Major Highlights / Features * [**Presentation during Issuance**](https://docs.inji.io/inji-certify/overview/features#id-13.-presentation-during-issuance)**:** Introduced a new issuance mode enabling residents to present an existing Verifiable Credential to obtain another credential. * [**Pre-Authorized Code Flow**](https://docs.inji.io/inji-certify/overview/features#id-15.-vc-issuance-with-pre-authorised-code-pre-auth-code-flow)**:** Enabled a simplified issuance flow where users can securely download credentials using a pre-authorized and transaction code. * [**Support for Issuance in mDoc/mDL Format**](https://docs.inji.io/inji-certify/overview/features#id-4.-support-for-multiple-credential-formats)**:** Added support for issuing Verifiable Credentials in standardized mDoc/mDL formats. * **Error Message Revamp:** Improved the error handling framework with clearer, more structured, and developer-friendly messages. * [**MOSIP Identity Plugin Integration**](https://docs.inji.io/inji-certify/overview/features#data-provider-plugins)**:** Integrated with MOSIP APIs to fetch identity data and generate Verifiable Credentials within Certify. * [**Embedding Data in QR Code for VC Issuance**](https://docs.inji.io/inji-certify/overview/features#id-14.-issuance-of-verifiable-credentials-with-qr-code)**:** Enabled [**169 - QR Code Specifications 1.1.0**](https://docs.mosip.io/1.2.0/readme/standards-and-specifications/mosip-standards/169-qr-code-specification-1) compliant data embedding within QR codes for secure credential download and verification. #### User Stories Released
FeatureDescriptionJIRA
Pre Authorized Code FlowEnables credential issuance without login using a pre-authorized code.INJICERT-976
Support for mDoc VC FormatIssuing VC in mDoc/mDL format.INJICERT-981
Presentation During IssuanceEnables credential issuance by requiring the user to present an existing Verifiable Credential as proofs.INJICERT-990
Issuance of Verifiable Credentials with QR codeIssuing VC with QR code in compliant of claim 169 specification.INJICERT-1223
Enhance Error MessageImprove Error Message Handling for System Integration and Automation.INJICERT-1257
Enable certify to Issue MOSIP UIN as VCEnable certify to convert and issue MOSIP UIN as verifiable credentials.INJICERT-1295
#### Bug Fixes
JIRADescription
INJICERT-1275Getting 401 error when /issuance/credential API is hit pointing to esignet-1.7.0V.
INJICERT-1282Remove claims validation for mDoc request as claims are optional.
INJICERT-1297Issuer and verification method value is pointing to mosip repo instead of inji in status list credential response.
INJICERT-1110Error message should be user friendly when invalid request is passed - add credential config API.
INJICERT-1098Error code and error messages to be different.
INJICERT-1075VC fetch with VID is failing in Mosipid Usecase.
INJICERT-852Error message is not proper when render template id is mismatch in DB and config.
INJICERT-840Error messages are not user friendly when {{url}}/issuance/credential API is executed without context value.
INJICERT-819Error message is not proper for sunbird and Mosipid use case with 2.0 model context.
INJICERT-681Error messages difference in few scenarios in Sunbird and MOCK Use cases.
### Known Issues Below is the list of known issues related to the release v0.13.0. To access all known issues related to Inji Certify please click [**here**](https://mosip.atlassian.net/issues/INJICERT-852?filter=11419\&jql=project%20%3D%20%22Inji%20Certify%22%20AND%20issuetype%20%3D%20Bug%20%20AND%20labels%20not%20in%20%28API_Automation%2C%20AWSdevicefarm%2C%20device_specific%2C%20qa-inji-UI-auto%29%20%20and%20status%20NOT%20IN%20%28Closed%2C%20Fixed%2C%20Canceled%2CCancelled%29%20%20ORDER%20BY%20created%20DESC%2C%20updated%20DESC)
JIRADescription
INJICERT-1319Error messages mismatch in mdoc-mdl usecase(PDI).
INJICERT-1290CSR Certificate Upload via Automation Causes DID kid Mismatch and VC Verification Failures.
INJICERT-1265Upload ca cert for ecck1 signalgo is failing.
INJICERT-1260Improper Validation in Status Update Endpoints.
INJICERT-1324Generate token API is failing with unkown_error.
### Repository Released
RepositoriesTags
inji-certifyv0.14.0
inji-configv0.14.0
keymanagerv1.4.0
digital-credential-pluginv0.6.0
mosip-functional-testsv1.5.0
### Compatible Modules
ModulesVersion
eSignet1.6.2
IDA1.3.0
pixelpass0.8.0
Sunbird Cv2.0.0
esignet-mock-servicesv0.11.2
commons1.3.0
mimoto0.20.0
inji-web0.15.0
### Documentation * [Feature Documentation](https://docs.mosip.io/inji/inji-certify/functional-overview/features) * [Local Setup](https://docs.mosip.io/inji/inji-certify/build-and-deploy/local-setup) * [API Documentation](https://mosip.stoplight.io/docs/inji-certify/25f435617408e-inji-certify) * [Test Report](/inji-certify/releases/version-0.14.0/test-report) # Test Report ## Introduction The scope of testing is to verify fitment to the specification from the perspective of Functionality, Configurability and Customizability. Verification is performed not only from the end-user perspective but also from the System Integrator (SI) point of view. Hence, the Configurability and Extensibility of the software are also assessed. This ensures the readiness of the software for use in multiple countries and diverse identity ecosystems. ### Overview and Scope Testing scope has been focused on the following features: * Inji certify Docker compose testing (Data provider CSV plugin, Data provider Postgres plugin) * Insurance, MosipId and Mock (Issuance and Data provider (Postgres plugin)), which covered Land registry, school and Farmer use case * Integration with Inji Web and Inji verify * DB upgrade scripts testing, Backward compatibility - from Docker setup * Preauthcode * Presentation during issuance * Claim 169 * Mdoc mdl format ## Test Approach The Functional verification of the Inji Mobile Wallet application is performed on Android and iOS platforms to ensure alignment with product specifications and business requirements. Analyzed with respect to functional stability, data integrity, and UI consistency. The validation adopts a persona-based testing strategy, simulating real-world user scenarios across diverse device matrices and multi-language configurations to ensure robustness in both online and offline environments. * Functionality * Combination * Configurability * Customizability ## Test Organization Table: Test Organization
NameFunctional RoleResponsibilities
Likhitha R LQA EngineerVerifying the functionality, Automation scenarios development and report preparation
Chaitanya KQA ManagerOverviewing the test execution and review of the report.
Ragini KrishnaSenior QA ManagerHigh-level governance and executive reviews of reports and execution.
### Test Planning * Data Readiness: Validate the availability of all services along with configured identity schemas (UIN/VID) to authentication flows. ### Test Environment Table: Test Environment
Images (qa-inji1 env)
injistackqa/inji-certify-with-plugins:0.14.x
injistackqa/uitest-web:release-0.16.x
injistack/mimoto:0.21.0
injistackqa/inji-verify-service:develop
injistackqa/inji-verify-ui:develop
Nginx
mosipid/softhsm:v2
mosipid/kernel-config-server:1.3.0
mosipqa/postgres-init:develop
injistackqa/apitest-inji-certify:0.14.x
Images (released env)
mosipid/credential-service:1.2.2.2
mosipid/data-share-service:1.2.0.1
mosipid/data-share-service:1.3.0-beta.2 - Injiweb
mosipid/digital-card-service:1.2.0.1
mosipid/esignet:1.6.2
mosipid/mock-identity-system:0.11.1
sunbird-rc/sunbird-rc-core:v1.0.0
sunbird-rc/sunbird-rc-credential-schema:v2.0.0-rc3
sunbird-rc/sunbird-rc-credentials-service:v2.0.0-rc3
sunbird-rc/sunbird-rc-identity-service:v2.0.0-rc3
## Test Execution Report ### Test case execution summary Manual Test Execution was completed in qa-inji1 env achieving a 100% execution rate for all planned scenarios. The testing validated core functionalities with a high pass rate, while identified issues on both platforms have been logged for defect resolution. Table: Test Execution Summary
TotalPassFailSkip
880859210
#### Feature Health
### Automation Results #### Sunbird use case
TotalPassedFailedIgnoredKnown issues
62279052617
Test Rate: 100%, With Pass Rate: 100% and Fail Rate: 0%
#### Mock Use case
TotalPassedFailedIgnoredKnown issues
62253055217
Test Rate: 100%, With Pass Rate: 100% and Fail Rate: 0%
#### Mock (Data provider) Land registry Use case
TotalPassedFailedIgnoredKnown issues
622326027917
Test Rate: 100%, With Pass Rate:97.02% and Fail Rate: 2.98%
#### MosipId Use case
TotalPassedFailedIgnoredKnown issues
62273053217
Test Rate: 100%, With Pass Rate: 100% and Fail Rate: 0%
#### Preauth code(academic) Use case
TotalPassedFailedIgnoredKnown issues
62228057717
Test Rate: 100%, With Pass Rate: 90.32% and Fail Rate:9.68%
#### PDI (mdoc) Use case
TotalPassedFailedIgnoredKnown issues
62224058117
Test Rate: 100%, With Pass Rate: 88.99% and Fail Rate: 11.11%
#### Mdoc mdl Use case
TotalPassedFailedIgnoredKnown issues
62219058617
Test Rate: 100%, With Pass Rate:95% and Fail Rate: 5%
## Defect Metrics ### Defect Metrics for the Release 0.14.0 The following table depicts only the bugs which are found and not addressed in the current release. Table: Defect Metrics for the Release
BlockerCriticalMajorMinorTotal
00617
## Conclusion This section summarizes the key findings of test execution. It also provides a final QA recommendation on the build's readiness for release. The functional verification for Inji certify release version 0.14.0 has been successfully completed. The testing cycle achieved a 100% execution rate with a 97% pass rate across a total of 880 test cases. Additionally, API automation achieved an average of 95% across different use cases. While there are 18 open defects (14 Major, 4 Minor) and as known issues, there are zero blocker defects that are open. Testing has demonstrated functional stability and data integrity consistent with product specifications. ### QA Approval The build has successfully met the defined exit criteria and is recommended for release. The approval is based on the following satisfied conditions: * Test Case Execution Completion: 100% of planned scenarios executed. * Defect Status: No Blocker defects remain open. * Documentation Sign-off: Reports are finalized. * Test Environment Stability: The test environment remained stable throughout the execution cycle. Table: Report is signed off details
NameFunctional RoleResponsibilities
Chaitanya KQA Manager
Ragini KrishnaSenior QA Manager
## Appendix This includes additional reference information for the report. It contains a history of document versions and a list of acronyms and their meanings. ### Appendix A: Versions
VersionDateAuthorReviewers
V1.017/03/2026Likhitha R L

Chaitanya K

Ragini Krishna

### Appendix B: Acronyms
AcronymLiteral Translation
MOSIPModular Open-Source Identity Platform
UINUnique Identification Number
VIDVirtual Identification
SVGScalable Vector Graphics
SD-JWTSelective Disclosure - JSON Web Token
VCVerifiable Credentials
OpenID4VCOpenID for Verifiable Credentials
### Document History It outlines the strategy used to ensure a comprehensive evaluation.
VersionAuthorDateReviewAffected Sections
V1.0Likhitha R L17/03/2025
  1. Chaitanya Kesiraju
  2. Ragini Krishna
New Document
Refer to the github link for more on reports [**here**](https://github.com/mosip/test-management/tree/master/inji-certify/0.14.0). # Version 0.13.1 **Release Version**: v0.13.1 **Release Type:** Developer Release **Release Date:** 5th December, 2025 ### **Overview** Inji Certify v0.13.1 release includes an automation bug fix required to support the new features introduced in version 0.13.0. ### **Major Highlights / Features** * Corrected the certificate path in the automation scripts to ensure the appropriate certificates are used for generating biometric data during prerequisite creation for MOSIP ID use cases. ### Bug Fixes Here below is the bug which has been addressed as part of this release. | JIRA | Description | | ----------------------------------------------------------------- | -------------------------------------------------- | | [INJICERT-1279](https://mosip.atlassian.net/browse/INJICERT-1279) | Authenticate user API failing with test automation | ### Repository Released | Repository | Version | | ------------ | ------------------------------------------------------------- | | inji-certify | [v0.13.1](https://github.com/mosip/inji-certify/tree/v0.13.1) | ### Known Issues Below is the list of known issue(s) related to the release v0.13.1. To access all the known issues related to Inji Certify please refer [here](https://mosip.atlassian.net/issues/?filter=16603). | JIRA | Description | | ---------------------------------------------------------------- | ----------------------------------------- | | [INJICERT-43526](https://mosip.atlassian.net/browse/MOSIP-43526) | Hardcoded domain in IDA automation script | ### Compatible Modules | Repositories | Version | | --------------------- | ------------------------------------------------------------------------------- | | eSignet | [v1.6.2](https://github.com/mosip/esignet/tree/v1.6.2) | | IDA | [1.2.1.0](https://github.com/mosip/id-authentication/tree/v1.2.1.0) | | Sunbird C | [v2.0.0](https://github.com/Sunbird-RC/sunbird-rc-core/releases/tag/v2.0.0-rc3) | | esigent-mock-services | [v0.11.2](https://github.com/mosip/esignet-mock-services/tree/v0.11.2) | | commons | [v1.3.0-beta.3](https://github.com/mosip/commons/tree/v1.3.0-beta.3) | | key manager | [v1.3.0-beta.5](https://github.com/mosip/keymanager/tree/v1.3.0-beta.5) | | mimoto | [v0.18.1](https://github.com/mosip/mimoto/tree/v0.18.1) | | inji-web | [v0.13.1](https://github.com/mosip/inji-web/tree/v0.13.1) | ### Documentation * [Feature Documentation](https://docs.mosip.io/inji/inji-certify/functional-overview/features) * [Local Setup](https://docs.mosip.io/inji/inji-certify/build-and-deploy/local-setup) * [API Documentation](https://mosip.stoplight.io/docs/inji-certify/25f435617408e-inji-certify) * [Test Report](/inji-certify/releases/version-0.13.1/test-report) # Test Report ## Testing Scope The scope of testing is to verify fitment to the specification from the perspective of * Functionality * Deployability * Configurability * Customizability Verification is performed not only from the end user perspective but also from the System Integrator (SI) point of view. Hence Configurability and Extensibility of the software is also assessed. This ensures readiness of software for use in multiple countries. Since MOSIP is an “API First” product platform. Testing scope has been focused on the following features: * Automation (Mospid, Mock, Sunbird, Landregistry use cases) ## Test Approach Persona based approach has been adopted to perform the IV\&V, by simulating test scenarios that resemble real-time implementation. A Persona is a fictional character/user profile created to represent a user type that might use a product/or a service in a similar way. Persona based testing is a software testing technique that puts software testers in the customer's shoes, assesses their needs from the software and thereby determines use cases/scenarios that the customers will execute. The persona needs may be addressed through any of the following. * Functionality * Deployability * Configurability * Customizability The verification methods may differ based on how the need was addressed. ## Verified configuration Verification is performed on configurations as mentioned below * Default configuration * English ## Feature Health
**Note**: For Esignet compatibility * eSignet 1.6.2 from released env ## Test execution statistics ### Functional test results Below are the test metrics by performing functional testing. The process followed was black box testing which based its test cases on the specifications of the software component under test. Functional test was performed in combination of individual module testing as well as integration testing. Test data were prepared in line with the user stories. Expected results were monitored by examining the user interface. The coverage includes GUI testing, System testing, and End-To-End flows across multiple configurations. The testing cycle included simulation of multiple identity schema and respective UI schema configurations.
TotalPassedFailedNA
78377290
Test Rate: 100%, With Pass Rate: 98.5% and Fail Rate: 2%
Automation Statistics * Sunbird use case
TotalPassedFailedIgnoredKnown issues
56072045335
Test Rate: 100%, With Pass Rate: 88.9% and Fail Rate: 11.1%
* Mock Use case
TotalPassedFailedIgnoredKnown issues
56050047535
Test Rate: 100%, With Pass Rate: 94.3% and Fail Rate: 5.7%
* Mock (Data provider) Landregistry Use case
TotalPassedFailedIgnoredKnown Issues
560199019935
Test Rate: 100%, With Pass Rate: 93.4% and Fail Rate: 6.6%
* MosipId Use case
TotalPassedFailedIgnoredKnown Issues
56064046135
Test Rate: 100%, With Pass Rate: 87.7% and Fail Rate: 12.3%
**Note** - Ignored scenarios are not related to particular use cases and 35 scenarios are known issues can be tracked from INJICERT-681, INJICERT-1118, INJICERT-1176 ### Detailed Test Metrics Below are the detailed test metrics by performing manual/automation testing. The project metrics are derived from Defect density, Test coverage, Test execution coverage, test tracking and efficiency. The various metrics that assist in test tracking and efficiency are as follows: * Passed Test Cases Coverage: It measures the percentage of passed test cases. (Number of tests passed / Total number of tests executed) x 100 * Failed Test Case Coverage: It measures the percentage of all the failed test cases. (Number of failed tests / Total number of test cases executed) x 100 ## Tested with Components
Module/RepoImagePOM versionDependent artifactIDComments
Inji-certify-mosipidmosipqa/inji-certify-with-plugins:0.13.x
Inji-certify-mockmosipqa/inji-certify-with-plugins:0.13.x
Inji-certify-Insurancemosipqa/inji-certify-with-plugins:0.13.x
Inji-certify- landregistrymosipqa/inji-certify-with-plugins:0.13.x
Mdoc-mdlmosipqa/inji-certify-with-plugins:0.13.x
Inji-configReleasing from release-0.12.x branchhttps://github.com/mosip/inji-config/tree/release-0.12.x
eSigneteSignet-1.6.2
KeymanagerAs a library1.3.0-beta.5(1.3.0-SNAPSHOT)Getting release with branch name release-1.3.x
Refer to the github link for more on reports [**here**](https://github.com/mosip/test-management/tree/master/inji-certify/0.13.1). # Version 0.13.0 **Release Version** 0.13.0 **Release Type**: Developer Release **Release Date**: 28th November, 2025 ## Overview Inji Certify v0.13.0 introduces major advances in credential issuance and lifecycle management and this includes the following: * A full implementation of the **Revocation Flow** enabling issuers to mark credentials as revoked and track them with a ledger. * Support to upload **Externally-signed CA Certificates** into the key-management workflow, allowing organizations to use their own PKI for signing credentials. * Full implementation of the **SD-JWT - Selective Disclosure JWT** issuance feature. * Updated Docker-Compose support that aligns with the latest versions of the associated modules (Inji Web & Mimoto). ## Major Highlights & Features The [**Revocation**](https://docs.inji.io/inji-certify/overview/features#id-7.-revocation-mechanism-json-ld-only) feature is now fully functional, issuers can revoke VCs, and the ledger can be configured for indexing to support efficient search for revocation lookup. Organizations can now integrate their own PKI by uploading [**externally-signed CA Certificates**](https://docs.inji.io/inji-certify/overview/features#id-11.-vc-signing-with-external-ca-signed-certificates) into Inji Certify's Key Manager. You can now Issue Credentials in [**SD-JWT - Selective Disclosure JWT**](https://docs.inji.io/inji-certify/overview/features#id-4.-support-for-multiple-credential-formats) format, offering issuers selective disclosure capabilities and enhanced privacy options. * **Revocation Implementation** The [**Revocation**](https://docs.inji.io/inji-certify/overview/features#id-7.-revocation-mechanism-json-ld-only) feature is now fully functional, issuers can revoke VCs, and the ledger can be configured for indexing to support efficient search for revocation lookup. * **Externally Signed Certificate Upload** Organizations can now integrate their own PKI by uploading [**externally-signed CA Certificates**](https://docs.inji.io/inji-certify/overview/features#id-11.-vc-signing-with-external-ca-signed-certificates) into Inji Certify's Key Manager. New APIs allow the following steps: * Generate a CSR via the generateCSR endpoint. * Upload the CA certificate via the upload-ca-certificate endpoint. * Upload the signed certificate via the uploadCertificate endpoint. * Once configured, the system’s key manager uses these externally signed certificates to generate keys and sign VCs. * **SD-JWT Implementation** You can now Issue Credentials in [**SD-JWT - Selective Disclosure JWT**](https://docs.inji.io/inji-certify/overview/features#id-4.-support-for-multiple-credential-formats) format, offering issuers selective disclosure capabilities and enhanced privacy options. * **Docker-Compose Upgrade** We have now Updated The docker-compose.yml definitions to reference latest versions of Inji Web and Mimoto, helping streamline environment setup, testing, and CI/CD workflows. ## User Stories Released
FeatureDescriptionJIRA
Revocation of VCSearching VC to be revokedINJICERT-1116
Enabling revocation through configuration using APIINJICERT-1139
Support for latest mimoto & Inji WebEnabling docker compose setup to support latest released version of mimoto and Inji WebINJICERT-1164
Decouple Ledger Search Table Updates from Credential StatusEnabling Ledger as a feature to use without revocationINJICERT-1173
Enable Ledger SearchEnabling Ledger search based on id, statuslisindex and statuslistcredentialINJICERT-1207
Multiple language VC issuanceIssuing VC with multiple language based on the data present in data sourceINJICERT-1220
Allowing to upload external CA certificateExposing key manager API through certify to upload CA certificateINJICERT-1259
## Bug Fixes Below are a few key bugs that have been addressed as part of this release. Please click [here](https://mosip.atlassian.net/jira/software/c/projects/INJICERT/issues/?jql=project%20%3D%20%22INJICERT%22%20AND%20fixVersion%20%3D%200.13.0%20AND%20type%3DBug) to learn more about the issues that have been resolved:
JIRADescription
INJICERT-1126Incorrect x5c Field in JWT Header – Certificate Passed Instead of Full Trust Chain
INJICERT-1180Issue while fetching VC from inji mobile with signed using RSA signature
INJICERT-1183Issues in Credential config APIs
INJICERT-1185Config dependency for did url is still exists
INJICERT-1186VC fetch is failing for 2.0 model from docker compose
INJICERT-1214Unable to decode encoded list of credentialStatus
INJICERT-1217Ledger Search API supports credentialId as an optional parameter, then should be treated as null
INJICERT-1218Automation scripts are using ClientID as the jti value.
INJICERT-1240Land regsitry usecase 2.0 model VC fetch is failing with unknown error -Query did not return a unique result: 2 results were returned
INJICERT-1241Mosipid VC fetch is failing with error "IDA-MLC-007"
INJICERT-1262License compliance issue-inji-certify
### Known Issues Below is the list of known issues related to the release v0.13.0. To access all known issues related to Inji Certify please click [**here**](https://mosip.atlassian.net/issues/INJICERT-852?filter=11419\&jql=project%20%3D%20%22Inji%20Certify%22%20AND%20issuetype%20%3D%20Bug%20%20AND%20labels%20not%20in%20%28API_Automation%2C%20AWSdevicefarm%2C%20device_specific%2C%20qa-inji-UI-auto%29%20%20and%20status%20NOT%20IN%20%28Closed%2C%20Fixed%2C%20Canceled%2CCancelled%29%20%20ORDER%20BY%20created%20DESC%2C%20updated%20DESC)**.**
JIRADescription
INJICERT-1265Upload ca cert for ecck1 signalgo is failing
INJICERT-1279Authenticate user API failing with test automation
## Repository Released
RepositoriesTags
inji-certifyv0.13.0
inji-configv0.12.0
keymanagerv1.3.0-beta.5
mosip-functional-testsv1.3.5
## Compatible Modules | Modules | Version | | --------------------- | ------------------------------------------------------------------------------- | | eSignet | [v1.6.2](https://github.com/mosip/esignet/tree/v1.6.2) | | IDA | [1.2.1.0](https://github.com/mosip/id-authentication/tree/v1.2.1.0) | | Sunbird C | [v2.0.0](https://github.com/Sunbird-RC/sunbird-rc-core/releases/tag/v2.0.0-rc3) | | esignet-mock-services | [v0.11.2](https://github.com/mosip/esignet-mock-services/tree/v0.11.2) | | commons | [v1.3.0-beta.3](https://github.com/mosip/commons/tree/v1.3.0-beta.3) | | keymanager | [v1.3.0-beta.5](https://github.com/mosip/keymanager/tree/v1.3.0-beta.5) | | mimoto | [v0.18.1](https://github.com/mosip/mimoto/tree/v0.18.1) | | inji-web | [v0.13.1](https://github.com/mosip/inji-web/tree/v0.13.1) | ## Documentation * [Feature Documentation](https://docs.mosip.io/inji/inji-certify/functional-overview/features) * [Local Setup](https://docs.mosip.io/inji/inji-certify/build-and-deploy/local-setup) * [API Documentation](https://mosip.stoplight.io/docs/inji-certify/25f435617408e-inji-certify) * [Test Report](https://docs.inji.io/inji-certify/releases/version-0.13.0/test-report) # Test Report ## Testing Scope The scope of testing is to verify fitment to the specification from the perspective of * Functionality * Deployability * Configurability * Customizability Verification is performed not only from the end user perspective but also from the System Integrator (SI) point of view. Hence Configurability and Extensibility of the software is also assessed. This ensures readiness of software for use in multiple countries. Since MOSIP is an “API First” product platform. Testing scope has been focused on the following features: * Inji certify Docker compose testing (Data provider CSV plugin, Data provider Postgres plugin) * Insurance, MosipId and Mock (Issuance and Data provider (Postgres plugin)), which covered Land registry, school and Framer use case * Integration with Inji Web and Inji verify * DB upgrade scripts testing, Backward compatibility - from Docker setup * Sd\_jwt format * Revocation feature * CSR certificate(generate, upload and fetch) * Multi language support for VC * Svg render method ## Test Approach Persona based approach has been adopted to perform the IV\&V, by simulating test scenarios that resemble real-time implementation. A Persona is a fictional character/user profile created to represent a user type that might use a product/or a service in a similar way. Persona based testing is a software testing technique that puts software testers in the customer's shoes, assesses their needs from the software and thereby determines use cases/scenarios that the customers will execute. The persona needs may be addressed through any of the following. * Functionality * Deployability * Configurability * Customizability The verification methods may differ based on how the need was addressed. ## Verified configuration Verification is performed on configurations as mentioned below * Default configuration * English * Supported multi language according to configuration ## Feature Health
**Note**: For Esignet compatibility * eSignet 1.6.2 from released env * Docker compose testing – esignet from collab env by default ## Test execution statistics ### Functional test results Below are the test metrics by performing functional testing. The process followed was black box testing which based its test cases on the specifications of the software component under test. Functional test was performed in combination of individual module testing as well as integration testing. Test data were prepared in line with the user stories. Expected results were monitored by examining the user interface. The coverage includes GUI testing, System testing, and End-To-End flows across multiple configurations. The testing cycle included simulation of multiple identity schema and respective UI schema configurations.
TotalPassedFailedNA
78377290
Test Rate: 100%, With Pass Rate: 98.5% and Fail Rate: 2%
**Automation Statistics** * Sunbird use case
TotalPassedFailedIgnoredKnown issues
56072045335
Test Rate: 100%, With Pass Rate: 88.9% and Fail Rate: 11.1%
**Mock Use case**
TotalPassedFailedIgnoredKnown issues
56050047535
Test Rate: 100%, With Pass Rate: 94.3% and Fail Rate: 5.7%
**Mock (Data provider) Landregistry Use case**
TotalPassedFailedIgnoredKnown Issues
560199019935
Test Rate: 100%, With Pass Rate: 93.4% and Fail Rate: 6.6%
**MosipId Use case** **Note** - Ignored scenarios are not related to particular use cases and 35 scenarios are known issues can be tracked from INJICERT-681, INJICERT-1118, INJICERT-1176 ### Detailed Test Metrics Below are the detailed test metrics by performing manual/automation testing. The project metrics are derived from Defect density, Test coverage, Test execution coverage, test tracking and efficiency. The various metrics that assist in test tracking and efficiency are as follows: * Passed Test Cases Coverage: It measures the percentage of passed test cases. (Number of tests passed / Total number of tests executed) x 100 * Failed Test Case Coverage: It measures the percentage of all the failed test cases. (Number of failed tests / Total number of test cases executed) x 100 ## Tested with Components
Module/RepoImagePOM versionDependent artifactIDComments
Inji-certify-mosipidmosipqa/inji-certify-with-plugins:0.13.xDigital-credential-plugin - 0.5.0
Inji-certify-mockmosipqa/inji-certify-with-plugins:0.13.xDigital-credential-plugin - 0.5.0
Inji-certify-Insurancemosipqa/inji-certify-with-plugins:0.13.xDigital-credential-plugin - 0.5.0
Inji-certify- landregistrymosipqa/inji-certify-with-plugins:0.13.xDigital-credential-plugin - 0.5.0
Mdoc-mdlmosipqa/inji-certify-with-plugins:0.13.xDigital-credential-plugin - 0.5.0
Inji-configReleasing from release-0.12.x branchDigital-credential-plugin - 0.5.0https://github.com/mosip/inji-config/tree/release-0.12.x
eSigneteSignet-1.6.2
KeymanagerAs a library1.3.0-beta.5(1.3.0-SNAPSHOT)Getting release with branch name release-1.3.x
# Version 0.12.2 **Release Version:** 0.12.2 **Release Type:** Developer Release **Release Date:** 23rd October, 2025 ### **Overview** Inji Certify v0.12.2 focuses on enabling issuers with greater control and flexibility in managing their credential signing infrastructure, while also improving usability and operational stability. This release introduces new issuer-facing APIs that allow seamless integration with external Certificate Authorities (CAs) through a complete CSR generation and signed certificate upload workflow. By orchestrating with Key Manager, Certify ensures that issuers can securely generate CSRs, validate and store CA-signed certificates, and immediately leverage them for VC signing, thereby expanding deployment capacity and supporting sovereign CA setups. Alongside this core capability, the release also improves accessibility for external users by updating key documentation references and Postman collections to point to the collaboration environment, ensuring a smoother setup and integration experience. Additionally, database scripts now include the Shedlock table, resolving prior gaps and providing reliable distributed job scheduling for production deployments. Together, these enhancements not only extend the functional capacity of Certify but also strengthen its readiness for large-scale, real-world integrations. ### **Major Highlights / Features** * **CSR & Certificate Management APIs** – Certify now exposes APIs to generate CSRs via Key Manager for `aphid`and `refid`, download them, and upload externally signed certificates. Uploaded certificates are validated and securely stored, enabling their use in VC signing. * **Updated Documentation Links** – Postman collections and reference URLs have been updated to point to the collaboration environment, ensuring external users can easily test and integrate. * **Database Script Correction** – Shedlock table has been added to DB scripts to support distributed job scheduling and ensure reliable execution in production setups. ### Bug Fixes
JIRADescription
INJICERT-1237Allow issuer to generate CSR for app id and ref id to enable external CA signing and certificate upload into certify
INJICERT-1238Update Postman Collection to refer collab environment
INJICERT-1242Enabling shedlock table to facilitate scheduled jobs within certify
### Known Issues Below is the list of known issues related to the release v0.12.2. To access all known issues related to Inji Certify please click [**here**](https://mosip.atlassian.net/issues/INJICERT-852?filter=11419\&jql=project%20%3D%20%22Inji%20Certify%22%20AND%20issuetype%20%3D%20Bug%20%20AND%20labels%20not%20in%20%28API_Automation%2C%20AWSdevicefarm%2C%20device_specific%2C%20qa-inji-UI-auto%29%20%20and%20status%20NOT%20IN%20%28Closed%2C%20Fixed%2C%20Canceled%2CCancelled%29%20%20ORDER%20BY%20created%20DESC%2C%20updated%20DESC)
JIRADescription
INJICERT-1249SD-JWT VC fetch is failing after CSR generated and uploaded to certify
### Repository Released
RepositoriesTags
inji-certify0.12.2
### Compatible Modules The following table outlines the tested and certified compatibility of 0.12.2 with other modules. | Module | Version (with tag links) | | --------------------- | ------------------------------------------------------------------------------- | | eSignet | [v1.6.2](https://github.com/mosip/esignet/tree/v1.6.2) | | IDA | [v1.2.1.0](https://github.com/mosip/id-authentication/tree/v1.2.1.0) | | Sunbird C | [v2.0.0](https://github.com/Sunbird-RC/sunbird-rc-core/releases/tag/v2.0.0-rc3) | | esignet-mock-services | [v0.11.2](https://github.com/mosip/esignet-mock-services/tree/v0.11.2) | | commons | [v1.3.0-beta](https://github.com/mosip/commons/tree/v1.3.0-beta.3).3 | | key-manager | [v1.3.0-beta.4](https://github.com/mosip/keymanager/tree/v1.3.0-beta.4) | | mimoto | [0.15.0](https://github.com/mosip/mimoto/tree/v0.15.0) (for docker compose) | | Inji-web | [0.11.0](https://github.com/mosip/inji-web/tree/v0.11.0) (for docker compose) | | Inji-web | [0.13.1](https://github.com/mosip/inji-web/tree/v0.13.1) | | mimoto | [0.18.1](https://github.com/mosip/mimoto/tree/v0.18.1) | ### Documentation * [Feature Documentation](https://docs.mosip.io/inji/inji-certify/functional-overview/features) * [Local Setup](https://docs.mosip.io/inji/inji-certify/build-and-deploy/local-setup) * [API Documentation](https://mosip.stoplight.io/docs/inji-certify/25f435617408e-inji-certify) * [Test Report](/inji-certify/releases/version-0.12.2/test-report) # Test Report ## Testing Scope The scope of testing is to verify fitment to the specification from the perspective of * Functionality * Deployability * Configurability * Customizability Verification is performed not only from the end user perspective but also from the System Integrator (SI) point of view. Hence Configurability and Extensibility of the software is also assessed. This ensures readiness of software for use in multiple countries. Since MOSIP is an “API First” product platform. Testing scope has been focused on the following features: * Inji certify Docker compose testing (Data provider CSV plugin, Data provider Postgres plugin) * Insurance, MosipId and Mock (Issuance and Data provider (Postgres plugin)), which covered Land registry use case * Integration with Inji Web and Inji verify * CSR generation for appid and refid to enable external CA signing and certificate upload to certify (except ES256K signature) * Postman readme changes in Docs (Docker compose) * Enabling of shedlock table ## Test Approach Persona based approach has been adopted to perform the IV\&V, by simulating test scenarios that resemble real-time implementation. A Persona is a fictional character/user profile created to represent a user type that might use a product/or a service in a similar way. Persona based testing is a software testing technique that puts software testers in the customer's shoes, assesses their needs from the software and thereby determines use cases/scenarios that the customers will execute. The persona needs may be addressed through any of the following: * Functionality * Deployability * Configurability * Customizability The verification methods may differ based on how the need was addressed. ## Verified Configuration Verification is performed on configurations as mentioned below * Default configuration: * English {% hint style="success" %} **Note:** Ignored scenarios are not related to particular use cases and 34 scenarios are known issues can be tracked from [INJICERT-681](https://mosip.atlassian.net/browse/INJICERT-681), [INJICERT-1118](https://mosip.atlassian.net/browse/INJICERT-1118), [INJICERT-1176](https://mosip.atlassian.net/browse/INJICERT-1176) {% endhint %} ### Functional Test Results Below are the test metrics by performing functional testing. The process followed was black box testing which based its test cases on the specifications of the software component under test. Functional test was performed in combination of individual module testing as well as integration testing. Test data were prepared in line with the user stories. Expected results were monitored by examining the user interface. The coverage includes GUI testing, System testing, and End-To-End flows across multiple configurations. The testing cycle included simulation of multiple identity schema and respective UI schema configurations.
TotalPassedFailedNA
769744220
Test Rate: 100%, With Pass Rate: 97% and Fail Rate: 3% #### Automation Statistics * Sunbird use case
TotalPassedFailedIgnoredKnown issues
44272033634
Test Rate: 100%, With Pass Rate: 90% and Fail Rate: 10% * Mock Use case
TotalPassedFailedIgnoredKnown issues
44250035834
Test Rate: 100%, With Pass Rate: 94.4% and Fail Rate: 5.6% * Mock (Data provider) Landregistry Use case
TotalPassedFailedIgnoredKnown Issues
442209019934
Test Rate: 100%, With Pass Rate: 94.6% and Fail Rate: 5.4% * MosipId Use case
TotalPassedFailedIgnoredKnown Issues
44264034434
Test Rate: 100%, With Pass Rate: 85.3% and Fail Rate: 14.7% {% hint style="success" %} **Note:** Ignored scenarios are not related to particular use cases and 34 scenarios are known issues can be tracked from [INJICERT-681](https://mosip.atlassian.net/browse/INJICERT-681), [INJICERT-1118](https://mosip.atlassian.net/browse/INJICERT-1118), [INJICERT-1176](https://mosip.atlassian.net/browse/INJICERT-1176) {% endhint %} ### Detailed Test Metrics Below are the detailed test metrics by performing manual/automation testing. The project metrics are derived from Defect density, Test coverage, Test execution coverage, test tracking and efficiency. The various metrics that assist in test tracking and efficiency are as follows: * Passed Test Cases Coverage: It measures the percentage of passed test cases. (Number of tests passed / Total number of tests executed) x 100 * Failed Test Case Coverage: It measures the percentage of all the failed test cases. (Number of failed tests / Total number of test cases executed) x 100 ## Tested with Components
Module/RepoImagePOM versionDependent artifactIDComments
Inji-certify-mosipidmosipqa/inji-certify-with-plugins:0.12.xDigital-credential-plugin - 0.5.0
Inji-certify-mockmosipqa/inji-certify-with-plugins:0.12.xDigital-credential-plugin - 0.5.0
Inji-certify-Insurancemosipqa/inji-certify-with-plugins:0.12.xDigital-credential-plugin - 0.5.0
Inji-certify- landregistrymosipqa/inji-certify-with-plugins:0.12.xDigital-credential-plugin - 0.5.0
Mdoc-mdlmosipqa/inji-certify-with-plugins:0.12.xDigital-credential-plugin - 0.5.0
Inji-configReleasing from release-0.10.x branchDigital-credential-plugin - 0.5.0https://github.com/mosip/inji-config/tree/release-0.10.x
eSigneteSignet-1.6.1
KeymanagerAs a library1.3.0-beta.4(1.3.0-SNAPSHOT)
Click [here](https://github.com/mosip/test-management/tree/master/inji-certify/0.12.2) to view the detailed test report. # Version 0.12.1 **Release Version:** 0.12.1 **Release Type:** Developer Release **Release Date:** 11th September, 2025 ## Overview **Inji Certify v0.12.1**, brings enhancements in automation of testing to support latest eSignet release v1.6.2 ## Major Highlights/ Features Support for eSignet v1.6.2 – Test automation has been updated to accommodate the blocker change requiring `jti` in the authentication request. With this fix, the automation now fully supports [eSignet v1.6.2](https://docs.esignet.io/roadmap-and-releases/versions/v1.6.2). ## Bug Fixes | **JIRA** | **Description** | | ----------------------------------------------------------------- | -------------------------------------------------------------------------- | | [INJICERT-1200](https://mosip.atlassian.net/browse/INJICERT-1200) | Update Automation Script - Support jti attribute during eSignet api access | ## Known Issue Below is the list of known issues related to the release v0.12.0. To access all known issues related to Inji Certify please click [**here**](https://mosip.atlassian.net/issues/INJICERT-852?filter=11419\&jql=project%20%3D%20%22Inji%20Certify%22%20AND%20issuetype%20%3D%20Bug%20%20AND%20labels%20not%20in%20%28API_Automation%2C%20AWSdevicefarm%2C%20device_specific%2C%20qa-inji-UI-auto%29%20%20and%20status%20NOT%20IN%20%28Closed%2C%20Fixed%2C%20Canceled%2CCancelled%29%20%20ORDER%20BY%20created%20DESC%2C%20updated%20DESC) | **JIRA** | **Description** | | ----------------------------------------------------------------- | ------------------------------------------------------ | | [INJICERT-1218](https://mosip.atlassian.net/browse/INJICERT-1218) | Automation scripts are using ClientID as the jti value | ## Repository Released | **Repositories** | **Tags Released** | | ---------------- | ------------------------------------------------------------- | | inji-certify | [v0.12.1](https://github.com/mosip/inji-certify/tree/v0.12.1) | ## Compatible Modules The following table outlines the tested and certified compatibility of \ with other modules. | **Module** | **Version (with tag links)** | | --------------------- | ------------------------------------------------------------------------------- | | eSignet | [v1.6.2](https://github.com/mosip/esignet/tree/v1.6.2) | | IDA | [v1.2.1.0](https://github.com/mosip/id-authentication/tree/v1.2.1.0) | | Sunbird C | [v2.0.0](https://github.com/Sunbird-RC/sunbird-rc-core/releases/tag/v2.0.0-rc3) | | esignet-mock-services | [v0.11.2](https://github.com/mosip/esignet-mock-services/tree/v0.11.2) | | commons | [v1.3.0-beta](https://github.com/mosip/commons/tree/v1.3.0-beta.3).3 | | key-manager | [v1.3.0-beta.4](https://github.com/mosip/keymanager/tree/v1.3.0-beta.4) | | mimoto | [0.15.0](https://github.com/mosip/mimoto/tree/v0.15.0) (for docker compose) | | Inji-web | [0.11.0](https://github.com/mosip/inji-web/tree/v0.11.0) (for docker compose) | | Inji-web | [0.13.1](https://github.com/mosip/inji-web/tree/v0.13.1) | | mimoto | [0.18.1](https://github.com/mosip/mimoto/tree/v0.18.1) | ## Documentation * [Feature Documentation](https://docs.mosip.io/inji/inji-certify/functional-overview/features) * [Local Setup](https://docs.mosip.io/inji/inji-certify/build-and-deploy/local-setup) * [API Documentation](https://mosip.stoplight.io/docs/inji-certify/25f435617408e-inji-certify) # Version 0.12.0 Release Version: 0.12.0 Release Type: Developer Release Release Date: 26th August, 2025 ### Overview **Inji Certify v0.12.0**, brings significant enhancements in credential issuance, revocation, and cryptographic support. This release continues our commitment to aligning with emerging standards while providing issuers with flexible configuration and integration capabilities. ### Major Highlights/ Features * Credential Formats – Draft Implementation * SD-JWT and JWT support: Draft implementation enabling issuers to issue credentials in Selective Disclosure JWT (SD-JWT) format, expanding interoperability across wallets. Refer to [feature description](https://docs.inji.io/inji-certify/overview/features#support-for-multiple-credential-formats) to know more about this feature * VC Configuration & Binding * Configurable VC Type: Issuers can now configure the VC Type dynamically, providing greater flexibility for different issuance use cases. Refer to [feature description](https://docs.inji.io/inji-certify/overview/features#addition-of-credential-type-via-api-post-onboarding) for more details. * DID Binding with did key:key: Added support for binding credentials to did:key, enhancing decentralization and cryptographic agility. * DID Binding with did:web for `kid` generation: Introduced support for did:web and automated key ID (kid) generation to enable smooth VC issuance in SD-JWT format. * Revocation – Draft Implementation * VC Revocation: Initial draft implementation of revocation capabilities, allowing issuers to mark credentials as revoked and support verifiers in checking credential status. Refer to [feature description](https://docs.inji.io/inji-certify/overview/features#revocation-mechanism-draft-release-experimental-json-ld-only) for more details. * Cryptography & Data Integrity * Data Integrity Support: Added support for W3C Data Integrity Proofs, providing a standards-based mechanism for ensuring verifiability of issued credentials. * ECC R1 Curve Support: Extended cryptographic suite with support for Elliptic Curve secp256r1 (P-256), enabling broader adoption and compliance. Refer to [feature description](https://docs.inji.io/inji-certify/overview/features#efficient-signing-with-multiple-algorithms) for more details. {% hint style="info" %} Note: * When configuring the VC type, ensure that the `didUrl` value in the config file matches the value sent through the API; otherwise, VC issuance will fail. * The VC Revocation feature is enabled by default for all VCs configured in Inji Certify. Configuration options to customise this will be introduced in an upcoming release. * VC Revocation and SD-JWT support are released as draft features. They are marked as draft since additional enhancements are still in progress to enable the complete end-to-end flow and to complete comprehensive regression testing. {% endhint %} ### User Stories Released | Feature | Description | JIRA | | ---------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Addition/Configuration of Verifiable Credential Type via API post onboarding | Enabling issuer configure new VC types based on the requirement at any time | [INJICERT-769](https://mosip.atlassian.net/browse/INJICERT-769) | | | Enabling additional validation to support the configuration of VC type addition | [INJICERT-1036](https://mosip.atlassian.net/browse/INJICERT-1036) | | Revocation of VC | Searching VC to be revoked | [INJICERT-1116](https://mosip.atlassian.net/browse/INJICERT-1116) | | | Revoking VC through API | [INJICERT-792](https://mosip.atlassian.net/browse/INJICERT-792) | | Support for VC Issuance with SD-JWT format | Enable Trust Element in VC Format (SD-JWT) Using did:web in iss Attribute | [INJICERT-1060](https://mosip.atlassian.net/browse/INJICERT-1060) | | | Issuing VC in SD-JWT Format | [INJICERT-61](https://mosip.atlassian.net/browse/INJICERT-61) | | | Enabling key manager to support did:web binding for VC signing | [MOSIP-41756](https://mosip.atlassian.net/browse/MOSIP-41756) | | Data Integrity Proof | Support for W3C **Data Integrity Proofs** | [INJICERT-1033](https://mosip.atlassian.net/browse/INJICERT-1033) | | Code Refactoring | Refactoring code to enhance the code quality of the application |

INJICERT-978

INJICERT-768

| | Signing VC with ECC R1 Algorithm | Extending application’s capability of VC signing and providing support to sign with ECC R1 algorithm | [INJICERT-977](https://mosip.atlassian.net/browse/INJICERT-977) | | DID integration for VC | Allows credentials to be cryptographically bound to a DID, ensuring stronger identity association and verifiability | [INJICERT-522](https://mosip.atlassian.net/browse/INJICERT-522) | ### Bug Fixes | JIRA | Description | | ----------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------- | | [INJICERT-1184](https://mosip.atlassian.net/browse/INJICERT-1184) | StatusListCredential in credential status of VC is not accessible | | [INJICERT-1178](https://mosip.atlassian.net/browse/INJICERT-1178) | Resolved an issue where certain test cases were failing with a `java.lang.NullPointerException` error. | | [INJICERT-1160](https://mosip.atlassian.net/browse/INJICERT-1160) | Fixed a bug related to VC download for land registry VC type | | [INJICERT-1156](https://mosip.atlassian.net/browse/INJICERT-1156) | Issue related to deploying Inji Certify with docker resolved | | [INJICERT-1155](https://mosip.atlassian.net/browse/INJICERT-1155) | resolved issue related to VC issuance post the DB changes introduced as part of the new feature change | | [INJICERT-1120](https://mosip.atlassian.net/browse/INJICERT-1120) | When credential config APIs used to add new credential type, we need to still update signature in git properties | | [INJICERT-903](https://mosip.atlassian.net/browse/INJICERT-903) | aud in Access Token Uses containsAll Instead of contains | | [INJICERT-544](https://mosip.atlassian.net/browse/INJICERT-544) | Certify doesn't give the @context of the VC it's downloading | | [INJICERT-324](https://mosip.atlassian.net/browse/INJICERT-324) | VC download is failing with credential type "LifeInsuranceCredential" | | [INJICERT-298](https://mosip.atlassian.net/browse/INJICERT-298) | VC download is failing with signature alg (ES256) supported values mentioned in well-known response | | [MOSIP-42537](https://mosip.atlassian.net/browse/MOSIP-42537) | Incorrect representation of x5c field in JWT header | ### Known Issues Below is the list of known issues related to the release v0.12.0. To access all known issues related to Inji Certify please click [**here**](https://mosip.atlassian.net/issues/INJICERT-852?filter=11419\&jql=project%20%3D%20%22Inji%20Certify%22%20AND%20issuetype%20%3D%20Bug%20%20AND%20labels%20not%20in%20%28API_Automation%2C%20AWSdevicefarm%2C%20device_specific%2C%20qa-inji-UI-auto%29%20%20and%20status%20NOT%20IN%20%28Closed%2C%20Fixed%2C%20Canceled%2CCancelled%29%20%20ORDER%20BY%20created%20DESC%2C%20updated%20DESC) | JIRA | Description | | ----------------------------------------------------------------- | ------------------------------------------------------------------------------------------------- | | [INJICERT-1185](https://mosip.atlassian.net/browse/INJICERT-1185) | Config dependency for did url is still exists | | [INJICERT-1182](https://mosip.atlassian.net/browse/INJICERT-1182) | "credentialStatusPurposes" from credential config API is getting overwritten by git configuration | | [INJICERT-1176](https://mosip.atlassian.net/browse/INJICERT-1176) | VC fetch is failing for proof\_jwt with did:key binding for ES256 signature only | ### Repositories Released | Repositories | Tags Released | | -------------------------- | ------------------------------------------------------------------------- | | inji-certify | [v0.12.0](https://github.com/mosip/inji-certify/tree/v0.12.0) | | digital-credential-plugins | [v0.5.0](https://github.com/mosip/digital-credential-plugins/tree/v0.5.0) | | inji-config | [v0.10.0](https://github.com/mosip/inji-config/tree/v0.10.0) | | key manager | [v1.3.0-beta.4](https://github.com/mosip/keymanager/tree/v1.3.0-beta.4) | | commons | [v1.3.0-beta.3](https://github.com/mosip/commons/tree/v1.3.0-beta.3) | ### Compatible Modules The following table outlines the tested and certified compatibility of \ with other modules. | Modules | Version (with tag links) | | --------------------- | ------------------------------------------------------------------------------- | | eSignet | [v1.5.1](https://github.com/mosip/esignet/tree/v1.5.1) | | id-authentication | [v1.2.1.0](https://github.com/mosip/id-authentication/tree/v1.2.1.0) | | Sunbird C | [v2.0.0](https://github.com/Sunbird-RC/sunbird-rc-core/releases/tag/v2.0.0-rc3) | | esignet-mock-services | [v0.10.1](https://github.com/mosip/esignet-mock-services/tree/v0.10.1) | ### Documentation * [Feature Documentation](https://docs.mosip.io/inji/inji-certify/functional-overview/features) * [QA Report](/inji-certify/releases/version-0.12.0/test-report) * [Local Setup](https://docs.mosip.io/inji/inji-certify/build-and-deploy/local-setup) * [API Documentation](https://mosip.stoplight.io/docs/inji-certify/25f435617408e-inji-certify) # Test Report ## Testing Scope The scope of testing is to verify fitment to the specification from the perspective of * Functionality * Deployability * Configurability * Customizability Verification is performed not only from the end user perspective but also from the System Integrator (SI) point of view. Hence Configurability and Extensibility of the software is also assessed. This ensures readiness of software for use in multiple countries. Since MOSIP is an “API First” product platform. Testing scope has been focused on the following features: * Inji certify Docker compose testing (Data provider CSV plugin, Data provider Postgres plugin) * Insurance, MosipId and Mock (Issuance and Data provider (Postgres plugin)), which covered Land registry use case * Integration with Inji Web and Inji verify * ECCR1 signing of VC request * Did:key signing – scope from automation * Credential config APIs * DB upgrade scripts testing, Backward complatibility - from Docker setup * Sd\_jwt format (Draft implementation) * Revocation feature (Draft implementation) ## Test Approach Persona based approach has been adopted to perform the IV\&V, by simulating test scenarios that resemble real-time implementation. A Persona is a fictional character/user profile created to represent a user type that might use a product/or a service in a similar way. Persona based testing is a software testing technique that puts software testers in the customer's shoes, assesses their needs from the software and thereby determines use cases/scenarios that the customers will execute. The persona needs may be addressed through any of the following. * Functionality * Deployability * Configurability * Customizability The verification methods may differ based on how the need was addressed. ## Verified configuration Verification is performed on configurations as mentioned below * Default configuration * English ## Feature Health
{% hint style="info" %} Note: For Esignet compatibility * eSignet 1.5.1 from released env * Docker compose testing – esignet from collab env by default {% endhint %} ## Test execution statistics ### Functional test results Below are the test metrics by performing functional testing. The process followed was black box testing which based its test cases on the specifications of the software component under test. Functional test was performed in combination of individual module testing as well as integration testing. Test data were prepared in line with the user stories. Expected results were monitored by examining the user interface. The coverage includes GUI testing, System testing, and End-To-End flows across multiple configurations. The testing cycle included simulation of multiple identity schema and respective UI schema configurations.
TotalPassed
747723212
Test Rate: 99%, With Pass Rate: 97% and Fail Rate: 3%
Automation Statistics * Sunbird use case
TotalPassedFailedIgnoredKnown issues
44272033634
Test Rate: 100%, With Pass Rate: 90% and Fail Rate: 10%
* Mock Use case
TotalPassedFailedIgnoredKnown issues
44250035834
Test Rate: 100%, With Pass Rate: 94.4% and Fail Rate: 5.6%
\- Mock (Data provider) Landregistry Use case
TotalPassedFailedIgnoredKnown Issues
442209019934
Test Rate: 100%, With Pass Rate: 94.6% and Fail Rate: 5.4%
MosipId Use case
TotalPassedFailedIgnoredKnown Issues
44264034434
Test Rate: 100%, With Pass Rate: 85.3% and Fail Rate: 14.7%
{% hint style="info" %} Note: Ignored scenarios are not related to particular use cases and 34 scenarios are known issues can be tracked from INJICERT-681, INJICERT-1118, INJICERT-1176 {% endhint %} ### Detailed Test Metrics Below are the detailed test metrics by performing manual/automation testing. The project metrics are derived from Defect density, Test coverage, Test execution coverage, test tracking and efficiency. The various metrics that assist in test tracking and efficiency are as follows: * Passed Test Cases Coverage: It measures the percentage of passed test cases. (Number of tests passed / Total number of tests executed) x 100 * Failed Test Case Coverage: It measures the percentage of all the failed test cases. (Number of failed tests / Total number of test cases executed) x 100 ## Tested with Components
Module/RepoImagePOM versionDependent artifactIDComments
Inji-certify-mosipidmosipqa/inji-certify-with-plugins:0.12.xDigital-credential-plugin - 0.5.0
Inji-certify-mockmosipqa/inji-certify-with-plugins:0.12.xDigital-credential-plugin - 0.5.0
Inji-certify-Insurancemosipqa/inji-certify-with-plugins:0.12.xDigital-credential-plugin - 0.5.0
Inji-certify- landregistrymosipqa/inji-certify-with-plugins:0.12.xDigital-credential-plugin - 0.5.0
Mdoc-mdlmosipqa/inji-certify-with-plugins:0.12.xDigital-credential-plugin - 0.5.0
Inji-configReleasing from release-0.10.x branchDigital-credential-plugin - 0.5.0https://github.com/mosip/inji-config/tree/release-0.10.x
eSigneteSignet-1.5.1
KeymanagerAs a library1.3.0-beta.4(1.3.0-SNAPSHOT)Getting release with branch name release-1.3.x
Refer to the github link for more on reports [**here**.](https://github.com/mosip/test-management/tree/master/inji-certify/0.12.0). # Version 0.11.0 **Release Version**: v0.11.0 **Release Type**: Developer Release **Release** **Date**: 2nd May, 2025 ### Overview Inji Certify v0.11.0 brings major enhancements focused on improving security, standards compliance, and interoperability in verifiable credential issuance. This release expands cryptographic support, simplifies deployment, strengthens identity integration, and aligns closely with OpenID4VC and OpenID4VCI specifications. It also introduces initial support for third-party wallets and identity platforms, making Inji Certify more versatile and extensible in digital ID ecosystems. ### Major Highlights/Features * **Keycloak Integration**: Seamless integration with Keycloak has been introduced, providing secure, standards-based authentication aor verifiable credential issuance. * **Enabled for Interoperability and Integration**: Inji Certify now supports seamless interoperability with digital wallets that adhere to the OpenID for Verifiable Credentials (OpenID4VC) specification. Having gone through rigorous testing, Inji Certify now assures and attests that it can integrate effortlessly with any wallet designed to be interoperable and compliant with OpenID4VC standards and thereby enhancing its versatility and adoption in diverse ecosystems. * **Expanded Cryptographic Algorithm Support in Inji Certify**\ Inji Certify now offers enhanced cryptographic flexibility through support for additional signing algorithms: * **ECC K1 2019 Key Support**: Inji Certify supports signing and verification using ECC K1 2019 keys, enabling compatibility with a broader range of secure systems and ensuring robust security for verifiable credentials. * **Ed25519 Signing (2018 & 2020)**: Verifiable credential requests can now be signed using Ed25519 keys, compliant with both 2018 and 2020 specifications. This enhancement ensures interoperability with diverse ecosystems and aligns with modern cryptographic standards. * **eSignet v1.5.1 Compatibility**: Full support for eSignet 1.5.1. * **OpenID4VCI Compliance Improvements**: Docker Compose now supports redirection of the .well-known endpoint as per spec. * **Simplified Setup**: Dependency on Artifactory removed for streamlined deployment. ### Enhancements * Improved cryptographic flexibility through support of ECC K1 2019 and Ed25519 key types. * Enhanced ecosystem integration by supporting Keycloak and eSignet 1.5.1. * Support for Talaos and Altme wallets expands adoption in OpenID4VC ecosystems. * Alignments made with OpenID4VCI specs to improve compatibility and standard adherence. ### Bug Fixes | JIRA | Description | | --------------------------------------------------------------- | --------------------------------------------------------------------------------------------------- | | [INJICERT-867](https://mosip.atlassian.net/browse/INJICERT-867) | In docker compose, jar is still copied from one place to another place to continue with VC download | | [INJICERT-895](https://mosip.atlassian.net/browse/INJICERT-895) | Spec compliance - Issues | | [INJICERT-901](https://mosip.atlassian.net/browse/INJICERT-901) | Incorrect Required Claims in VC Issuance | | [INJICERT-902](https://mosip.atlassian.net/browse/INJICERT-902) | kid Not Set Correctly for did:jwk Verification | | [INJICERT-933](https://mosip.atlassian.net/browse/INJICERT-933) | Certify docker compose should also support redirection of the well-known as per OpenID4VCI | **Known Issues** Below is the list of known issues. To read in detail and view all the topics related to Inji Certify please click [**here**](https://mosip.atlassian.net/issues/INJICERT-852?filter=11419\&jql=project%20%3D%20%22Inji%20Certify%22%20AND%20issuetype%20%3D%20Bug%20%20AND%20labels%20not%20in%20%28API_Automation%2C%20AWSdevicefarm%2C%20device_specific%2C%20qa-inji-UI-auto%29%20%20and%20status%20NOT%20IN%20%28Closed%2C%20Fixed%2C%20Canceled%2CCancelled%29%20%20ORDER%20BY%20created%20DESC%2C%20updated%20DESC) | JIRA | Description | | --------------------------------------------------------------- | ------------------------------------------------------------------------------ | | [ES-2289](https://mosip.atlassian.net/browse/ES-2289) | Esignet Oauth API is failing intermittently | | [INJIVER-1069](https://mosip.atlassian.net/browse/INJIVER-1069) | The MOSIP UIN VC's created from reg-client are not verifiable from INJI-verify | ### Repository Released | Repositories | Tags Released | | -------------------------- | ------------------------------------------------------------------------- | | inji-certify | [v0.11.0](https://github.com/mosip/inji-certify/tree/v0.11.0) | | digital-credential-plugins | [v0.4.0](https://github.com/mosip/digital-credential-plugins/tree/v0.4.0) | | inji-config | [v0.8.0](https://github.com/mosip/inji-config/tree/v0.8.0) | ### Compatible Modules The following table outlines the tested and certified compatibility of \ with other modules. | Module | Version(With tag links) | | -------------------- | ------------------------------------------------------------------------------- | | eSignet | [v1.5.1](https://github.com/mosip/esignet/tree/v1.5.1) | | Sunbird C | [v2.0.0](https://github.com/Sunbird-RC/sunbird-rc-core/releases/tag/v2.0.0-rc3) | | Key Manager | [v1.3.0-beta.2](https://github.com/mosip/keymanager/tree/v1.3.0-beta.2) | | commons | [v1.3.0-beta.1](https://github.com/mosip/commons/tree/v1.3.0-beta.1) | | mock-identity-system | [v0.10.1](https://github.com/mosip/esignet-mock-services/tree/v0.10.0) | ## Documentation * [Functional Overview](https://docs.inji.io/inji-certify/overview) * [Feature Documentation](https://docs.inji.io/inji-certify/overview/features) * [API Documentation](https://mosip.stoplight.io/docs/inji-certify/25f435617408e-inji-certify) * [QA Report](https://docs.inji.io/inji-certify/releases/version-0.11.0/test-report) # Test Report ## Testing Scope The scope of testing is to verify fitment to the specification from the perspective of * Functionality * Deployability * Configurability * Customizability Verification is performed not only from the end user perspective but also from the System Integrator (SI) point of view. Hence Configurability and Extensibility of the software is also assessed. This ensures readiness of software for use in multiple countries. Since MOSIP is an “API First” product platform. Testing scope has been focused on the following features:\\ * Inji certify Docker compose testing (Removal of artifactory dependency – Data provider CSV plugin and mdoc plugin) which covered Farmer Use case * Esignet compatibility with 1.5.1 version and 1.4.1 version * Insurance, Mock (Issuance and Data provider (Postgres plugin)), MosipId which covered Land registry, school use case also * Integration with Inji Web and Inji verify * Keycloak integration with Injicertify * Ed25519 signing of VC request – Scope from automation * Support of ECC k1 verification signature ## Test Approach Persona based approach has been adopted to perform the IV\&V, by simulating test scenarios that resemble real-time implementation. A Persona is a fictional character/user profile created to represent a user type that might use a product/or a service in a similar way. Persona based testing is a software testing technique that puts software testers in the customer's shoes, assesses their needs from the software and thereby determines use cases/scenarios that the customers will execute. The persona needs may be addressed through any of the following. * Functionality * Deployability * Configurability * Customizability The verification methods may differ based on how the need was addressed. ## Verified configuration Verification is performed on configurations as mentioned below * Default configuration * English ## Feature Health
Note: 1. For keycloak integration – keycloak is pointing to dev2 env 2. For Esignet compatibility 1. eSignet 1.5.1 from dev2 env 2. eSignet 1.4.1 from released env ## Test execution statistics ### Functional test results Below are the test metrics by performing functional testing. The process followed was black box testing which based its test cases on the specifications of the software component under test. Functional test was performed in combination of individual module testing as well as integration testing. Test data were prepared in line with the user stories. Expected results were monitored by examining the user interface. The coverage includes GUI testing, System testing, and End-To-End flows across multiple configurations. The testing cycle included simulation of multiple identity schema and respective UI schema configurations.
TotalPassedFailedNA
643612282
Test Rate: 99%, With Pass Rate: 95% and Fail Rate: 4.35%
Automation Statistics * Sunbird use case
TotalPassedFailedIgnoredKnown issues
2256101559
Test Rate: 100%, With Pass Rate: 96% and Fail Rate: 4%
* Mock Use case
TotalPassedFailedIgnoredKnown issues
2254701699
Test Rate: 100%, With Pass Rate: 96% and Fail Rate: 4%
* Mock (Data provider) Use case
TotalPassedFailedIgnoredKnown Issues
2257901379
Test Rate: 100%, With Pass Rate: 96% and Fail Rate: 4%
{% hint style="info" %} **Note** - Ignored scenarios are Not related to particular use case and 9 scenarios are known issues can be tracked from INJICERT-681, Mosip id use case is being ignored from Automation for the current release. {% endhint %} ### Detailed Test Metrics Below are the detailed test metrics by performing manual/automation testing. The project metrics are derived from Defect density, Test coverage, Test execution coverage, test tracking and efficiency. The various metrics that assist in test tracking and efficiency are as follows: * Passed Test Cases Coverage: It measures the percentage of passed test cases. (Number of tests passed / Total number of tests executed) x 100 * Failed Test Case Coverage: It measures the percentage of all the failed test cases. (Number of failed tests / Total number of test cases executed) x 100 ## Tested with Components
Module/RepoImagePOM versionDependent artifactIDComments
Inji-certify-mosipidmosipqa/inji-certify-with-plugins:0.11.xDigital-credential-plugin - 0.4.0
Inji-certify-mockmosipqa/inji-certify-with-plugins:0.11.xDigital-credential-plugin - 0.4.0
Inji-certify-Insurancemosipqa/inji-certify-with-plugins:0.11.xDigital-credential-plugin - 0.4.0
Inji-certify- landregistrymosipqa/inji-certify-with-plugins:0.11.xDigital-credential-plugin - 0.4.0
Inji-certify- academicmosipqa/inji-certify-with-plugins:0.11.xDigital-credential-plugin - 0.4.0
Mdoc-mdlmosipqa/inji-certify-with-plugins:0.11.xDigital-credential-plugin - 0.4.0
Inji-configReleasing from release-0.8.x branchDigital-credential-plugin - 0.4.0https://github.com/mosip/inji-config/tree/release-0.8.x
Keymanager1.3.0-beta.2Will be released as 1.3.0-beta.2
eSignet

eSignet-1.4.1

eSignet-1.5.1

1.5.1 eSignet from dev2 env

1.4.1 eSignet from released env

# Version 0.10.2 **Release Version**: v0.10.2 (Patch) **Release Type**: Developer Release **Release** **Date**: 21st Feb, 2025 ## **Overview** This patch release **0.10.2** for **Inji Certify** addresses fixes related to release versions, ensuring that the correct images of **Inji Web** and **Mimoto** are selected during local deployment using **Docker Compose**. ## **Bug Fixes** Below is the list of bug fixes as part of the **0.10.2** release: | **Jira ID** | **Description** | | --------------------------------------------------------------- | ------------------------------------------------------------------- | | [INJICERT-926](https://mosip.atlassian.net/browse/INJICERT-926) | Unable to pull image of Inji web and mimoto during local deployment | ## **Repository Released** | **Repositories** | **Tags Released** | | -------------------------- | ----------------------------------------------------------------------------------- | | inji-certify | [**v0.10.2**](https://github.com/mosip/inji-certify/tree/v0.10.2) | | digital-credential-plugins | [**v0.10.0**](https://github.com/mosip/esignet-mock-services/tree/v0.10.0) | | artifactory | [**v0.10.0-INJI**](https://github.com/mosip/digital-credential-plugins/tree/v0.3.0) | | inji-config | [**v0.5.0**](https://github.com/mosip/inji-config/tree/v0.5.0) | | keymanager | [**v1.3.0-beta.2**](https://github.com/mosip/keymanager/tree/v1.3.0-beta.2) | ## **Compatible Modules** The following table outlines the tested and certified compatibility of \ with other modules. | **Module** | **Version(With tag links)** | | -------------------- | ----------------------------------------------------------------------------------- | | eSignet | [**v1.4.1**](https://github.com/mosip/esignet/tree/v1.4.1) | | Sunbird C | [**v2.0.0**](https://github.com/Sunbird-RC/sunbird-rc-core/releases/tag/v2.0.0-rc3) | | Key Manager | [**v1.3.0-beta.2**](https://github.com/mosip/keymanager/tree/v1.3.0-beta.2) | | commons | [**v1.3.0-beta.1**](https://github.com/mosip/commons/tree/v1.3.0-beta.1) | | mock-identity-system | [**v0.10.0**](https://github.com/mosip/esignet-mock-services/tree/v0.10.0) | ## Documentation: * [QA Report](https://docs.inji.io/inji-certify/releases/version-0.10.2/test-report) # Test Report ## Testing Scope The scope of testing is to verify fitment to the specification from the perspective of * Functionality * Deployability * Configurability * Customizability Verification is performed not only from the end user perspective but also from the System Integrator (SI) point of view. Hence Configurability and Extensibility of the software is also assessed. This ensures readiness of software for use in multiple countries. Since MOSIP is an "API First" product platform. Testing scope has been focused around the below features * Docker compose testing for Mock Data Provider plugin (csv), Framer use case - 1.1 & 2.0 VC * Integration with INJI Web - Limited to download only 1.1 VC ## Test Approach Persona based approach has been adopted to perform the IV\&V, by simulating test scenarios that resemble a real-time implementation. A Persona is a fictional character/user profile created to represent a user type that might use a product/or a service in a similar way. Persona based testing is a software testing technique that puts software testers in the customer's shoes, assesses their needs from the software and thereby determines use cases/scenarios that the customers will execute. The persona needs may be addressed through any of the following. * Functionality * Deployability * Configurability * Customizability The verification methods may differ based on how the need was addressed. ## Verified configuration Verification is performed on configurations as mentioned below * Default configuration * English **Note:** 1. Docker setup - Authorization endpoints pointing to **collab.mosip.net** ## Test execution statistics ### Automation Statistics #### Sunbird use case | **Total** | **Passed** | **Failed** | **Ignored** | | --------- | ---------- | ---------- | ----------- | | 129 | 53 | 0 | 67 | Test Rate: 100%,\ With Pass Rate: 96% and Fail Rate: 0% #### Mock use case | **Total** | **Passed** | **Failed** | **Ignored** | | --------- | ---------- | ---------- | ----------- | | 129 | 41 | 0 | 79 | Test Rate: 100%,\ With Pass Rate: 100% and Fail Rate: 0% #### Mosipid use case | **Total** | **Passed** | **Failed** | **Ignored** | | --------- | ---------- | ---------- | ----------- | | 129 | 26 | 0 | 94 | Test Rate: 100%,\ With Pass Rate: 100% and Fail Rate: 0% Ignored scenarios are not related to particular use case and 9 scenarios are known issues that can be tracked in INJICERT-681. ## Detailed Test metrics Below are the detailed test metrics by performing manual/automation testing. The project metrics are derived from Defect density, Test coverage, Test execution coverage, test tracking and efficiency. The various metrics that assist in test tracking and efficiency are as follows: * Passed Test Cases Coverage: It measures the percentage of passed test cases. (Number of tests passed / Total number of tests executed) x 100 * Failed Test Case Coverage: It measures the percentage of all the failed test cases. (Number of failed tests / Total number of test cases executed) x 100 # Version 0.10.1 **Release Version**: v0.10.1 **Release Type**: Developer Release **Release** **Date**: 3rd February, 2025 ### **Overview** Inji Certify continues to innovate by integrating new features that enhance the product's interoperability and adaptability, addressing the growing demand for verifiable credential (VC) issuance on digital platforms. This release introduces support for Data Model 2.0 and enables SVG rendering. Additionally, we've improved the deployment process, making it easier for users to configure and deploy Certify with various data sources ### **Major Highlights** 1. **Local deployment using docker compose** * Enabling local inji certify deployment via docker compose for easier setup and environment management with an externally deployed authentication setup like MOSIP's eSignet 2. **Support for VC 2.0 Data Model:** * Enabled Inji to generate credentials in the VC 2.0 format. * Introduced SVG templates for visually representing VC 2.0 credentials. * Implemented a VC Formatter to support formatting credentials in VC 1.1. 3. **Implementation of Data Provider Plugin** * Enabling inji certify to retreive data from different data sources using the data provider plugin. In this release the product support to interact with below 2 different data sources: 1. Postgres 2. CSV 4. **ED25519 (2018 & 2020) VC Signing** * Enhanced security with ED25519 Signature (2018 & 2020) signing. ### **Bug Fixes** Below is the list of bug fixes as part of the **0.10.1** release: | **Jira ID** | **Description** | | --------------------------------------------------------------- | ------------------------------------------------------- | | [INJICERT-316](https://mosip.atlassian.net/browse/INJICERT-316) | Mock VC containing additional attribute with null value | ### **Known Issues** Below is the list of known issues. To read in detail and view all the topics related to Inji Certify please click [**here**](https://mosip.atlassian.net/issues/INJICERT-852?filter=11419\&jql=project%20%3D%20%22Inji%20Certify%22%20AND%20issuetype%20%3D%20Bug%20%20AND%20labels%20not%20in%20%28API_Automation%2C%20AWSdevicefarm%2C%20device_specific%2C%20qa-inji-UI-auto%29%20%20and%20status%20NOT%20IN%20%28Closed%2C%20Fixed%2C%20Canceled%2CCancelled%29%20%20ORDER%20BY%20created%20DESC%2C%20updated%20DESC) | **Jira ID** | **Description** | | --------------------------------------------------------------- | -------------------------------------------------------------------------------------- | | [INJICERT-681](https://mosip.atlassian.net/browse/INJICERT-681) | Error messages are different in few scenarios | | [INJIWEB-1417](https://mosip.atlassian.net/browse/INJIWEB-1417) | Unable to download VC which is signed with RSA Signature 2018 or ED25519Signature 2018 | ### **Repository Released** | Repositories | Tags Released | | -------------------------- | ----------------------------------------------------------------------------------- | | inji-certify | [**v0.10.1**](https://github.com/mosip/inji-certify/tree/v0.10.1) | | digital-credential-plugins | [**v0.10.0**](https://github.com/mosip/esignet-mock-services/tree/v0.10.0) | | artifactory | [**v0.10.0-INJI**](https://github.com/mosip/digital-credential-plugins/tree/v0.3.0) | | inji-config | [**v0.5.0**](https://github.com/mosip/inji-config/tree/v0.5.0) | | keymanager | [**v1.3.0-beta.2**](https://github.com/mosip/keymanager/tree/v1.3.0-beta.2) | ### **Compatible Modules** The following table outlines the tested and certified compatibility of \ with other modules. | Module | Version(With tag links) | | -------------------- | ----------------------------------------------------------------------------------- | | eSignet | [**v1.4.1**](https://github.com/mosip/esignet/tree/v1.4.1) | | Sunbird C | [**v2.0.0**](https://github.com/Sunbird-RC/sunbird-rc-core/releases/tag/v2.0.0-rc3) | | Key Manager | [**v1.3.0-beta.2**](https://github.com/mosip/keymanager/tree/v1.3.0-beta.2) | | commons | [**v1.3.0-beta.1**](https://github.com/mosip/commons/tree/v1.3.0-beta.1) | | mock-identity-system | [**v0.10.0**](https://github.com/mosip/esignet-mock-services/tree/v0.10.0) | ### Documentation: * [Feature Documentation](https://docs.inji.io/inji-certify/functional-overview/features) * [Integration Guide](https://docs.inji.io/inji-certify/build-and-deploy/local-setup) * [QA Report](https://docs.inji.io/inji-verify/releases/version-0.10.1/test-report) # Test Report ## Testing Scope The scope of testing is to verify fitment to the specification from the perspective of: * Functionality * Deployability * Configurability * Customizability Verification is performed not only from the end user perspective but also from the System Integrator (SI) point of view. Hence Configurability and Extensibility of the software is also assessed. This ensures readiness of software for use in multiple countries. Since MOSIP is an "API First" product platform. **Testing scope has been focused around the below features:** * Inji certify Docker compose testing (Data provider plugin(csv), mdoc mdl) * Docker compose testing for Mock Data Provider plugin (csv), Farmer use case - 1.1 & 2.0 VC * Inji certify - Insurance use case using namespace (VC issuance plugin) - 1.1 VC * Inji certify - Mock IDA use case using namespace (Data provider plugin(Postgres)) - 1.1 & 2.0 VC * Inji certify - MOSIP ID use case using namespace (VC issuance plugin) - 1.1 VC * Integration with INJI Web - Limited to download only 1.1 VC ## Test Approach Persona based approach has been adopted to perform the IV\&V, by simulating test scenarios that resemble a real-time implementation. A Persona is a fictional character/user profile created to represent a user type that might use a product/or a service in a similar way. Persona based testing is a software testing technique that puts software testers in the customer's shoes, assesses their needs from the software and thereby determines use cases/scenarios that the customers will execute. The persona needs may be addressed through any of the following. * Functionality * Deployability * Configurability * Customizability The verification methods may differ based on how the need was addressed. ## Verified configuration **Verification is performed on configurations as mentioned below** * Default configuration * English ## Feature Health
{% hint style="success" %} **Note**: * **Docker setup** - Authorization endpoints pointing to **collab.mosip.net** * **Postgres plugin** - In Qa-inji1 env, authorization endpoints pointing to **released.mosip.net** and manual changes must be done in DB to fetch VC (as mock identity image in released env in **mosipid/mock-identity-system:0.9.3** but data provider supports 0.10.x version of mock-identity service) - Update PSUT value of individual id and data type limitations for the same column {% endhint %} ## Test execution statistics ### Functional test results Below are the test metrics by performing functional testing. The process followed was black box testing which based its test cases on the specifications of the software component under test. Functional test was performed in combination of individual module testing as well as integration testing. Test data were prepared in line with the user stories. Expected results were monitored by examining the user interface. The coverage includes GUI testing, System testing, End-To-End flows across multiple configurations. The testing cycle included simulation of multiple identity schema and respective UI schema configurations. | **Total** | **Passed** | **Failed** | **NA** | | --------- | ---------- | ---------- | ------ | | 565 | 527 | 34 | 4 | Test Rate: 100%, With Pass Rate: 93% and Fail Rate: 6% ### Automation Statistics * Sunbird Use Case | **Total** | **Passed** | **Failed** | **Ignored** | | --------- | ---------- | ---------- | ----------- | | 129 | 53 | 5 | 71 | Test Rate: 100%, With Pass Rate: 96% and Fail Rate: 3.8% 5 Failures are known issues can be tracked in INJICERT-681 * Mock Use Case | **Total** | **Passed** | **Failed** | **Ignored** | | --------- | ---------- | ---------- | ----------- | | 129 | 41 | 0 | 88 | Test Rate: 100%, With Pass Rate: 100% and Fail Rate: 0% Ignored scenarios are Not related to particular use case * Mosipid Use Case | **Total** | **Passed** | **Failed** | **Ignored** | | --------- | ---------- | ---------- | ----------- | | 129 | 26 | 0 | 103 | Test Rate: 100%, With Pass Rate: 100% and Fail Rate: 0% Ignored scenarios are Not related to particular use case ### Detailed Test metrics Below are the detailed test metrics by performing manual/automation testing. The project metrics are derived from Defect density, Test coverage, Test execution coverage, test tracking and efficiency. **The various metrics that assist in test tracking and efficiency are as follows:** * Passed Test Cases Coverage: It measures the percentage of passed test cases. (Number of passed tests / Total number of tests executed) x 100 * Failed Test Case Coverage: It measures the percentage of all the failed test cases. (Number of failed tests / Total number of test cases executed) x 100 ## Tested with Components | **Module/Repo** | **Image** | **POM version** | **Dependent artifactID** | **Comments** | | ---------------------- | --------------------------- | -------------------- | --------------------------------- | --------------------------------------------------------- | | Inji-certify-mosipid | mosipqa/inji-certify:0.10.x | | Digital-credential-plugin - 0.3.0 | | | Inji-certify-mock | mosipqa/inji-certify:0.10.x | | Digital-credential-plugin - 0.3.0 | | | Inji-certify-Insurance | mosipqa/inji-certify:0.10.x | | Digital-credential-plugin - 0.3.0 | | | Inji-config | mosipqa/config-server:1.1.2 | | | | | Keymanager | | 1.3.0-beta2 Snapshot | | To be released as a part of certify | | eSignet | eSignet-1.4.1 | | | | # Version 0.9.1 **Release Name:** Inji Certify 0.9.1 (Patch) **Support:** Developer Release **Release Date:** 3rd October, 2024 ### **Overview** This patch release 0.9.1 for Inji Certify focuses on upgrading critical components to ensure compatibility and enhanced performance across various plugins. The primary updates include upgrading the eSignet version to 1.4.1, the OIDC-UI pod version to 1.4.1, and now certify plugins are available as **0.2.1-SNAPSHOT**. Additionally, the release introduces changes to the Artifactory configuration, ensuring seamless integration of Certify plugins for continued reliability. #### **Changes and Upgrades:** 1. **eSignet Version Upgrade:** * The eSignet version has been upgraded to **1.4.1** for compatibility with different Certify plugins. 2. **OIDC-UI Pod Version Bump:** * The OIDC-UI pod version has been upgraded to **1.4.1**. 3. **Artifactory Changes:** * The Artifactory being pointed to by the config map now comes from the **Artifactory-ref-impl** branch. * This will ensure the correct dependency versions of the Artifactory. * The updated Certify plugins are now available as **0.2.1-SNAPSHOT** versions. ### **Testing and Integration Note:** For detailed steps click here to view the [**ReadMe**](https://github.com/mosip/inji-certify/tree/v0.9.1?tab=readme-ov-file) file. 1. **Setup:** Configure InjiWeb and Mimoto in your local environment. 2. **Issuer Configuration:** Add an issuer in Mimoto with the authorization\_endpoint, credential\_endpoint, and .well-known properties pointing to the installed eSignet and Certify services. 3. **Private Key Addition:** Insert the private key from the OIDC client created in eSignet into the .p12 file in Mimoto. 4. **Verification:** The configured issuer should now appear on the InjiWeb homepage, allowing you to download the credential. 5. **Plugin Compatibility:** For this release, ensure that the eSignet image version in Docker Compose (currently 1.4.1) is consistent with the Mock plugin dependencies in Artifactory. This alignment is crucial due to shared Redis cache dependencies resolving serialization issues. ### **Repositories: Released/Dependent** | Repositories | Tags: Released/Dependent | | ----------------------------- | --------------------------------------------------------------------------------- | | **Inji Certify** | [**v0.9.1**](https://github.com/mosip/inji-certify/tree/v0.9.1) | | **inji-config** | [**v0.2.0**](https://github.com/mosip/inji-config/tree/v0.2.0) | | **Digital Credential Plugin** | [**v0.2.1**](https://github.com/mosip/digital-credential-plugins/tree/v0.2.1) | | **Artifactory Server** | [**v0.9.1-INJI**](https://github.com/mosip/artifactory-ref-impl/tree/v0.9.1-INJI) | ### **Compatible modules:** The following table outlines the tested and certified compatibility of Inji Certify 0.9.0 with other modules. | Module | Version | | --------------- | ----------------------------------------------------------------------------------- | | **eSignet** | [**v1.4.1**](https://github.com/mosip/esignet/tree/v1.4.1) | | **Sunbird C** | [**v2.0.0**](https://github.com/Sunbird-RC/sunbird-rc-core/releases/tag/v2.0.0-rc3) | | **Key Manager** | [**v1.3.0-B1**](https://github.com/mosip/keymanager/tree/v1.3.0-beta.1) | | **Commons** | [**v1.3.0-B1**](https://github.com/mosip/commons/tree/v1.3.0-beta.1) | ### **Known Issues** Below is the list of known issues. To read in detail and view all the topics related to Inji Certify please click [here](https://mosip.atlassian.net/issues/?filter=11419\&jql=project%20%3D%20%22Inji%20Certify%22%20AND%20issuetype%20%3D%20Bug%20%20AND%20labels%20not%20in%20\(API_Automation%2C%20AWSdevicefarm%2C%20device_specific%2C%20qa-inji-UI-auto\)%20%20%20%20ORDER%20BY%20created%20DESC%2C%20updated%20DESC%2C%20cf%5B10039%5D%20)**.** | Jira ID | Description | | ------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------- | | [**INJICERT-468**](https://mosip.atlassian.net/browse/INJICERT-468) | Inji Certify: Mosipid VC download from injiweb is missing a few attributes, though VC JSON has the same | | [**INJICERT-467**](https://mosip.atlassian.net/browse/INJICERT-467) | Inji Certify : API /authorization/authenticate is throwing an error as HV000028: Unexpected exception during isValid call in the local setup | | [**INJICERT-236**](https://mosip.atlassian.net/browse/INJICERT-236) | Inji Certify : Getting response for well known endpoint when random value is specified in version query param | | [**INJICERT-298**](https://mosip.atlassian.net/browse/INJICERT-298) | Inji Certify : VC download is failing with signature alg (ES256) supported values mentioned in well-known response | | [**INJICERT-316**](https://mosip.atlassian.net/browse/INJICERT-316) | Inji Certify : Response of Mock VC is having extra attribute with null value | | [**INJICERT-324**](https://mosip.atlassian.net/browse/INJICERT-324) | Inji Certify : VC download is failing with credential type "LifeInsuranceCredential" | | [**INJICERT-327**](https://mosip.atlassian.net/browse/INJICERT-327) | Inji Certify :Extra credential type is coming in VC response for insurance usecase | | [**INJICERT-328**](https://mosip.atlassian.net/browse/INJICERT-328) | Inji Certify : Not able to download VC with few of the registries from InjiWeb, certify issuer | ### **Documentation** * [Feature Documentation](https://docs.mosip.io/inji/inji-certify/functional-overview/features) * [QA Report](/inji-certify/releases/version-0.9.1/test-report) * [Local Setup](https://docs.mosip.io/inji/inji-certify/build-and-deploy/local-setup) * [API Documentation](https://mosip.stoplight.io/docs/inji-certify/25f435617408e-inji-certify) # Test Report ## Testing Scope The scope of testing is to verify fitment to the specification from the perspective of * Functionality * Deployability * Configurability * Customizability Verification is performed not only from the end user perspective but also from the System Integrator (SI) point of view. Hence Configurability and Extensibility of the software are also assessed. This ensures the readiness of software for use in multiple countries. Since MOSIP is an “API First” product platform. The testing scope has been focused on the following features: * Inji certify Docker compose testing(VCI segregations) * Docker compose testing for Insurance and Mock ID use case * Inji certify - Insurance use case using namespace * Inji certify - Mock IDA use case using namespace * Inji certify - MOSIP ID use case using namespace(verified using idrepo UIN/VIDs only) * Integration with INJI Web ## Swaggers links ## Test Approach Persona based approach has been adopted to perform the IV\&V, by simulating test scenarios that resemble a real-time implementation. A Persona is a fictional character/user profile created to represent a user type that might use a product/or a service in a similar way. Persona based testing is a software testing technique that puts software testers in the customer's shoes, assesses their needs from the software, and thereby determines use cases/scenarios that the customers will execute. The persona's needs may be addressed through any of the following. * Functionality * Deployability * Configurability * Customizability The verification methods may differ based on how the need was addressed. ## Verified configuration Verification is performed on configurations as mentioned below * Default configuration * English ## Feature Health

Feature Health

{% hint style="info" %} **Note:** 1. UINs/VIDs generated with ID Repo were only used in verifying MOSIP ID, and Reg-Client UINs were not verified. 2. The Sunbird registry was pointing to Sunbird dev. {% endhint %} ## Test execution statistics ### Functional test results Below are the test metrics by performing functional testing. The process followed was black box testing which based its test cases on the specifications of the software component under test. The functional test was performed in combination with individual module testing as well as integration testing. Test data were prepared in line with the user stories. Expected results were monitored by examining the user interface. The coverage includes GUI testing, System testing, End-To-End flows across multiple configurations. The testing cycle included the simulation of multiple identity schema and respective UI schema configurations. | Total | Passed | Failed | NA | | ----- | ------ | ------ | -- | | 313 | 305 | 8 | 0 | **Test Rate:** 100%, With **Pass Rate:** 97% and **Fail Rate:** 3% ### Detailed Test metrics Below are the detailed test metrics by performing manual/automation testing. The project metrics are derived from Defect density, Test coverage, Test execution coverage, test tracking, and efficiency. The various metrics that assist in test tracking and efficiency are as follows: ● Passed Test Cases Coverage: It measures the percentage of passed test cases. (Number of passed tests / Total number of tests executed) x 100 ● Failed Test Case Coverage: It measures the percentage of all the failed test cases. (Number of failed tests / Total number of test cases executed) x 100 ## Tested with Components
Module/RepoImagePOM versionDependent artifactIDComments
Inji-certify-mosipidmosipqa/inji-certify:0.9.xDigital-credential-plugin - 0.2.1
Inji-certify-mockmosipqa/inji-certify:0.9.xDigital-credential-plugin - 0.2.1
Inji-certify-Insurancemosipqa/inji-certify:0.9.xDigital-credential-plugin - 0.2.1
Inji-configmosipqa/config-server:1.1.2https://github.com/mosip/inji-config/tree/release-0.2.x
Keymanager1.3.0-Snapshot
Commons1.3.0-Snapshot
Artifactory-certifymosipqa/artifactory-server:0.9.1-INJI
eSignet

eSignet-1.4.1

mosipid/esignet:1.4.1

The Github link for the xls file is [**here**.](https://github.com/mosip/test-management/tree/master/inji-certify/0.9.1) # Version 0.9.0 **Release Name:** Inji Certify 0.9.0 **Support:** Developer Release **Release Date:** 22nd August, 2024 ### **Overview** Inji Certify continues to innovate in the realm of verifiable credentials (VCs) with the release of **version 0.9.0.** This update introduces significant enhancements, improving the platform's flexibility, scalability, and ease of use. Designed to empower organizations to issue and manage VCs securely, Inji Certify 0.9.0 further strengthens its integration capabilities. With these new features, users can expect a more streamlined experience in credential issuance and management, ensuring compliance with industry standards while offering robust data control. Support for various plugins and microservices, allowing organizations to tailor the platform to their specific needs and existing systems. #### **New Features in Version 0.9.0:** 1. **Enhanced Verifiable Credential Issuance:** * **National Identity Plugin:** Integration with MOSIP for identity verification, enabling secure and reliable credential issuance. * **Insurance Plugin:** Seamless integration with Sunbird services to facilitate the issuance and management of VCs. * **Mock IDA Plugin:** Introduced for testing and development purposes, providing a controlled environment to simulate credential issuance. 2. **Segregation of eSignet VCI Component:** * The eSignet VCI component is now separated from eSignet services and migrated to the core Inji Certify system, optimizing functionality and scalability, and allowing for more modular deployments. 3. **Support for VC Formats:** * **JSON-LD Compliance:** Ensures adherence to W3C VC v1.1 standards promoting interoperability and industry compliance. * **Credential Schema Configuration:** Issuers can now configure custom credential schemas for various types of certificates, enhancing flexibility in credential design and issuance. 4. **Ease of Installation and Deployment:** * **Docker-compose Support:** Quick and easy deployment using Docker-compose, allowing for rapid local setup and scaling. Click [**here**](https://github.com/mosip/inji-certify/tree/v0.9.0/docker-compose) to learn more**!** 5. **Inji-config Repository:** * **Configuration Management:** Introduction of the inji-config repository to maintain all configurations related to the Inji Certify, streamlining configuration management and consistency across deployments. 6. **Support for Mock and Insurance Credential Use Cases:** * **Mock Credential Use Case:** Provides a predefined setup for mock credentials, useful for testing and development. * **Insurance Credential Use Case:** A specialized setup for issuing insurance-related credentials, offering a targeted solution for the insurance sector. ### **Testing and Integration Note:** For detailed steps click here to view the [**ReadMe**](https://github.com/mosip/inji-certify/blob/v0.9.0/README.md) file. 1. **Setup:** Configure InjiWeb and Mimoto in your local environment. 2. **Issuer Configuration:** Add an issuer in Mimoto with the authorization\_endpoint, credential\_endpoint and .well-known properties pointing to the installed eSignet and Certify services. 3. **Private Key Addition:** Insert the private key from the OIDC client created in eSignet into the .p12 file in Mimoto. 4. **Verification:** The configured issuer should now appear on the InjiWeb homepage, allowing you to download the credential. 5. **Plugin Compatibility:** For this release, ensure that the eSignet image version in Docker Compose (currently 1.4.0) is consistent with the Mock plugin dependencies in Artifactory. This alignment is crucial due to shared Redis cache dependencies resolving serialization issues. ### **Repositories: Released/Dependent** | **Repositories** | **Tags: Released/Dependent** | | ----------------------------- | --------------------------------------------------------------------------------- | | **Inji Certify** | [**v0.9.0**](https://github.com/mosip/inji-certify/tree/v0.9.0) | | **inji-config** | [**v0.2.0**](https://github.com/mosip/inji-config/tree/v0.2.0) | | **Digital Credential Plugin** | [**v0.2.0**](https://github.com/mosip/digital-credential-plugins/tree/v0.2.0) | | **Artifactory Server** | [**v0.9.0-INJI**](https://github.com/mosip/artifactory-ref-impl/tree/v0.9.0-INJI) | ### **Compatible Modules:** The following table outlines the tested and certified compatibility of Inji Certify 0.9.0 with other modules. | **Module** | **Version** | | --------------- | --------------------------------------------------------------------------- | | **eSignet** | [**v1.4.0**](https://github.com/mosip/esignet/tree/v1.4.0) | | **Sunbird C** | [**v2.0.0**](https://github.com/Sunbird-RC/sunbird-rc-core/tree/v2.0.0) | | **Key Manager** | [**v1.3.0-beta.1**](https://github.com/mosip/keymanager/tree/v1.3.0-beta.1) | | **Commons** | [**v1.3.0-beta.1**](https://github.com/mosip/commons/tree/v1.3.0-beta.1) | ### **Known Issues** Below is the list of known issues. To read in detail and view all the topics related to Inji Verify please click [**here**](https://mosip.atlassian.net/issues/?filter=11419\&jql=project%20%3D%20%22Inji%20Certify%22%20AND%20issuetype%20%3D%20Bug%20%20AND%20labels%20not%20in%20\(API_Automation%2C%20AWSdevicefarm%2C%20device_specific%2C%20qa-inji-UI-auto\)%20%20%20%20ORDER%20BY%20created%20DESC%2C%20updated%20DESC%2C%20cf%5B10039%5D%20)**.** | **Jira ID** | **Description** | | ------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------- | | [**INJICERT-236**](https://mosip.atlassian.net/browse/INJICERT-236) | Getting response for well known endpoint when random value is specified in version query param | | [**INJICERT-298**](https://mosip.atlassian.net/browse/INJICERT-298) | Inji Certify: VC download is failing with signature alg (ES256) supported values mentioned in well-known response | | [**INJICERT-316**](https://mosip.atlassian.net/browse/INJICERT-316) | Inji Certify: Response of Mock VC is having extra attribute with null value | | [**INJICERT-324**](https://mosip.atlassian.net/browse/INJICERT-324) | Inji Certify: VC download is failing with credential type "LifeInsuranceCredential" | | [**INJICERT-327**](https://mosip.atlassian.net/browse/INJICERT-327) | Inji Certify: Extra credential type is coming in VC response for insurance usecase | | [**INJICERT-328**](https://mosip.atlassian.net/browse/INJICERT-328) | Inji Certify : Not able to download VC with few of the registries from InjiWeb, certify issuer | ### **Bug Fixes** Below is the list of fixes as part of the **0.9.0** release: | **Jira ID** | **Description** | | ------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------- | | [**INJICERT-314**](https://mosip.atlassian.net/browse/INJICERT-314) | Inji Certify: /authorization/v2/oauth-details API is failing with error ""invalid\_client\_id" | | [**INJICERT-312**](https://mosip.atlassian.net/browse/INJICERT-312) | Inji Certify: VC verification is failing for insurance VC | | [**INJICERT-274**](https://mosip.atlassian.net/browse/INJICERT-274) | Inji Certify: Fetching of credential list from issuer " National Identity Department (Certify)" is failing | | [**INJICERT-277**](https://mosip.atlassian.net/browse/INJICERT-277) | Inji Certify: VC download is failing from certify with error "Unable to connect to Redis" | ### **Conclusion:** Inji Certify 0.9.0 represents a significant milestone in the evolution of the module offering users enhanced capabilities for issuing, managing, and integrating verifiable credentials. With a focus on scalability, interoperability, and ease of use, this release empowers organizations to leverage the full potential of VCs securely and efficiently. ### **Documentation** * [Feature Documentation](/inji-certify/overview/features) * [QA Report](/inji-certify/releases/version-0.9.0/test-report) * [Local Setup](/inji-certify/build-and-deploy/local-setup) # Test Report ## Testing Scope The scope of testing is to verify fitment to the specification from the perspective of * Functionality * Deployability * Configurability * Customizability Verification is performed not only from the end user perspective but also from the System Integrator (SI) point of view. Hence Configurability and Extensibility of the software are also assessed. This ensures the readiness of software for use in multiple countries. Since MOSIP is an “API First” product platform. Testing scope has been focused on the below features: * Inji certify Docker compose testing(VCI segregations) * Docker compose testing for Insurance and Mock ID use case * Inji certify - Insurance use case using namespace * Inji certify - Mock IDA use case using namespace * Inji certify - MOSIP ID use case using namespace(verified using idrepo UIN/VIDs only) * Integration with INJI Web ## Swaggers links ## Test Approach Persona based approach has been adopted to perform the IV\&V, by simulating test scenarios that resemble a real-time implementation. A Persona is a fictional character/user profile created to represent a user type that might use a product/or a service in a similar way. Persona based testing is a software testing technique that puts software testers in the customer's shoes, assesses their needs from the software, and thereby determines use cases/scenarios that the customers will execute. The persona's needs may be addressed through any of the following. * Functionality * Deployability * Configurability * Customizability The verification methods may differ based on how the need was addressed. ## Verified configuration Verification is performed on configurations as mentioned below * Default configuration * English ## Feature Health
{% hint style="info" %} **Note**: * UIN’s/VID’s generated with ID Repo were only used in verifying MOSIP ID, Reg-Client UIN were not verified. * The Sunbird registry was pointing to Sunbird dev. {% endhint %} ## Test execution statistics ### Functional test results Below are the test metrics by performing functional testing. The process followed was black box testing which based its test cases on the specifications of the software component under test. The functional test was performed in combination with individual module testing as well as integration testing. Test data were prepared in line with the user stories. Expected results were monitored by examining the user interface. The coverage includes GUI testing, System testing, End-To-End flows across multiple configurations. The testing cycle included the simulation of multiple identity schema and respective UI schema configurations. | **Total** | **Passed** | **Failed** | **NA** | | ------------------------------------------------------- | ---------- | ---------- | ------ | | 311 | 303 | 6 | 0 | | Test Rate: 100%, With Pass Rate: 98% and Fail Rate : 2% | | | | ### Detailed Test metrics Below are the detailed test metrics by performing manual/automation testing. The project metrics are derived from Defect density, Test coverage, Test execution coverage, test tracking, and efficiency. The various metrics that assist in test tracking and efficiency are as follows: * Passed Test Cases Coverage: It measures the percentage of passed test cases. (Number of passed tests / Total number of tests executed) x 100 * Failed Test Case Coverage: It measures the percentage of all the failed test cases. (Number of failed tests / Total number of test cases executed) x 100 ### Stories Tested
DetailsStories TestedTest Cases
TotalTotalWith Storiesw/o StoriesPassFailNot tested
Inji-Certify4311311030560
Total4311311030560
Functional Testing - Stories Verified : 4
Test cases : 311 Passed : 305 Failed : 6 Skipped : 0
Test Rate : 100% With Pass Rate : 98%
### API + Docker compose testing
API +Docker compose testing
StoryTest Results
INJICERT-41858320
INJICERT-13727110
INJICERT_186727020
INJICERT-189828110
## Tested with Components | **Module/Repo** | **Image** | **POM version** | **Dependent artifactID** | **Comments** | | ---------------------- | ------------------------------------- | --------------- | --------------------------------- | --------------------------------------------------------------------------- | | Inji-certify-mosipid | mosipqa/inji-certify:0.9.x | | Digital-credential-plugin - 0.2.0 | | | Inji-certify-mock | mosipqa/inji-certify:0.9.x | | Digital-credential-plugin - 0.2.0 | | | Inji-certify-Insurance | mosipqa/inji-certify:0.9.x | | Digital-credential-plugin - 0.2.0 | | | Inji-config | mosipqa/config-server:1.1.2 | | | [**v0.2.0**](https://github.com/mosip/inji-config/tree/v0.2.0) | | Keymanager | | 1.3.0-Snapshot | | [**v1.3.0-beta.1**](https://github.com/mosip/keymanager/tree/v1.3.0-beta.1) | | Commons | | 1.3.0-Snapshot | | [**v1.3.0-beta.1**](https://github.com/mosip/commons/tree/v1.3.0-beta.1) | | Artifactory-certify | mosipqa/artifactory-server:0.9.0-INJI | | | | | eSignet | eSignet-1.4.0 | | | | ## Browser Versions Used For Testing | Browser Versions Used For Testing | | --------------------------------- | | chrome: Version 127.0.6533.89 | | Mac : version 16.6 | The Github link for the xls file is **here**. # Version 0.8.1 **Release Name**: Inji Certify 0.8.1 (Patch) **Support**: Developer Release **Release Date**: 17th May, 2024 ## Overview Version 0.8.1 introduces significant enhancements to streamline the management and issuance of verifiable credentials using the Sunbird platform. Key updates include: 1. **Sunbird Installation and Configuration:** * Postman collections are provided for creating issuers and credential schemas. 2. **DID Generation:** * To generate Decentralized Identifiers (DIDs) using the web method and an empty services list. The configuration within the Sunbird installation ensures that the generated DIDs are resolvable. When creating an issuer (which involves a DID generation call), this configuration will be used to generate the DIDs. * Added steps to make the generated DID discoverable for local testing 3. **Credential Schema and Issuance Registry:** * Users can create credential schemas and issuance registries. * Important identifiers (`$.schema[0].author` and `$.schema[0].id`) were noted for schema requests. 4. **Endpoint and Environment Variable Configuration:** * Hostname configuration for endpoints based on Docker setup. * `aud` variable and `audUrl` in the postman collection updated to the local OAuth token endpoint. 5. **Knowledge-Based Identification (KBI):** * KBI process implemented as per Postman collection. * Base64 encoded KBI details for authorization. 6. **Credential Generation:** * We adjusted the pre-request script for `/vci/credential` API. * Keypair and algorithm updated for generating smaller Verifiable Credentials. **Repository Released** | **Repositories** | **Tags Released** | | ---------------- | ----------------------------------------------------------------------------------- | | Inji Certify | [**v0.8.1**](https://github.com/mosip/inji-certify/tree/v0.8.1) | | eSignet | [**v1.4.0**](https://github.com/mosip/esignet/releases/tag/v1.4.0) | | Sunbird C | [**v2.0.0**](https://github.com/Sunbird-RC/sunbird-rc-core/releases/tag/v2.0.0-rc3) | #### **Known Issues** No Known Issues #### **Documentation** * [Feature Documentation](https://docs.mosip.io/inji/inji-certify/functional-overview/features) * [Local Setup](https://docs.mosip.io/inji/inji-certify/build-and-deploy/local-setup) # Version 0.8.0 **Release Name**: Inji Certify 0.8.0 **Support**: Developer Release **Release Date**: 30th April, 2024 ### **Overview** We are thrilled to announce the inaugural release of Inji Certify, featuring a seamless installation guide for deploying Inji Certify. This release highlights the key integration with microservices such as eSignet VCI and Sunbird RC, in Version 0.8.0. **Summary** Below are the details for the **Inji Certify 0.8.0** release: Inji Certify introduces seamless integration with microservices eSignet VCI and Sunbird C. These robust services are dedicated to credentialing, facilitating seamless authentication, issuance, and verification of verifiable credentials within the platform. Click on the following links to learn more: * [**Credential Issuance**](https://docs.mosip.io/inji/inji-certify/functional-overview/features) * [**Effortless Installation**](https://docs.mosip.io/inji/inji-certify/functional-overview/features) **Repository Released** | **Repositories** | **Tags Released** | | ---------------- | ----------------------------------------------------------------------------------- | | Inji Certify | [**v0.8.0**](https://github.com/mosip/inji-certify/tree/v0.8.0) | | eSignet | [**v1.4.0**](https://github.com/mosip/esignet/releases/tag/v1.4.0) | | Sunbird C | [**v2.0.0**](https://github.com/Sunbird-RC/sunbird-rc-core/releases/tag/v2.0.0-rc3) | ### **Known Issues** No Known Issues ### **Documentation** * [Feature Documentation](https://docs.mosip.io/inji/inji-certify/functional-overview/features) * [Local Setup](https://docs.mosip.io/inji/inji-certify/build-and-deploy/local-setup) # FAQ # FAQ
Why and what was the segregation of eSignet VCI Component to Inji Certify? **Segregation of eSignet VCI Component to Inji Certify** Inji Certify, a platform for issuing and managing verifiable credentials (VCs), has enhanced its system by segregating the eSignet VCI component. This strategic move optimizes functionality and scalability. Important Update: Now eSignet VCI is known as Inji Certify Core! **What was eSignet VCI?** **eSignet VCI** was a microservice for secure authentication, issuance, and verification of VCs, based on OAuth 2.0 and OpenID Connect protocols. It ensures reliable user authentication and promotes interoperability across systems. **Reasons for Segregation** **1. Enhanced Specialization and Focus** * Separating eSignet VCI allows Inji Certify to focus on credential issuance while eSignet VCI concentrates on secure authentication and verification, improving efficiency. **2. Improved Scalability** * Each component can now scale independently based on demand, ensuring the platform handles varying loads effectively. **4. Streamlined Maintenance and Updates** * Independent updates and maintenance reduce downtime and allow for quicker deployment of enhancements and security patches. **5. Facilitating Multi-Tenancy** * The segregation will support multiple issuers on a single Inji Certify instance, ensuring data integrity and security for each issuer in the upcoming implementation of Inji Certify. **How the Segregation Works** * **Modular Structure**: Now eSignet VCI is maintained as a separate module within the Inji Certify which offers an Inji Certify core under the Certify repository, ensuring a clear separation of concerns while maintaining a unified codebase. * **Enhanced Configuration**: Organizations can now configure Inji Certify core which offers the VC issuances independently to meet specific requirements, allowing for customized solutions. The segregation of eSignet VCI enhances Inji Certify’s performance and scalability, providing a robust solution for issuing and managing verifiable credentials. This strategic move ensures a more secure and efficient credentialing ecosystem for organizations and users.
# Inji Mobile Inji Mobile is the **mobile wallet app** in the Inji stack. Use it to **download**, **store**, and **share** verifiable credentials (VCs). #### What you’ll find here * [Overview](/inji-wallet/inji-mobile/overview): What the app is, and what it supports. * [Test](/inji-wallet/inji-mobile/functional-overview): Try the app flows, sandbox content, and user guides. * [Setup](/inji-wallet/inji-mobile/build-and-deployment): Local setup prerequisites and environment needs. * [Develop](/inji-wallet/inji-mobile/technical-overview): Architecture, components, integrations, and customization docs. * [API](/inji-wallet/inji-mobile/api): API references used by the wallet and supporting services. * [Deploy](broken://spaces/aY8BQ4hdzhSchZV814Ev/pages/ubiu1h1efd0ZagqHEJLE): Deployment instructions and pointers. * [Releases](/inji-wallet/inji-mobile/versions): Version history and test reports. # Overview > Inji Mobile isn't just a wallet – it’s a gateway to digital trust, empowering every individual to carry their identity with dignity, privacy, and control.\ > — Inspired by the vision of open, inclusive digital identity ecosystems. **Inji Mobile** is an open-source mobile wallet built to securely **receive, store, manage, and share Verifiable Credentials (VCs)**, whether online or offline. Designed in line with global standards such as **W3C VC Data Model**, **OpenID4VCI**, **OpenID4VP**, **ISO 18013-5 (mDL)**, and **IETF SD-JWT**, Inji Mobile enables individuals to carry digital identity, documents, certificates, etc., with full privacy, consent, and control. Whether you're a citizen accessing government services, a developer building digital identity applications, or a verifier validating credentials, Inji Mobile offers a trusted, standards-compliant foundation for secure and privacy-preserving interactions. As a **reference implementation**, Inji Mobile is both a ready-to-use wallet and a modular solution; its SDKs, libraries, and components can be used independently or bundled into custom apps, depending on the adopter’s needs and specific use cases. ### Core Design Principles * **Interoperability-First**\ Complies with major standards: OpenID4VCI, OpenID4VP, W3C Data Model, IETF SD-JWT, JWT VC, and ISO mDL/mDoc. * **Offline Functionality**\ BLE-based VC sharing and **offline face authentication**, ensuring usability even in no-connectivity environments. * **User Sovereignty**\ Credentials are held entirely by the user, with **granular consent-driven sharing**. * **Modular Security Architecture**\ Combines robust cryptography with flexible authentication mechanisms and strong privacy guarantees. * **Cross-Platform Native Implementation**\ Built in **React Native** with Kotlin (Android) and Swift (iOS) integrations for native performance. ### Capabilities Snapshot #### Multiple Credential Format Support Inji Wallet is designed for interoperability and flexibility by supporting a wide range of credential formats: * **W3C Verifiable Credentials (JSON-LD VCs) Data Model 1.1 and Data Model 2.0** * Standards-based credential format is widely adopted across ecosystems. * Suitable for general-purpose credential issuance and verification. * **ISO 18013-5 (mDL)** * Mobile Driving License and Mobile Document specification. * Supports use cases like identity verification in transport, law enforcement, and service access. * **IETF SD-JWT** * **IETF** **SD-JWT Verifiable Credentials**: Enables holders to download and share credentials in IETF **SD-JWT format**. This allows users to share only the necessary attributes while keeping other data private, ensuring **privacy-preserving credential sharing**. * Allows users to share only the required claims with verifiers via the OpenIDVP flow, where these selectively disclosable claims can be shared as per the user's need. This multi-format support allows Inji Wallet to work seamlessly across different ecosystems, ensuring **compatibility, security, and user privacy**. #### Secure Storage of VCs * Digitally signed credentials from trusted issuers * Encrypted and integrity-verified local storage. * Supports multiple credential formats including W3C JSON-LD VCs, ISO mDL/mDoc, and **IETF SD-JWT.** #### Seamless Credential Sharing * **Offline sharing** via [Bluetooth Low Energy (BLE)](https://tlodderstedt.github.io/openid-for-verifiable-presentations-offline-1_0-00.html) * **Online presentation** using QR-code SSO and [OpenID4VP](https://openid.net/specs/openid-4-verifiable-presentations-1_0.html) * Supports **same-device and cross-device** interactions #### Authentication & Face Verification * Offline **face match verification** to authenticate the user during VC sharing * Device-level biometric/passcode unlock for app access #### Deep Link-Based SSO (Wallet Login Authentication - WLA) * Tap-to-login via QR code scanning * Smart redirection to service post-verification * Works across any OpenID4VP-compliant verifier #### Credential Download via Pre-Auth Code * Download credentials via **pre-authorized flow** * Supports various credential types: national IDs, driver's licenses, health cards, academic degrees, etc. #### **SD-JWT OpenIDVP Support** * Inji Mobile supports **Selective Disclosure JWT (SD-JWT)** credentials. * Enables **privacy-preserving presentations**, where users can share only the specific attributes required by a verifier, rather than the entire credential. * Fully compliant with the **OpenID for Verifiable Presentations Draft 23 (OpenID4VP)** specification for SD-JWT. * Improves compatibility with ecosystems adopting **SD-JWT and OpenID-based verifiable presentation**. #### **SVG-Based Credential Rendering** * Introduces support for **SVG templates** via the **Inji VC Renderer** library. * Allows credentials to be rendered in a **visually rich, scalable, and customizable format**. * Enables **dynamic layouts**, inclusion of **logos, photos, and design elements**, while staying aligned with the **W3C VC Data Model 2.0**. * Improves on-screen display and print-ready credential rendering experience. #### Revocation Support * **Automatically checks if a card is still valid** by reading the issuer’s revocation list whenever a credential is downloaded or refreshed. * **Uses W3C Bitstring Status List**, ensuring global, standards-based detection of revoked. * **Shows clear status indicators** (Valid, Revoked, Pending) so users immediately know whether a card can be safely shared. * Supports manual status checks #### Presentation During Issuance (PDI) Inji Mobile supports **Presentation During Issuance (PDI)** a secure flow where users can **prove eligibility using an existing credential before receiving a new one**. Instead of repeating identity checks or submitting documents again, the wallet can present a **Verifiable Presentation (VP)** of an already stored credential to the issuer during the issuance process. **Example:** Present your **National ID credential** → Receive a **Driving License or Health Card** * Receive new credentials faster without repeating onboarding steps * Reuse trusted credentials already stored in the wallet * Approve exactly what information is shared before issuance ## Claim-169 QR Code Support Inji Mobile supports **Claim-169 QR Codes**, a standardized QR format used to support receiving and using Verifiable Credentials (VCs) that contain **Claim 169–formatted QR code blocks**, issued as **CBOR-based CWT (CBOR Web Tokens)** inside the credential.\ This ensures secure, compact, and privacy-preserving QR sharing ideally suited for offline or quick verification scenarios. The goal of this feature is to allow the wallet to: * Download credentials containing embedded Claim 169 QR blocks * Store and render these QR blocks for display * Allow users to present the QR-based identity data when required * Ensure proper validation and security checks (size, format, signature, structure) ### How It Works 1. **Credential Download**\ Users can obtain VCs using their unique identifiers (UIN/VID or other methods), authenticate via OTP, and securely store them. 2. **Credential Storage**\ All credentials are stored encrypted, verified using the issuer’s digital signature, and integrity is validated via a unique **HASH**. In addition to standard VC formats, Inji Mobile supports JSON-LD, ISO mDL/mDoc and IETF SD-JWT credentials, ensuring the privacy-preserving selective disclosure of claims during verification. 3. **Sharing Credentials**\ Users can share credentials: * Offline using BLE * Online by scanning QR codes via OpenID4VP * Simple Upload and Scan of QR codes 4. **Face Verification**\ Optional offline face authentication ensures the right holder is presenting credentials during in-person verifications. 5. **Consent & Privacy**\ Credential sharing is **consent-based**, giving users full control over what data is shared and with whom. ### Sneak Peek: Upcoming Features * Support for **JWT-format credentials** * **Wallet Login with IdPs** * Multiple Profile Creation * Credential Refresh Support ### Technology and Integration 1. The app leverages [**Mimoto APIs**](https://mosip.stoplight.io/docs/mimoto/k6907m3dzc1gi-mimoto) * Wallet configuration and trusted issuer setup * VC download * Holder binding of credentials (public key association) 2. Refer to [**Inji Certify APIs**](https://mosip.stoplight.io/docs/inji-certify/25f435617408e-inji-certify) * Fetch issuer's well-known metadata * Download VCs (OpenID4VCI flow) 3. Additionally, it utilises [**eSignet APIs**](https://mosip.stoplight.io/docs/identity-provider/zevye0dm733qx-link-transaction-endpoint-v2) to enable seamless online login for users. ### Summary **Inji Mobile** is more than just a credential wallet; it’s a **reference implementation** for inclusive, offline-capable, standards-compliant digital identity. With full support for online and offline VC flows, strong cryptographic safeguards, and a user-first design, it provides a powerful tool for citizens, developers, and governments alike. Inji Mobile gives you the **interoperable building blocks** you need. ### Get Involved For any queries, contributions, or to collaborate, join us on the [**Inji community forum**](https://community.mosip.io/c/inji/16) or raise a PR via the [**GitHub repository**](https://github.com/mosip/inji-wallet). # Features Inji Mobile is an open-source digital wallet designed to enable individuals to receive, store, and present Verifiable Credentials (VCs) securely, both online and offline. Purpose-built to align with global standards like W3C VC, OpenID4VCI, OpenID4VP, IETF SD-JWT, and ISO 18013-5 (mDL), it brings interoperability, user autonomy, and strong cryptographic guarantees to digital identity ecosystems. ### Core Mobile Wallet Features ### 1. Multiple Credential Format Support Inji Wallet is designed for interoperability and flexibility by supporting a wide range of credential formats: * **W3C Verifiable Credentials (JSON-LD VCs) Data Model 1.1** * Standards-based credential format is widely adopted across ecosystems. * Suitable for general-purpose credential issuance and verification. * **ISO 18013-5 (mDL)** * Mobile Driving License and Mobile Document specification. * Supports use cases like identity verification in transport, law enforcement, and service access. * **IETF SD-JWT** * **IETF** **SD-JWT Verifiable Credentials**: Enables holders to download and share credentials in IETF **SD-JWT format**. This allows users to share only the necessary attributes while keeping other data private, ensuring **privacy-preserving credential sharing**. * Allows users to share only the required claims with verifiers via the OpenIDVP flow, where these selectively disclosable claims can be shared as per the user's need. This multi-format support allows Inji Wallet to work seamlessly across different ecosystems, ensuring **compatibility, security, and user privacy**. ### 2. Download, Verify, and Share Verifiable Credentials Inji Wallet makes it easy and secure for residents to manage their digital identity and credentials. From downloading and verifying to sharing and backing up Verifiable Credentials (VCs), this guide outlines all key features and workflows available in the wallet. #### 2.1 Downloading Verifiable Credentials #### a) OpenID for VC Issuance Residents can download VCs from trusted issuers integrated with OpenID for the VCI protocol. **Example Issuers:** * Republic of Veridonia National ID Department - National ID * StayProtected Insurance - Insurance Credentials * Republic of Veridonia Tax Department - Tax ID * AgroVeritas Property & Land Registry - Land Record * Veridonia Department of Motor Vehicles - mDoc #### b) Pre-Authorised Credential Offers (Without Transaction Code) * Users download credentials directly using a credential\_offer URI * No login required; pre-auth code embedded in the offer * Used in mass issuance or public campaigns (e.g., vaccination certificates, offline cards) #### c) Pre-Authorised Credential Offers (With Transaction Code) * Adds a one-time transaction code (OTP / claim code) to bind issuance to the user * User enters code in-app to retrieve VC securely * Ideal for privacy-sensitive issuance (e.g., mDL, insurance) #### d) Presentation During Issuance * Enables users to **present an existing credential before receiving a new one**, reducing repeated verification steps. * Allows issuers to verify eligibility securely using **Verifiable Presentations (VPs)**. * Improves user experience with **consent-based sharing directly from the wallet**. * Built on **OpenID4VCI and OpenID4VP standards** for interoperable issuance flows. * Helps prevent fraud and ensures credentials are issued only to **eligible users**. #### e) Claim 169 QR Code Support * Supports **standardized QR codes** for initiating credential download and sharing flows. * Download credentials containing embedded Claim 169 QR blocks * Store and render these QR blocks for display * Allow users to present the QR-based identity data when required * Ensure proper validation and security checks (size, format, signature, structure) #### 2.2 Verifying Credential Authenticity Inji Mobile Wallet uses robust cryptographic libraries to verify that the VC is: * **Digitally signed by a trusted issuer,** ensuring the credential originates from a valid and recognized entity. * **Cryptographically valid based on proof type** verifying the integrity of the data using the appropriate proof mechanisms (e.g., JSON-LD proof, JWT, IETF SD-JWT, etc.). * **Not revoked or expired** performing revocation status checks using status lists, revocation registries, or endpoints defined in the VC metadata. * **Untampered** confirming that no field or claim in the credential has been altered since issuance. * **Bound to the correct holder (where applicable)** verifying holder binding in cases where the VC includes a subject proof (e.g., via DID or SD-JWT binding). ### 3. Sharing Verifiable Credentials Inji Wallet supports secure sharing of Verifiable Credentials (VCs) in multiple ways — both **online and offline** — with strong privacy and authentication.
MethodDescriptionConnectivityUser Control / Notes
QR Code SharingGenerate QR using PixelPass. Scan or upload on verifier portal.OnlineQuick and compact
BLE (Bluetooth) SharingShare VCs offline using Bluetooth Low Energy.OfflinePeer-to-peer; face match supported
SSO via QR CodeScan QR on service portal → share selected VCs after user consent.OnlineFine-grained VC selection and SSO login
OpenID4VP – Cross-DeviceScan verifier’s QR from another device → present VCs post face verification.

Example: Sharing of JSON-LD,mDoc VCs etc		OnlineSecure, decentralized VC presentation
OpenID4VP – Same DeviceTap QR on browser → deep-link opens wallet → share credentials.

Example: Sharing of JSON-LD,mDoc VCs etc		OnlineSeamless redirect
SD-JWT Verifiable Presentation (VP) Support
  • Inji Wallet supports OpenID for Verifiable Presentations (OpenID4VP) flow for credentials in the IETF SD-JWT format.
  • Holders can selectively disclose specific claims while keeping other attributes private.
  • This ensures privacy-preserving credential sharing with verifiers, aligning with IETF SD-JWT and OpenID4VP standards.
  • The wallet validates signed authorization requests and presents only the chosen claims, ensuring security and consent-driven sharing.
OnlineConsent-based sharing
**Note:** All methods include **user consent** and **privacy-by-design** to ensure secure, context-aware interactions. ### **4. SVG-based Credential Rendering** * Inji Wallet now supports **SVG-based credential rendering** for **Data Model 2.0 VCs**. * This allows credentials issued under the Data Model 2.0 schema to be displayed as **secure, dynamic SVG visuals** within the wallet. * The rendering ensures that displayed information (such as name, ID, issuer, and other attributes) directly corresponds to the **cryptographically verified credential data**. * This enhancement improves **readability**, **user trust**, and **consistency** while maintaining alignment with the underlying verifiable data. * Support for SVG rendering for other data models may be added in future versions. ### 5. Revocation Support * **Automatic Status Check** – The wallet automatically checks if a card is valid, revoked, or pending when it is downloaded. * **Manual Recheck Anytime** – Users can recheck a card’s status whenever needed, with clear results shown instantly. * **Easy-to-Understand Status Labels** – Cards clearly show one of three states: **Valid**, **Revoked**, **Expired** and **Pending**. * **History Tracking** – Whenever there is a change in status, it reflects in the user’s History for easy tracking and transparency. ### 6. Additional Mobile Wallet Features #### 6.1 Backup and Restore Inji Wallet includes a secure, one-time backup setup based on the platform: | Platform | Backup Option | Notes | | -------- | ------------- | ---------------------------- | | Android | Google Drive | Select Google account | | iOS | iCloud | Uses logged-in Apple account | **Ideal for:** * Phone upgrades * App crashes or resets #### 6.2 User-Friendly Interface & Quick Actions Designed for ease of use with intuitive UI components: * Multiple VC Views: Mini cards to full detail * Separation of Downloaded vs. Received VCs * Quick Access Menu: Share, Share with Selfie via the kebab menu (⋮) on card * Select from a list of credential types offered by the issuer. * Choose only the VCs they want to download, ensuring relevance and control. * VCs grouped by type (ID, insurance, education) * Recent VCs shown first #### 6.3 Wallet Security & Device Features * **Biometric / Passcode Access** * App requires authentication on every open or session timeout * Supports Android biometrics and Apple Face ID / Touch ID * **Private Key Storage in Secure Enclave** * Private keys are stored using Android Keystore / iOS Secure Enclave * Keys cannot be exported or tampered ### Read More Check the [Inji Mobile Wallet Repository](https://github.com/mosip/inji-wallet/tree/master/docs/) to explore the above-mentioned features. # Revocation of Verifiable Credentials ### Overview Revocation in Inji Mobile Wallet is the mechanism that allows the wallet to determine and display whether a stored verifiable credential (VC) is **revoked or not**. Inji uses the [**W3C Bitstring Status List**](https://www.w3.org/TR/vc-bitstring-status-list/) mechanism to evaluate revocation for supported credential formats. The revocation check runs automatically when credentials are downloaded, and can be triggered manually by the user. To get more details on the technical implementation and design of this feature, click [here](https://github.com/mosip/inji-wallet/blob/master/docs/revocation-support.md) to explore. ### Why This Feature Matters * **Protects Verifiers & Holders:** Prevents use of credentials that an issuer has invalidated (e.g., lost, compromised, or superseded). * **Maintains Trust:** Ensures relying parties receive only valid credentials and avoids false acceptances. * **User Safety & Compliance:** Alerts users that a credential is no longer usable and prevents them from unknowingly sharing revoked data. * **Offline-first UX:** The wallet supports offline scenarios (BLE) and indicates pending status when online checks are unavailable. * **Status recheck:** Status checks are performed when the credential is first downloaded and can be triggered manually by the user. ### Supported Credential Types * **Fully supported (revocation checks):** * `ldp_vc` (Linked Data Proof VC) with an `credentialStatus` entry that follows [**W3C Bitstring Status List**](https://www.w3.org/TR/vc-bitstring-status-list/) semantics. * Status entries where `statusPurpose == "revocation"`. * Multi-bit status lists (`statusSize > 1`) are supported (0 = valid, >0 = revoked). * **Not yet checked (bypass for now):** * `sd-jwt` (SD-JWT) — revocation check currently bypassed (future work planned). * `mDoc`/`mDL` — depending on issuer support; currently may be bypassed if the credential lacks a StatusList entry. * Any credential without an `credentialStatus` entry or with unsupported `statusPurpose`. ### How does the Revocation Flow Work? #### **User Flow (Step-by-Step)** * When a verifiable credential is downloaded into the wallet, the app automatically checks whether it is still valid. * The wallet looks up the status for every credential downloaded, where the wallet checks if the issuing authority has marked it as still active or revoked (no longer valid). * The wallet verifies the information before trusting the response. The wallet makes sure the data is correct: * a) It checks that the file is valid. * b) It checks that the information is up-to-date. * c) It checks (on Android) that the file is digitally signed and secure. * The wallet updates the screen, and the app now shows the correct status: * a) 🟢 **Valid** — You can use or share it * b) 🔴 **Revoked** — You cannot use it * c) 🟡 **Pending** — Try again later; internet may be required * Wallet logs the activity. The action (“Status checked”) is saved in your **History** so you always know when the last check happened.
### Current Limitations 1. **Format coverage:** * Revocation checks currently apply only to credentials using the [**W3C Bitstring Status List**](https://www.w3.org/TR/vc-bitstring-status-list/) (LDP-VC). SD-JWT and some other credential formats are **bypassed** for status checks until issuers provide compatible status-list metadata or wallet libraries add support. 2. **iOS signature verification:** * Full cryptographic signature verification of the Status List Credential is **skipped on iOS** for the current release (processing still decodes bitstring). iOS signature verification is planned for a future update. 3. **Network dependence & offline UX:** * When offline or when the status list URL is unreachable, the wallet marks the status as **PENDING**. Verifiers must treat PENDING per their policy (some verifiers may allow conditional acceptance; others must reject). 4. **Revocation push & near-real-time updates:** * Current flow is pull-based; there is no push notification mechanism for immediate issuer-driven revocation propagation to wallets. This may cause brief windows of stale state between issuer revocation and wallet recheck. 5. **Multi-purpose status entries:** * Wallet currently supports only `statusPurpose = "revocation"`. Other purposes (e.g., `suspension`) are not handled. 6. **Error reporting granularity:** * Some failure states map to a generic `PENDING`; more granular error messaging could help users and integrators diagnose issues (e.g., signature failure, decode error, invalid index). 7. **Scale of encodedList:** * Very large encodedList files for population-scale deployments may require optimized storage, streaming, and verification strategies (e.g., segmented lists, CDN usage). ### Learn More * [Revocation Check - Inji Wallet](https://github.com/mosip/inji-wallet/blob/master/docs/revocation-support.md): To learn how revocation works with Inji Mobile Wallet # Presentation During Issuance (PDI) ## Overview Presentation During Issuance (PDI) in **Inji Mobile Wallet** is a mechanism that allows an issuer to **request and verify an existing Verifiable Credential (VC)** from a user **before issuing a new credential**. Instead of relying on OTPs, reference numbers, or manual checks, PDI enables issuers to request a **Verifiable Presentation (VP)** from the wallet as part of the issuance flow. The issuer validates the presented credential to confirm identity, eligibility, or authorization before issuing the new credential. Inji Wallet implements this feature using **OpenID4VCI** for issuance and **OpenID4VP** for presentation, with protocol complexity abstracted through dedicated client libraries. ## Why This Feature Matters #### a) Stronger Security & Fraud Prevention Issuers verify cryptographically signed credentials rather than relying solely on user-entered verification methods, reducing the risk of impersonation and fraud. #### b) Trust-Based Issuance Credentials are issued only after validating trusted, issuer-backed proofs, ensuring relying parties receive authentic and eligible credentials. #### c) Improved User Experience Users don’t need to remember IDs or complete repetitive verification steps. Credential selection and consent happen directly within the wallet. #### d) Privacy-Preserving Verification Only required credentials are shared, and users explicitly approve what data is presented, ensuring transparency and user control. #### e) Standards-Based & Interoperable Built on OpenID4VCI and OpenID4VP standards, PDI supports interoperable credential ecosystems across sectors and issuers. ### Supported Credential Types **Credentials That Can Be Presented (for verification)** Any verifiable credential that: * Is stored in the wallet * Matches the issuer’s presentation policy * Conforms to supported formats and schemas **Supported Formats** * **W3C JSON-LD Verifiable Credentials (v1.1 and v2.0)**\ Credentials conforming to the W3C Verifiable Credentials Data Model, including JSON-LD-based credentials with linked data proofs. * **mDoc / mDL (ISO 18013-5 / 18013-7)**\ Mobile document credentials, such as mobile driving licenses and other ISO-compliant mobile IDs, where issuer and verifier support is available. * **SD-JWT (IETF)**\ Selective Disclosure JWT-based credentials compliant with IETF specifications, enabling privacy-preserving disclosure of claims. > The exact credential requirement is defined by the issuer. ### How Does the Presentation During Issuance Flow Work? #### User Flow (Step-by-Step) 1. **User requests a new credential**\ The user initiates a request for a new credential from an issuer using Inji Wallet. 2. **Issuer requires verification**\ The issuer determines that an existing credential must be presented to confirm eligibility or identity. 3. **Wallet displays eligible credentials**\ Inji Wallet identifies and shows credentials that satisfy the issuer’s request. 4. **User selects a credential**\ The user chooses one credential to present. 5. **User reviews and approves sharing**\ The wallet clearly shows what information will be shared, and the user provides explicit consent. 6. **Wallet sends Verifiable Presentation**\ The wallet creates and sends a signed Verifiable Presentation to the issuer. 7. **The issuer verifies the presentation**\ The issuer validates: * Credential authenticity * Trust chain of the original issuer * Proof of subject control 8. **The issuer issues the new credential**\ Upon successful verification, the issuer issues the requested credential. 9. **The wallet stores the issued credential**\ The new credential is securely stored and becomes available to the user.
### Wallet Responsibilities * Display issuer requirements * Show eligible credentials * Capture user consent * Create and send Verifiable Presentations * Store newly issued credentials securely ### Issuer Responsibilities * Define presentation requirements * Verify presented credentials * Enforce issuance policies * Issue credentials upon successful verification #### Error Feedback Granularity * Some failure cases (e.g., invalid presentation, policy mismatch) may return generic errors; enhanced user-facing messaging may be added in future updates. ### Learn More **Presentation During Issuance – Inji Wallet:** To **l**earn how PDI works end-to-end, including issuer policies, presentation exchange, and issuance flows. # Claim 169 QR Code Support ### Overview Inji Mobile Wallet supports receiving and using Verifiable Credentials (VCs) that contain [**Claim-169**](https://docs.mosip.io/1.2.0/readme/standards-and-specifications/mosip-standards/169-qr-code-specification) **formatted QR code blocks**. These QR blocks are issued as **CBOR Web Tokens (CWT)** embedded inside the credential and encoded as Base64. This feature enables secure, compact, and privacy-preserving QR sharing, especially suited for **offline and quick verification scenarios**. The wallet can: * Download credentials containing embedded Claim-169 QR blocks * Store and render QR payloads securely * Allow users to present QR-based identity data when required * Perform validation checks for size, structure, and format #### Specification Details [Claim-169 ](https://docs.mosip.io/1.2.0/readme/standards-and-specifications/mosip-standards/169-qr-code-specification)QR blocks follow standards based on: * **IANA** [**Claim-169**](https://docs.mosip.io/1.2.0/readme/standards-and-specifications/mosip-standards/169-qr-code-specification) **Registry** * **CBOR (Concise Binary Object Representation)** * **CWT (CBOR Web Token)** * Base64-encoded QR payloads embedded inside a VC A Claim-169-enabled VC may include: ``` { "credentialSubject": { "id": "${_holderId}", "fullName": "${fullName}", "mobileNumber": "${mobileNumber}", "dateOfBirth": "${dateOfBirth}", "identityQRCode": $claim_169_values[0] } } ``` Each QR block contains CBOR data with attributes such as: | Claim ID | Attribute | | -------- | ------------ | | 4 | Full Name | | 12 | Phone Number | | 17 | Face Image | ### Why This Feature Matters * Claim-169 QR codes allow identity data to be shared without internet connectivity, enabling fast in-person verification. * Each QR can contain only the required attributes, reducing unnecessary disclosure of personal data. * Users can present identity data by simply displaying a QR code for scanning. * CBOR + CWT provides a compact and cryptographically secure way to encode identity attributes. * A single credential can contain multiple QR codes for different verification use cases. ### Supported Credential Types Claim-169 QR support applies to Verifiable Credentials that: * Contain embedded **CWT QR blocks** * Include Base64-encoded Claim-169 QR fields * Are issued via supported issuance flows Supported VC formats include: * W3C Verifiable Credentials (JSON-LD 1.1 / 2.0) ### How Does the Claim-169 QR Code Flow Work? #### **User Flow (Step-by-Step)** **Step 1: Credential Download** When a credential containing QR blocks is downloaded: * Wallet extracts QR fields (qr1, qr2, etc.) * Decodes Base64 → obtains CWT * Performs optional validation: * CWT structure check * CBOR decoding * Signature verification (platform-dependent) * Stores QR payload securely in encrypted storage **Step 2: Viewing QR Codes** When the user opens the credential: * Wallet detects available QR blocks * Converts CBOR payload → QR image * Displays QR with issuer-defined label (e.g., Age Verification) If decoding fails or QR exceeds size limits, an error message is shown. **Step 3: Sharing QR Codes** For verifier interactions: * User selects the required QR code * Wallet displays QR on screen * Verifier scans the QR directly No additional data leaves the device beyond what is encoded in the QR. #### **Multi-QR Credential Support** A single credential may contain multiple QR codes, for example: * Age Verification * Address Verification * Identity Proof **Note:** While **Inji Certify** supports the design for issuing **multiple QR codes**, **Inji Wallet currently does not support multiple QR codes for Claim-169 credentials.**
### Current Limitations * Signature verification of CWT payloads may vary by platform. * Requires issuer configuration to provide QR labels and supported attributes. * Only Base64-encoded CWT QR blocks are supported in the current release. * Customized error handling is not supported in the current capacity. ### Learn More **Claim 169 QR Code Support**: To learn how this QR code is issued and works with Inji Mobile Wallet, please click [here](https://github.com/inji/inji-certify/blob/release-0.14.x/docs/Claim-169-QR-Code-Support.md) to understand its issuance. # Test This section is for **hands-on testing** of Inji Mobile. Use it to validate real end-user flows. It includes sandbox exercises and user-facing guidance. Use it when you want to try features quickly. #### What you’ll find in this section * [Try It Out](/inji-wallet/inji-mobile/functional-overview/sandbox-details). Start quickly in a sandbox setup. * [Workflow](/inji-wallet/inji-mobile/functional-overview/feature-workflows). Understand the end-to-end user journey. * [End User Guide](/inji-wallet/inji-mobile/functional-overview/end-user-guide). Step-by-step usage for common actions. # Try It Out Welcome to the Inji Wallet Sandbox: Here, you can try out all the features of our app in a risk-free environment. Experiment with different settings, test your use cases, and get hands-on experience with Inji Wallet’s functionalities. Refer [**Inji Wallet Collab Guide**](/inji-wallet/inji-mobile/functional-overview/sandbox-details/inji-setup-guide) to know more about how you can explore '**Inji Wallet**' in our 'sandbox collab environment'. # Inji Mobile - Collab Guide Welcome to the Inji Mobile Guide tailored specifically for our Collab Environment! This guide is designed to assist you in setting up and configuring the [**Inji Wallet**](https://docs.mosip.io/inji) wallet app in our sandbox Collab environment. By following the steps outlined in this guide, you will be able to smoothly install and utilize the Inji Wallet app, empowering you to explore its features and functionalities effectively. Whether you're a Developer, System Integrator, or an enthusiast eager to dive into the world of digital identity, this guide will provide you with the necessary information to get started with Inji Wallet in our [**Collab**](https://collab.mosip.net/) environment. Let's begin this journey of seamless setup and exploration! ### Pre-requisites Before you start with setting up Inji Mobile, ensure you have the following in place. 1. Inji Wallet APK File: * If you are using an Android smartphone, click [**here**](https://drive.google.com/drive/folders/1SRHhFxQBNfOc-cdPU8VlKecIdc-WkuGZ) to get the Inji Mobile `apk` file for installation. * Transfer the `apk` file onto the smartphone on which it is to be installed. 2. Inji Wallet Test Flight Access: * If you are using an iOS device, click [**here**](https://testflight.apple.com/join/7FTAdjLe) get access to the Inji Wallet app on test flight. * Ensure you have get the test flight application from your app store. 3. UIN Credentials: * Issuance of UIN (Unique identification number) as a demo credential will allow you to explore Inji Mobile's capabilities and experience seamless VC sharing firsthand. * Now you can self generate your own UIN Credential using the [Collab environment](https://collab.mosip.net/). * Click on the **Get UIN** button located at the top-right corner of the page. This will open the [Self Registration Form](https://self-register.collab.mosip.net/), Alternatively, you can simply click on this [link](https://self-register.collab.mosip.net/) to self register. You need to duly fill the self registration form. * On successful registration the UIN is sent to you over the email you used for registration, For more details you follow the [Generating Demo Credentials Guide](https://docs.mosip.io/1.2.0/general/collab-getting-started-guide/generating-demo-credentials). *Note*: Please use 111111 as the OTP, for any OTP based feature in Collab environment. 4. For sample Insurance Credentials, please provide the below details in the eSignet authentication page: * Policy id: 7070 * Name: aswin * DOB: 19/02/2025 ### Step-by-Step Process To effectively set up the Inji Mobile app and manage Verifiable Credentials (VCs), follow these detailed steps: **Step 1: Install the Inji Mobile App** 1. For a step-by-step guide on how to install the Inji Mobile application, click [here](/inji-wallet/inji-mobile/functional-overview/end-user-guide). 2. You can visit this [section](https://docs.mosip.io/inji/inji-mobile-wallet/end-user-guide#installing-inji-mobile) for more detailed instructions in the guide. **Step 2: Install the Inji Mobile App - To be used as Verifier App** 1. Follow the same installation process mentioned above in step 1. 2. Setup another instance of the Inji Mobile app on an android device, which can serve as the Verifier app. **Step 3: Download National ID VC Using UIN/VID** 1. Download your credential (VC) onto the app by using your demo UIN. 2. To learn how to download VCs using the Unique Identification Number (UIN) or Virtual ID (VID) feature, click [here](https://docs.inji.io/inji-wallet/inji-mobile/functional-overview/sandbox-details/pages/UOAeYRauh3PfnGjXgFHD#id-1.-download-national-id-mosip-vc). Refer to the section titled `Download credentials using UIN / VID` feature in the guide . **Step 4**: **Download Insurance Credentials Using Policy Details** * Refer to the sample insurance credentials under 'Prerequisites' section. * Refer [here](https://docs.inji.io/inji-wallet/inji-mobile/functional-overview/sandbox-details/pages/UOAeYRauh3PfnGjXgFHD#id-2.-download-insurance-vc) for step-wise download. * You can view the QR Code for insurance credentials in the detailed view. **Step 5: Start Sharing the Credentials** 1. **Quick Share** * To understand the process of sharing credentials from the Resident app to the Verifier app, click [here](/inji-wallet/inji-mobile/functional-overview/end-user-guide#sharing-credentials). * Navigate to the section titled `Sharing Credentials` for detailed instructions. 2. **Share with Face Verification** * Discover how to share credentials with the added security of face verification by clicking [here](/inji-wallet/inji-mobile/functional-overview/end-user-guide#share-share-with-selfie-from-home-page-quick-access-menu). * Refer to the section titled `Face Authentication Flow` for a step-by-step guide. ### Creating your own credentials This section outlines the process of creating your own insurance credentials, generating a QR code, and verifying the QR code using Inji Verify. **Step 1: Creation**: Inji Certify also offers to generate your own credentials which can be used for testing / development purposes. To understand the steps to generate your own Insurance credentials, refer [here](https://docs.mosip.io/inji/inji-verify/build-and-deploy/creating-verifiable-credentials-and-generating-qr-codes#steps-to-generate-verifiable-credential). **Step 2: QR Code generation**: Using Inji Wallet app you can get the QR Code for Insurance Credentials To generate a QR Code using PixelPass library, please refer to the steps [here](https://docs.mosip.io/inji/inji-verify/build-and-deploy/creating-verifiable-credentials-and-generating-qr-codes#steps-to-generate-qr-code).' **Step 3: QR Code verification**: The above generated QR Code can be verified using Inji Verify, by uploading the QR Code. To know more, please click [here](https://docs.mosip.io/inji/inji-verify/build-and-deploy/creating-verifiable-credentials-and-generating-qr-codes#steps-to-verify-qr-code). ### Additional Resources Watch this informative video titled [**Inji Wallet Product Demo to Download and Share VC**](https://youtu.be/JWxJfHMVMFI?si=_VtK4_MaIcs0f_Yh) for a visual walkthrough of the features. Click [here](https://docs.mosip.io/inji) for detailed information about Inji Wallet. > By following these instructions, you will be equipped to seamlessly set up the Inji Wallet application and effectively share your Verifiable Credentials. ### Get In Touch If you require any assistance or encounter any issues during the testing and integration process, kindly reach out to us through the support mechanism provided below. * Navigate to [Community](http://community.mosip.io/). * 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. *Thank you. Wishing you a pleasant experience!* # Workflow ## End-to-End Workflow for Inji Mobile Wallet ### Credential Download via OpenID4VCI Flow This workflow describes how Inji Wallet downloads a Verifiable Credential (VC) from an issuing authority using the OpenID4VCI protocol. ```mermaid sequenceDiagram participant W as Inji Wallet 📱 participant keystore as Secure Keystore 🗝️ participant VCI as VCI Client 🔐📄 participant Verifier as VC Verifier 🔎 participant Pixelpass as Pixelpass 🔲 participant AS as Authorization Server 🔐 participant Certify as Issuing Authority 🏛️ W->>keystore: Generate and store key-pair W->>VCI: Download VC VCI-->>W: Authorize User W->>AS: Redirect to Auth server and authenticate the User AS-->>W: Return Auth code W->>VCI: Auth code VCI-->>W: Get Token Response W->>AS: Token Request with received auth code AS-->>W: Token Response
(access-token, cNonce) W->>VCI: Token Response VCI-->>W: Get Proof JWT Note over W: Construct proof JWT W->>keystore: sign the request keystore-->>W: Return signature W->>VCI: Proof JWT Note over VCI: Construct download request VCI->>Certify: Download Credential Certify-->>VCI: Return Credential(VC) VCI-->>W: Return Credential(VC) W->>Verifier: Verify the Credential alt Verified Successfully Verifier-->>W: Return True Note over W: Store the VC, Render the VC W->>Pixelpass: Generate QR code Pixelpass-->>W: Return QR code image Note over W: Cache QR code and render else Verification Failed Verifier-->>W: Return false with error Note over W: Display error end ``` **Actors:** * **Inji Wallet:** Orchestrates the process, interacts with VCI Client and Secure Keystore. * **Secure Keystore:** Signs cryptographic proofs. * **VCI Client:** Manages OpenID4VCI communication with the Issuing Authority. * **Authorization Server:** Authenticates the user (e.g., eSignet). * **Issuing Authority:** Issues the VC. * **VC Verifier:** Verifies credential authenticity. * **Pixelpass:** Handles QR code generation and encoding. **Workflow Steps:** 1. **Key Pair Generation:**\ On first use, Inji Wallet generates and securely stores a cryptographic key pair via the Secure Keystore. 2. **VC Download Request:**\ User initiates VC download (via UIN/VID or KBI). Wallet instructs VCI Client to start the OpenID4VCI issuance flow. 3. **User Authentication:**\ VCI Client redirects the user to the Authorization Server. User authenticates (OTP, KBI, etc.). Authorization Server returns an auth code. 4. **Token Exchange:**\ Wallet exchanges the auth code for an access token and nonce from the Authorization Server. 5. **Proof Construction:**\ Wallet creates a proof JWT with the nonce, sends it to Secure Keystore for signing, and receives the signed proof JWT. 6. **Credential Issuance Request:**\ VCI Client sends the signed proof JWT to the Issuing Authority. Issuer returns the VC. 7. **Credential Verification:**\ Wallet verifies the VC with the VC Verifier (checks signature and schema). If verification fails, an error is shown. 8. **VC Storage and Rendering:**\ Verified credentials are securely stored. For some credentials, a QR code is cached for offline use. ### Verifiable Presentation (VP) Sharing via OpenID4VP Flow This workflow explains how Inji Wallet shares selected VCs with a verifier (Relying Party) using the OpenID4VP protocol. ```mermaid sequenceDiagram participant U as User 🙋 participant W as Inji Wallet 📱 participant keystore as Secure Keystore 🗝️ participant OVP as OpenId4VP Module 🔐📄 participant Verifier as Relying Party(Verifier) 🌐 W->>keystore: Generate and store key-pair Note over Verifier: Generate QR code with auth request W->>Verifier: Scan QR code Verifier-->>W: Return auth request W->>OVP: Pass auth request Note over OVP: validate the auth request OVP-->>W: Return validated auth request Note over W: Process auth request and
display Matching VCs U->>W: Select VCs and give consent W->>OVP: Construct unsigned VP token
(selected VCs based on format, holderId, & SignatureSuite) Note over OVP: Construct unsigned VP token by attaching proof without signature OVP-->>W: Return unsigned VP token by format Note over W: Sign VP token W->>OVP: Return signed data OVP->>Verifier: Send Auth response
(VP token, Presentation Submission) ``` **Actors:** * **User:** Selects credentials and provides consent. * **Inji Wallet:** Manages the process, interacts with OpenID4VP Module and Secure Keystore. * **Secure Keystore:** Signs VP tokens. * **OpenID4VP Module:** Validates requests and structures the VP token. * **Relying Party (Verifier):** Requests and validates credentials. **Workflow Steps:** 1. **QR Code Creation:**\ The verifier generates a QR code containing the authentication request. 2. **QR Code Scan:**\ User scans the QR code in Inji Wallet, which extracts the auth request. 3. **Auth Request Validation:**\ Wallet passes the request to the OpenID4VP Module for validation (issuer, signature, expiry, audience). 4. **Display Matching VCs & User Consent:**\ Wallet finds matching credentials, displays them, and the user selects which to share and gives consent. 5. **Construct Unsigned VP Token:**\ Wallet sends selected VCs and metadata to the OpenID4VP Module, which constructs the VP token (unsigned). 6. **Sign VP Token:**\ OpenID4VP Module sends the unsigned VP token to Secure Keystore for signing. The signed VP token is returned. 7. **Send Auth Response to Verifier:**\ Wallet sends the signed VP token and presentation\_submission to the verifier. The verifier validates the response and, if successful, completes the transaction. ## Features Flow This document delineates the workflow for essential functionalities of Inji Wallet. ### 1. First App Launch After installing the application for the first time, the user will be asked to set up unlock method for it. The app supports biometric or PIN-based locks. For more details, refer to the [End User Guide](/inji-wallet/inji-mobile/functional-overview/end-user-guide). #### Launch with passcode unlock method
#### Launch with biometric unlock method
### 2. Downloading, Verifying and storing credentials Residents have the ability to download a Verifiable Credential (VC) for themselves, their family members, or friends using a single mobile device. This can be done through two methods: While downloading the VCs, the credentials are validated and verified for the authenticity of the issuer using the signature and the proof type provided in the VC. * Downloading VC using OpenID for VC Issuance Flow (eSignet) #### Download via eSignet Below sections are going to detail as how Inji Wallet as an OIDC client to OpenID4VCI method of downloading a VC and illustrated implementations. **Download credentials using UIN / VID**: This method of VC download illustrates the **OpenID4VCI** method of download using UIN / VID issued to the resident. In this, eSignet plays the authentication and authorisation end point to connect to the credential provider (Reference Implementation: MOSIP). To understand more about Onboarding Mimoto (Inji BFF) as an OIDC client to support credential issuance from any issuer who support OpenID4VCI protocol refer [here](https://docs.mosip.io/inji/inji-mobile-wallet/customization-overview/credential_providers). **Download credentials using Knowledge Based Identification (KBI)** This method of VC download illustrates the **OpenID4VCI** method of download using KBI (Knowledge Based Identification). In this, eSignet plays the authentication, authorisation and credential issuance end point to connect to the credential provider. To understand more about Onboarding Mimoto (Inji BFF) as an OIDC client to support credential issuance from any issuer who supports **OpenID4VCI** protocol, refer [here](https://docs.mosip.io/inji/inji-mobile-wallet/customization-overview/credential_providers).
**Appendix**: * The term “identifier” in the architecture diagram refers to the unique identifier which can be used to download the credential on the esignet login Page * eSignet supports Various types of authorizations, ACR value is configured based on the Issuers' need to include the authorization mode in the authorization page * Types of Authorization Supported for Credential Download by eSignet are: * **Login With OTP**: Credential download using OTP Based authentication to authorize the user **Illustrated Implementation**: National ID credentials download * **Login With KBI**: Credential download using KBI to authorize the user. The knowledge (as described by the credential issuer to authorize) is exposed to eSignet from Registry (Issuer) through eSignet Issuance Plugins **Illustrated Implementation**: Insurance ID credentials download ### 3. Sharing of credentials The credentials are shared in a peer-to-peer model with the verifier application. The data exchange between devices is done using the BLE Protocol. For more information, refer to [Tuvali](/inji-wallet/inji-mobile/technical-overview/integration-guide/building-verifiable-credentials-wallet-with-inji-libraries/tuvali) documentation.
### 4. QR code login process * Residents can use Inji Wallet to log in to any service provider app (integrated with e-Signet) by just scanning a QR code from their portal. * The app performs offline face auth after scanning the QR code to verify the user's presence. * Once the presence is verified, the resident is given the option to choose the optional information to be shared with the service provider portal. * After consent is provided, the app sends a WLA (Wallet local auth) token which is a JWT token to the relying party. * The resident is then given the access to the portal after the token verification. #### Step 1: VC activation process
#### Step 2: QR code login
### 5. Data backup and restore From Settings screen, users can access Backup settings screen. In Backup settings screen, users can configure their preferences for data backup. The setting, configured once during the application's lifecycle, determines whether Google Drive or iCloud will be utilized based on the device platform. To restore backup data to the mobile wallet, users must log in to the same account and configure settings within the app accordingly. Additionally, restored Verifiable Credentials (VCs) should be re-activated to enable QR Code login functionality.
# End User Guide {% hint style="warning" %} **Important**: We are in the process of updating screenshots and content in the End User Guide to reflect our new branding. These updates will be available soon, thank you for your patience! {% endhint %} This document serves as a concise user guide for end users, providing comprehensive information on the features and functionalities offered by Inji Wallet. ## Installing Inji Wallet The below sections explain the steps for installing the Inji Wallet application on Android and iOS platforms. #### On Android device 1. To install the Inji Wallet app on an Android smartphone, click [**here**](https://drive.google.com/drive/folders/1gBjFSdpjxU4bsZi7-xS59W1-EIFKrkS8) to get the Inji Wallet `apk` file for installation. 2. Transfer the `apk` file onto the smartphone on which it is to be installed. 3. Click on the `apk` file and follow the OS installation instructions. #### On iOS device 1. Install the test flight app on your device. 2. Follow the steps mentioned [here](https://docs.mosip.io/inji/inji-wallet/sandbox-details/inji-setup-guide#pre-requisites). The below screenshots explain the next steps after you get access.

Installation of Inji Wallet on iOS mobile device

Installation of Inji Wallet on iOS mobile device

### First launch of the app After installation when you launch the app for the first time: * Select the preferred language. * You can read though a five-page tutorial for the Inji Wallet which is presented. * Choose a secure login method to enter the app (Biometric / PIN). This can be achieved through a PIN or the device's Biometrics (such as fingerprint or facial recognition). Once the setting is done you will be directed to the app's home page.
## Download of Verifiable Credentials Inji Wallet supports VC downloads using **eSignet** as the authorization layer. Some of the available use-cases include: * **Download National ID (MOSIP VC)** * **Download Insurance VC** * **And many more use-cases available to explore via eSignet!** ### **1. Download National ID (MOSIP VC)** **Download credentials using UIN / VID**: * On the home page, a plus "+" symbol will display the list of issuers from which you can download VCs. * Select the issuer that states **National Identity Department** and choose a credential type (MOSIP National ID). Once clicked, the browser will open and take you to the eSignet page. * On the authorization page (eSignet page), the user has to enter the UIN / VID and provide the OTP sent to the registered mobile number/email. * Upon successful validation of OTP, the user will be taken back to the application and land on the loading screen. After the download process is completed, the user will be returned to the home page, where the Downloaded Credential will be available.
### 2. Download Insurance VC **Download credentials using KBI:** * A plus "+" symbol on the home page will display the list of issuers from which you can download VCs. * Select the issuer that states **Stay Protected Insurance** and choose a credential type (Health Insurance, Life Insurance). Once clicked, the browser will open and take you to the eSignet page. * On the authorization page (eSignet page), the user has to enter the Policy Number, Full Name, and Date Of Birth(D.O.B). * Upon successful validation, the user will return to the application and land on the loading screen. Following the completion of the download process, the user will be returned to the home page, where the Downloaded Credential will be available.
## Detailed view of the downloaded VC Once we click on the downloaded VC on the Home Page, the detailed view opens up for the VC. ### Detailed View of National ID VC Users can see all the details of the National ID in the detailed view. In addition, the user can access the quick access menu (...) on the top right to perform actions such as Pin/Unpin, Share, Share with Selfie, QR Code Login, view Activity Log, and Remove from the detailed view of the VC.
### Detailed View of Insurance VC Users can see all the Insurance policy details in the detailed view along with the QR Code. The QR Code can be magnified which can be presented to the verifier for scanning. Through the quick access menu (...) on the top right user can also perform other actions like Share, Pin, Remove and Activity log on the VC.
### Download Credential by Scanning a QR Code (Credential Offer with Pre-Auth Code) This flow allows you to download credentials simply by scanning a QR code, **without login** or **manual input of ID/Identifier or other data**. #### 1. Pre-Authorized Credential Offer (**Without Transaction Code**) Used in public campaigns or mass rollouts (e.g., vaccine certificates, land cards). 1. On the issuer’s website, or from a flyer/poster, scan the QR code using the **Scan & Download** option available in Inji Wallet. 2. Click on the **"+" (Add Credential)** icon. ![image](/files/bnxNLaeqyLRRsQ3srh34) 3. Select the first option: **Scan & Download**. ![image](/files/6YhjBfX5FxLzH7qw35lV) 4. Scan the QR code from the issuer's website or printed material. ![image](/files/1d4xTgUd3rhaaCJ59mmI) ![image](/files/8I4duj0rDaA2tCyScVoj) ![image](/files/jBSJYjxnewgCV3xpz0qQ) ![image](/files/hQSAMvclWttfzHvy9LV9) ![image](/files/RDKasN9G8n061lJFo8ii) 5. If this is your first time interacting with the issuer, a **trust screen** will appear asking you to trust the issuer. 6. You can **proceed to trust** and add the issuer to your trusted list or **decline** as per your preference. This prompt appears only **once per issuer**. * If you **Decline**, the download **will not proceed** further. * If you **Allow**, the download **will proceed** further. ![](/files/7554XRSJ9QdBmEypbeoq) 7. The wallet recognizes the embedded **credential offer**, without needing to log in or enter any data, your credential starts downloading.\ \ ![](/files/TvbrC5FhuF5U0EhKBG3I) 8. You’ll see a **success message** and the VC will appear in your wallet. ![](/files/awMwzPt3jIy3EfeKt3Pz) ![](/files/5vIn6t73dMsnUyZ9Ecey) ![](/files/CKMtP3r3VV8fS0P5zoFo) #### B. Pre-Authorized Credential Offer (**With Transaction Code**) Used for personalized and secure issuance (e.g., mDL, insurance). 1. On the issuer’s website, or from a flyer/poster, scan the QR code using the **Scan & Download** option available in Inji Wallet. 2. Click on the **"+" (Add Credential)** icon. ![](/files/bnxNLaeqyLRRsQ3srh34) 3. Select the first option: **Scan & Download**. ![](/files/6YhjBfX5FxLzH7qw35lV) 4. Scan the QR code from the issuer's website or printed material. ![](/files/1d4xTgUd3rhaaCJ59mmI) ![](/files/8I4duj0rDaA2tCyScVoj) ![](/files/jBSJYjxnewgCV3xpz0qQ) ![](/files/hQSAMvclWttfzHvy9LV9) ![](/files/RDKasN9G8n061lJFo8ii) 5. If this is your first time interacting with the issuer, a **trust screen** will appear asking you to trust the issuer. ![](/files/7554XRSJ9QdBmEypbeoq) 6. You can **proceed to trust** and add the issuer to your trusted list or **decline** as per your preference. This prompt appears only **once per issuer**. * If you **Decline**, the download **will not proceed** further. * If you **Allow**, the download **will proceed** further. 7. You will be prompted to **enter a Transaction Code / OTP** provided by the issuer via SMS or Email. ![](/files/hgMRbLucqsW16jzRxbM8) ![](/files/wmM7BHdqQYkhRSYgg0QB) 8. After entering the code, the wallet retrieves the credential securely. ![](/files/TvbrC5FhuF5U0EhKBG3I) 9. The wallet recognizes the embedded **credential offer**, Without needing to log in or enter any data, your credential starts downloading. 10. You’ll see a **success message** and the VC will appear in your wallet. ![](/files/awMwzPt3jIy3EfeKt3Pz) ![](/files/5vIn6t73dMsnUyZ9Ecey) ![](/files/CKMtP3r3VV8fS0P5zoFo) ### Viewing the history of the downloaded VC After completing several scenarios, we can find it by selecting the third icon in the bottom right corner when we navigate to the history page. This page will display a comprehensive list of all the events.
### Activity Log for a VC: Users can view the activity logs of a VC from the Home Page or the detailed view by choosing the menu option "View Activity Log" from the quick access menu (...).
## Credential Sharing Methods ## Pre-requisites * Two or more devices with Inji Wallet installed are required to share credentials. The relying party's phone should be an Android device. * All required permissions like Bluetooth, location, and camera access are enabled on both devices. * The parties involved are usually a Resident (sharing party) who wishes to share their credentials with a Relying party (receiving party), a banker, a health worker, or other professional service. Users can now share their credentials using any of the methods listed below: 1. Share option from the NavBar. 2. Share or Share with Selfie option from the quick access menu (...) from a VC in the **Home Page** 3. Share or Share with Selfie option from quick access menu (...) in **detailed view** of VC. Let us understand the process of sharing credentials using an example and see the step-wise process for all the above three methods. Suppose a Resident wishes to share their credentials with a Relying/ Requesting party through the receiver's phone, the following steps outline the procedure for both parties involved: ### **Share** **from Share Option in NavBar** **On the Sharing Party's phone:** * The resident opens the QR Code Scanner by clicking on the `Share` button in the NavBar. The application now prompts for permissions. * Upon granting the necessary permissions, the app opens a camera where the resident can scan the QR code of the recipient's (Verifier/Relying Party) phone. * Once the QR code is successfully scanned, both phones will establish a Bluetooth connection. * The resident then needs to choose a downloaded VC and select either the Share or the Share with Selfie option. * The Share button will solely share the VC, while the Share with Selfie option will verify if the sender's face matches the photo in the VC before proceeding to share.
**On the Relying Party's phone** * This functionality is only available on Android devices. To access it, the receiver needs to navigate to the settings page and locate the `Receive Cards` option. * On selecting this option, it will open the QR code page. For the relying party to be able to receive a card, the resident needs to scan the QR code using a shared phone. Once the QR code is scanned and shared, the relying party will receive the VC and be able to preview its contents. * To view the received cards, they would need to access the settings page and find the `Received Cards` section. Clicking on this section will display the received cards. If the receiver has not received any card, this section will be empty. * Please note that the relying party can only view the received cards and will not be able to share or perform other actions with them.
### **Share / Share with Selfie from Home Page Quick Access menu** **On the Sharing Party's phone:** * The resident clicks on the quick access menu (...) from a VC on the Home Page and chooses the Share or Share with Selfie option from the menu. * The application now prompts for permissions if not granted already. * Upon granting the necessary permissions, the app opens a camera where the resident can scan the QR code of the recipient's (Verifier/Relying Party) phone. * Once the QR code is successfully scanned, both phones will establish a Bluetooth connection. * The Share button will solely share the VC, while the Share with Selfie option will verify if the sender's face matches the photo in the VC before proceeding to share.
**On the Relying Party's phone**: * This functionality is only available on Android devices. To access it, the receiver needs to navigate to the settings page and locate the `Receive Cards` option. * On selecting this option, it will open the QR code page. For the relying party to be able to receive a card, the resident needs to scan the QR code using a shared phone. Once the QR code is scanned and shared, the relying party will receive the VC and be able to preview its contents. * To view the received cards, they would need to access the settings page and find the `Received Cards` section. Clicking on this section will display the received cards. If the receiver has not received any card, this section will be empty. * Please note that the relying party can only view the received cards and will not be able to share or perform other actions with them.
### **Share with a selfie from VC Detailed View Quick Access menu** **On the Sharing Party's phone** * The resident clicks on the VC on the Home page and clicks on the quick access menu (...) in the detailed view. Resident can choose either Share or Share with Selfie option from the menu. * The application now prompts for permissions if not granted already. * Upon granting the necessary permissions, the app opens a camera where the resident can scan the QR code of the recipient's (Verifier/Relying Party) phone. * Once the QR code is successfully scanned, both phones will establish a Bluetooth connection. * The Share button will solely share the VC, while the Share with Selfie option will verify if the sender's face matches the photo in the VC before proceeding to share. **On the Relying Party's phone:** * This functionality is only available on Android devices. To access it, the receiver needs to navigate to the settings page and locate the `Receive Cards` option. * On selecting this option, it will open the QR code page. For the relying party to be able to receive a card, the resident needs to scan the QR code using a shared phone. Once the QR code is scanned and shared, the relying party will receive the VC and be able to preview its contents. * To view the received cards, they would need to access the settings page and find the `Received Cards` section. Clicking on this section will display the received cards. If the receiver has not received any card, this section will be empty. * Please note that the relying party can only view the received cards and will not be able to share or perform other actions with them. ### **Verifiable Credential Sharing & Presentation via OpenID4VP** > **Note:** Screenshots will be added soon to enhance the user experience and better explain the steps shown below. Inji Wallet supports two primary modes of sharing Verifiable Credentials (VCs) using the **OpenID4VP** protocol: * **Same-Device Flow**, where the wallet and verifier are accessed from the same mobile device. * **Cross-Device Flow**, where the wallet and verifier operate on separate devices. Both flows support **standard JSON-LD VCs**, **mDL (ISO 18013-5)**, and IETF **SD-JWT** credentials for full or non-selective disclosure sharing.\ For privacy-preserving selective disclosure, the **SD-JWT VP** flow is followed, as described below. #### Cross-Device Flow (OpenID4VP) This method is used when the **Inji Wallet** is on a **mobile phone**, and the **verifier** (such as a service provider portal, kiosk, or scanner) operates on a **different device** (e.g., laptop or tablet). **Steps to Present Credentials:** 1. **Verifier generates a QR code** on their system/portal requesting specific credentials. 2. On your **Inji Wallet**, tap the **QR scanner icon** from the home screen or use the “Share” option. 3. **Scan the QR code** displayed by the verifier. 4. The wallet reads the verifier’s request and shows you a list of **matching credentials**. 5. You are prompted for **face authentication**. 6. Choose the credentials you want to share. 7. Tap **“Share”** to proceed. The wallet sends the Verifiable Presentation (VP) to the verifier securely. 8. You’ll see a confirmation message once the sharing is complete. #### Same-Device Flow (OpenID4VP) This method is useful when you’re accessing a portal from the **same mobile device** that has the **Inji Wallet** installed. **Steps to Present Credentials:** 1. On your phone browser, visit the service portal that is requesting your credentials. 2. Tap on the **“QR Code”** or similar button. 3. This opens a **deep link** that launches your **Inji Wallet app** automatically. 4. The wallet fetches the verifier’s request. 5. A list of matching credentials is displayed. 6. You will be asked for **face authentication**. 7. Choose the credentials to be shared. 8. Tap **“Share”**. 9. You are automatically redirected back to the service portal (Android). * On **iOS**, you may need to manually switch back to the browser. #### **Selective Disclosure Flow (IETF SD-JWT VP)** This method allows users to share **only specific claims** from an IETF **SD-JWT credential**, ensuring **privacy-preserving** and **minimal disclosure** of information. **Steps to Present Credentials with SD-JWT VP:** 1. Access the verifier’s **portal or service** (same-device or cross-device). 2. Initiate the **credential request** using the **OpenID4VP flow**. 3. The verifier specifies **required claims** (e.g., Name, Date of Birth). 4. The **Inji Wallet** parses the **SD-JWT credential** and identifies which claims can be selectively disclosed. 5. The wallet displays: * The verifier’s details and request information. * A **list of available claims** within the SD-JWT credential. 6. The user can **select only the claims** they wish to share. 7. The wallet generates a **Verifiable Presentation (VP)** containing only the selected claims. 8. You are prompted for **authentication** (Face) if VC contains a face photo. 9. Upon confirmation, the **SD-JWT VP** is securely shared with the verifier. 10. A success message confirms completion of the privacy-preserving sharing process. ### **Revocation Check** 1. **Download a new credential into the Inji Wallet.**\ As soon as the download finishes, the app automatically begins checking whether the credential is still valid. 2. **The wallet looks up the status of the credential.**\ It checks if the issuing authority has marked the credential as: * Active (valid) * Revoked (no longer valid) * Or if the status cannot be confirmed yet 3. **The wallet verifies the information.**\ To make sure the status is trustworthy, the wallet: * Confirms the status file is valid * Checks that the information is current 4. **The wallet updates the credential status on the screen.**\ Based on the result, you will see: * 🟢 **Valid** — you can use or share the credential * 🔴 **Revoked** — you cannot use it * 🟡 **Pending** — try again later; internet may be required 5. **The wallet logs the status check.**\ The app saves a record in your **History** showing when the status was last checked. 6. **Manually check the status anytime.**\ To check the status later, you can go to the card options and tap **Check Status**. ### Pinning a VC After clicking on the ellipsis button on the downloaded VC, a button will appear allowing for the VC to be pinned. Selecting this option will pin the specific VC to the top of the screen.

Pinning a VC

Pinning a VC

Pinning a VC

### Activating a VC There are two ways to activate the VC: * The first option is to click on the "Activate for online login" menu option by clicking on the quick access menu (...) of the card from the Home Page. * The second option is to click on the "Activate for online login" menu option by clicking on the quick access menu (...) of the card from the detailed view of the VC. * A confirmation alert message will be prompted upon clicking the "Activate for online login" option. Once permission is granted, the user will be directed to an OTP screen. After entering the correct OTP, the VC will be activated and projected on the screen with the same message.
### Deleting a VC There are two ways to remove/delete a VC from the wallet: * The first option is to click on the Remove from Wallet menu option from the quick access menu (...) of the card from the Home Page. * The second option is to choose the Remove from Wallet menu option from the quick access menu (...) of the card from the detailed view of the VC. * Upon clicking this option, the user will be prompted with a pop-up for confirmation. If the user chooses, “Yes, I confirm” the VC will be removed from the wallet.
## Search Users can now search for a VC by providing a search string in the search bar. VCs that match the search criteria will be displayed.
## Data backup and restore ### Backup To backup VCs, the user has to choose their preference for the cloud based on the device they are using. 1. Firstly, the user has to go to settings and click on the Backup and Restore menu options. 2. The User should consent for the app to use the drive, and once consented, the application displays a backup and restore screen. 3. In this screen, the user can manually take a backup by clicking on the Backup button and this asynchronously happens allowing the user to use the application. 4. Users will be notified of success or failure. ### Data backup - Android
### Data backup- ios
### Restore To restore backed-up VCs, the user has to choose their preference of the cloud based on the device and use the same Google/apple ID that they used for taking backups. 1. Firstly, the user has to go to settings and click on the Backup and Restore menu options. 2. The user should consent for the app to use the drive, and once consented, the application displays a backup and restore screen. 3. Users find the details of latest backup details in the Last Backup Details section. 4. In this screen, the user can manually restore a backup by clicking on the Restore button and this asynchronously happens allowing the user to use the application. 5. Users will be notified of success or failure. ### Restore - Android
### Restore - ios
# Setup ### Repositories {% embed url="" %} ### Prerequisite * [Node](https://nodejs.org/en/download) v18.17.1 and npm 8.19.3 * [Gradle](https://gradle.org/install/) 8.6 * [Java 17](https://www.oracle.com/ph/java/technologies/downloads/#java17) * [Expo](https://docs.expo.dev/get-started/installation) 51.0.0 (React Native 0.74.5) * [Android Studio](https://developer.android.com/studio) (latest stable release) * [Android SDK](https://developer.android.com/) with Build-Tools 35.0.0, compileSdk 35, minSdk 24, targetSdk 35, NDK 21.4.7075529, Kotlin 1.9.22 * [XCode](https://developer.apple.com/xcode/) 15 or higher, for iOS development (Minimum Deployment Target: 14.0) * [CocoaPods](https://cocoapods.org/) > 1.12 and Ruby >= 2.6.10, for iOS development * [Docker](https://docs.docker.com/get-docker/) and [Docker Compose](https://docs.docker.com/compose/install/), for running the Mimoto backend locally To perform **offline sharing using BLE**, we recommend below: * Devices with Bluetooth v4.2 and above * Android v23 and above for Android ## Android - Build and Run The below sections describe the steps for building the android application in Mac and Windows OS. ### 1a. Installation and Keystore generation on MAC #### Step 1: Configure Node & npm (recommended to use v18.17.1) ``` brew install nvm nvm install 18.17.1 nvm use 18.17.1 ``` #### Step 2: Configure Yarn ``` brew install yarn ``` #### Step 3: Configure Gradle & Java ``` curl -s "https://get.sdkman.io" | bash sdk install gradle 8.6 sdk install java 17.0.13-amzn ``` #### Step 4: Configure Expo, refer [here](https://docs.expo.dev/get-started/installation). #### Step 5: Configure Android SDK, refer [here](https://developer.android.com/). Configure environment variables in your `~/.zshrc /` or `~/.bashrc` (depending upon your shell) ``` export ANDROID_HOME="$HOME/Library/Android/sdk" export ANDROID_PLATFORM_TOOLS="$ANDROID_HOME/platform-tools" export ANDROID_CMDLINE_TOOLS="$HOME/Library/Android/sdk/cmdline-tools/latest/bin/" export PATH="$PATH:$ANDROID_PLATFORM_TOOLS:$ANDROID_CMDLINE_TOOLS" ``` #### Step 6: Generate debug keystore for building debug build. ``` keytool \ -genkey -v \ -storetype PKCS12 \ -keyalg RSA \ -keysize 2048 \ -validity 10000 \ -storepass 'android' \ -keypass 'android' \ -alias androiddebugkey \ -keystore android/app/debug.keystore \ -dname "CN=io.mosip.residentapp,OU=,O=,L=,S=,C=US" ``` Export keystore ``` export DEBUG_KEYSTORE_ALIAS=androiddebugkey export DEBUG_KEYSTORE_PASSWORD=android ``` ### 1b. Installation and Keystore generation on Windows #### Step 1: * Install Git * Use the below link to download git ``` https://git-scm.com/download/win ``` * After installation, run Git as admin. #### Step 2: * Install SDKMAN * Use the below command in Git terminal ``` curl -s "" | bash ``` * If you encounter an error while installing sdkman, please install zip on your system using your favourite package manager. **Install zip** 1. `SDKMan` requires the installation of the zip utility, which is not included in the default installation of Windows Git Bash. 2. To address this, please visit the [website](https://sourceforge.net/projects/gnuwin32/files/). 3. Locate **zip** in the list of available files and download the **zip-3.0-bin.zip** archive. Extract the **zip.exe** file from the archive and place it in the **bin** folder. Location of bin folder `C:\Program Files\Git\usr\bin`. 4. Finally, rerun the `SDKMan` installation script. #### Step 3: * Install gradle * Use the command below in Git terminal. ``` sdk install gradle 8.6 ``` * To check the installed gradle version. `gradle -V` #### Step 4: * Install Java JDK, refer [here](https://www.oracle.com/ph/java/technologies/downloads/#java17). ``` [!TIP] Restart system ``` #### Step 5: * No global install needed — Expo is already a project dependency and is used via `npx expo` (the legacy global `expo-cli` is deprecated). #### Step 6: * Install Android SDK, refer [here](https://developer.android.com/). #### Step 7: * Install Node, refer [here](https://nodejs.org/en/download). #### Step 8: * Install nvm ``` curl -o- | bash ``` or ``` wget -qO- | bash ``` update the nvm version ``` nvm install 18.17.1 nvm use 18.17.1 ``` #### Step 9: Install adb ``` https://sourceforge.net/projects/quickadb/ ``` Configure ANDROID\_HOME and JAVA\_HOME in system environment variables ### 2. Command to build the application #### Step 1: * Clone Inji repository. #### Step 2: * Create an `android/local.properties` file with the following data: ``` sdk.dir = ``` * Alternatively, you can open the Android folder in the android studio. It will create `local.properties` file with `sdk.dir = `. > Note: > > * Default path for MacOS: `/Users//Library/Android/sdk` > * Default path for Linux: `/home//Android/Sdk` > * Default path for Windows: `C:\Users\\AppData\Local\Android\sdk` #### Step 3: * Inji application currently supports two themes: **gradient** and **purple**. * The default theme of the app is gradient. * To change the theme of the application, go to `.env` file and change the value of `APPLICATION_THEME` to `gradient` or `purple` #### Step 4: * Update mimoto url as `https://api.collab.mosip.net` for `MIMOTO_HOST` [here](https://github.com/inji/inji-wallet/blob/main/.env) * Update esignet host as `https://esignet.collab.mosip.net` for `ESIGNET_HOST` [here](https://github.com/inji/inji-wallet/blob/main/.env) * To deploy mimoto in local refer [here](https://docs.inji.io/inji-wallet/inji-mobile/build-and-deployment/local-setup#how-to-run-this-setup) #### Step 5: * Go to the root folder of the project in the terminal. * Install all the dependencies using `npm install`. #### Step 6: **Build and run the application on a connected device or emulator:** * Run `npm run android:mosip` to build and install the application on a connected device or a running emulator. * Run `npm run android:mosip --reset-cache` to build and install the application if any change is made in the .env file. > Note: Inji Wallet uses the Android hardware-backed keystore for secure key storage where available. Emulators (and some devices) don't support hardware-backed keystore — the app still runs and falls back to a software-backed keystore, but shows a one-time in-app warning about it. Use a physical device if you need to validate the hardware-backed keystore path. ### 3. Troubleshooting If you encounter the below issue on Windows, ``` **FAILURE:** Build failed with an exception. **Where:** Script 'C:\....\inji\node_modules\expo\scripts\autolinking.gradle' line: 2 **What went wrong:** A problem occurred evaluating script. > Could not read script 'C:\"PATH"\inji\node_modules\expo\scripts\android\autolinking_implementation.gradle' as it does not exist. ``` * Run `npm i expo-modules-autolinking@~1.11.0` and rebuild the app * Path for debug apk in Inji directory `android/app/build/outputs/apk/mosip/debug` ### 4. Setting Up Google API Services and Client ID for Data backup & Restore #### Step 1: **Creating A Google Cloud Project** Refer to this documentation on setting up a Google Cloud Project - #### Step 2: **Enabling Google Drive APIs** Go to - ![GCP API Library](/files/ZLSkxa3QfYDxWmbPzn5l) Search for `Google drive API` and Select Google Drive API from the list. Then enable the API. ![GCP Drive API Enable](/files/cCIEY6G79CAIc2Mq5C0W) #### Step 3: **Create Google Consent Screen** Go to - Create a new Consent Screen with necessary details such as - App Name, User Support Email, App Logo and Developer Info. Once added these details Save and Continue. #### Step 4: **Create Oauth Client ID** Go to - ![GCP Create Client ID](/files/wyMzJ3ODXI9Y7juaGHcQ) Click on `CREATE CREDENTIALS` and choose `OAuth client ID` ![GCP Create Client ID](/files/Eyk6JqydtcatscFDEeM6) Choose Appliation type as `Android` ![GCP Create Client ID](/files/irkM8bFfyKd3I5AWdZUJ) Add in details such as *Name*, *Package Name* and *SHA- Fingerptint* > Note: > > * SHA-1 should be of the keystore generated for signing the APK > * Make sure you have checked `Custom URI Scheme` in `Advanced Settings` > * The APK signing keystore needs to be unchanged for backup feature to work as the SHA-1 is 1-1 mapped for a client ID created #### Step 5: **Set Environment Variable** Once the Client ID has been created copy the client ID and add it as part of `.env` file. `GOOGLE_ANDROID_CLIENT_ID=""` ### 5. Build for PlayConsole The Internal testing version of the build can be uploaded to `PlayConsole` for testing. PlayConsole allows the creation of internal testers group. ![Internal testers](/files/GLf3elASltOSMCeH7LRo) **Publishing build manually to PlayConsole** A Google play console developer account is a must to publish builds in PlayConsole. 1. Set the backend URL and choose a theme (gradient | purple) inside the `.env` file. 2. Build the Apk or App bundle. 3. Login to PlayConsole and create a new release inside Internal testers. 4. Upload the Apk or App bundle to PlayConsole. **Upload in PlayConsole** ![img.png](/files/PQcz50KrHwNHL0aAoeyR) ![img.png](/files/noT7CeLCYcbukmQZVd5x) 1. Once the build is uploaded and saved you will be able to see the status of the release with version name, code, API level and some more details. ![img.png](/files/QTCKsN9q0oQZBqpfOhJB) 2. Select the testers group you want to share with. Once saved, you can copy the link and share the same with the testers to test the APK or App bundle. ![img.png](/files/a81tYgvsWMyDjdF6MOer) 3. You are required to manually share the link with the testers as they will not receive any notifications when a new build is uploaded. **Publishing build via Github actions (Automation) to PlayConsole** 1. A Google PlayConsole developer account must be configured to Inji to publish builds via PlayConsole. > Testers must be added to internal testers group in Play console. ![img.png](/files/a81tYgvsWMyDjdF6MOer) 2. To deploy the Android build to PlayConsole, select the `Internal Build [Android & IOS]` workflow from github actions, and select `Android` in the **Build for** option. ![img.png](/files/ROBvf7S6pOfFjgxoYW2p) 3. Choose the branch, backend url, theme and describe about build details. 4. Click the `Run` workflow button. 5. Once the pipeline has done with building the app (takes around \~25-30min), you need to login to PlayConsole and verify the build version name and code in the internal testers track. 6. Now, you can share the link to testers. ***Note***: Only those who are registered in the selected testers group will be able to download the App from Google Play. *** ## iOS - Build and run The below section describes the steps build the iOS application. ### 1. Installation and Keystore generation #### Step 1: Follow the [Steps](#1a-installation-and-keystore-generation-on-mac) to configure Node & npm, Expo and generate debug keystore #### Step 2: Configure XCode, refer [here](https://developer.apple.com/xcode/) #### Step 3: Enable iCloud and create Containers, refer [here](https://developer.apple.com/help/account/manage-identifiers/create-an-icloud-container/) ### 2. Build process * Install all the dependencies ``` npm install npx pod-install ``` * Run Metro bundler in the background ``` npm start ``` * Run Inji directly to a connected device Command to run on simulator ``` npm run ios ``` Command to run real device ``` npm run ios -- --device ``` **Note:** When the application is built via an IDE (e.g. XCode), Metro needs to be started manually — the Metro hook is removed when building via XCode. Building via npm commands (`npm run android:mosip` or `npm run ios`) starts Metro automatically. ### 3. Build for TestFlight The beta version of the build can be uploaded to `TestFlight` for testing. TestFlight allows the creation of internal and external testing teams who will be notified once a new build is published. ![Testflight testers](/files/01Zzm9XEs6GIn2EseYOm) **Publishing build manually to TestFlight** An Apple developer account is a must to publish builds in TestFlight. 1. Set the backend URL and choose a theme (gradient | purple) inside the `.env` file. 2. Archive the build using `xcode`. 3. Upload the archive to Testflight. First choose `Distribute App`. ![img.png](/files/fgsrOnBNEnBhUFRLIIOG) **Upload in TestFlight** ![img.png](/files/bmrbKExHdy8x15Ok2N4f) ![img.png](/files/QATmFj6rZkHZ0NZfJGrF) 1. Login to TestFlight and check for the build upload status. Once the build is uploaded successfully, add `Groups` to provide access to testers. ![img.png](/files/4Man8vFrCpEqA73jG354) 2. All the group members will be notified about the new build. Open TestFlight and install the new version. **Publishing build via Github actions (Automation) to TestFlight** An Apple developer account must be configured to Inji app to publish builds via TestFlight. > Testers must be added to group in TestFlight. ![img.png](/files/4Man8vFrCpEqA73jG354) 1. To deploy the iOS build to testflight, select the `Internal Build [Android & IOS]` workflow from github actions, and select `IOS` in the **Build for** option. ![img.png](/files/ROBvf7S6pOfFjgxoYW2p) 2. Choose the branch, backend URL, theme, testers group from TestFlight to get the build and describe about build details. 3. Click the `Run` workflow button. 4. Once the pipeline has done with building the app (takes around \~25-30min), TestFlight notifies corresponding testers associated with the testers group in email about deployed build details. ![img.png](/files/DP8n2FQOLtstAdn8CvAd) # Local Setup This is the docker-compose setup to run mimoto which act as BFF for Inji Wallet and backend for Inji web. This docker compose setup is intended only for local use and not for production deployment. ## What is in the docker-compose folder? * **`certs`** folder holds the p12 file which is created as part of OIDC client onboarding. * **`config`** folder holds the mimoto system properties file, issuer configuration and credential template. * **`docker-compose.yml`** file with the mimoto setup. ## How to run this setup? 1. **Prepare the environment:** * The `docker-compose` folder's `config` directory holds the configuration files Mimoto needs to act as BFF for Inji Wallet. * **Create a `certs` folder** in the `docker-compose` directory and add the OIDC client certificate (see below). * **Update the configuration files:** * `mimoto-issuers-config.json` — add identity providers as issuers. See [Credential Providers](/inji-wallet/inji-mobile/technical-overview/customization-overview/credential_providers) for how to structure each entry. * `mimoto-trusted-verifiers.json` — add the verifiers' clientId, redirect and response URIs, for Verifiable Credential Online Sharing. * Update the **Esignet host** reference in `mimoto-default.properties` (or `application-local.properties` if running Mimoto via IDE). * Set the `oidc_p12_password` environment variable in `docker-compose.yml` to match the password used for `oidckeystore.p12`. * **Create an OIDC client** and generate `oidckeystore.p12`, placed inside the `certs` folder. Follow [Credential Providers](/inji-wallet/inji-mobile/technical-overview/customization-overview/credential_providers) for this process. * **Update `mimoto-issuers-config.json`** with the `client_id` and `client_alias` from your OIDC onboarding. 2. **If you're only running Inji Wallet (mobile), do this before starting the services:** remove the `datashare` and `minio` services from `docker-compose.yml` (and the `datashare` dependency from `mimoto-service`'s `depends_on`), and set `qr_code_type` to `"EmbeddedVC"` for all issuers in `mimoto-issuers-config.json`. This also means you don't need to pull the datashare/minio images at all. 3. **\[Optional] Configure Google OAuth Client Credentials** * Only needed for Mimoto's own "Login with Google" feature — not required to run Inji Wallet locally. `docker-compose.yml` ships with working placeholder values, so this can be skipped for a wallet-only setup. * If you do need it, refer to [How to create Google Client Credentials](#how-to-create-google-client-credentials) below, then add the generated credentials to `docker-compose.yml`: ```yaml environment: - GOOGLE_OAUTH_CLIENT_ID= - GOOGLE_OAUTH_CLIENT_SECRET= ``` 4. **Start the services:** ```bash docker-compose up ``` Use the `-d` flag to run in detached (background) mode. 5. **Stop the services:** ```bash docker-compose down ``` To stop and remove a single service: `docker-compose stop ` then `docker-compose rm `. 6. **Removing the Docker Volume:** if you update `oidckeystore.p12`, Mimoto may fail to start — the new file won't contain the keys already stored in the database's key alias table, and their absence breaks encryption/decryption. Fix it by clearing the stale data: ```bash docker volume rm docker-compose_postgres-data ``` 7. **Access APIs as:** * `http://localhost:8099/v1/mimoto/allProperties` * `http://localhost:8099/v1/mimoto/issuers` * `http://localhost:8099/v1/mimoto/issuers/{issuer-id}` * `http://localhost:8099/v1/mimoto/issuers/{issuer-id}/well-known-proxy` ## How to create Google Client Credentials To enable Google OAuth2.0 authentication, follow these steps: 1. **Go to the Google Cloud Console**: Visit [Google Cloud Console](https://console.cloud.google.com/). 2. **Create a New Project**: If you don't already have a project, create one from the project dropdown. 3. **Enable the OAuth Consent Screen**: "APIs & Services" > "OAuth consent screen". Select "External" and configure the required fields. Save. 4. **Create OAuth 2.0 Credentials**: "APIs & Services" > "Credentials" > "Create Credentials" > "OAuth 2.0 Client IDs" > "Web application". 5. **Authorized JavaScript Origins**: `http://localhost:8099` 6. **Authorized Redirect URIs**: `http://localhost:8099/v1/mimoto/oauth2/callback/google` 7. **Save and Retrieve Client Credentials**: you'll receive a `Client ID` and `Client Secret` — add them to `docker-compose.yml` as shown in step 3 above. ## Inji Mobile Wallet Configuration Set the eSignet host Mimoto should use — update `mosip.esignet.host` in `mimoto-default.properties` (or `application-local.properties` if running Mimoto via IDE) to point to the eSignet instance for your target environment: ```properties mosip.esignet.host= (E.g. https://esignet.env.mosip.net) ``` Then point your local Inji Wallet build at this Mimoto instance — set `MIMOTO_HOST` to your ngrok URL (not `localhost`) in the wallet app's `.env` file (see [Setup → Command to build the application](/inji-wallet/inji-mobile/build-and-deployment#2-command-to-build-the-application)). Note: * For local env use [ngrok](https://ngrok.com/docs/getting-started/). * Replace `http://localhost:8099` by the ngrok public domain at the following places: * `token_endpoint` in `mimoto-issuers-config.json` * `mosipbox.public.url`, `mosip.api.public.url` in `mimoto-default.properties` * After editing `mimoto-issuers-config.json`, restart `nginx` then `mimoto-service` for the change to take effect # Develop This section offers an overview of the architecture and technologies utilized within Inji Wallet, ensuring compatibility, security, and efficiency in the management of Verifiable Credentials. # Standards, Specifications and Compliance ## Inji Wallet Mobile - Standards Implementation ### Overview Inji Mobile is the credential holder wallet for smartphones (iOS/Android). It receives credentials from issuers, stores them securely, and presents them to verifiers in standardized formats. ### Standards Implemented in Mobile *** #### W3C Verifiable Credentials Data Model **Specification**: (See Standards Library for details) **Mobile-Specific Implementation**: * **Credential Reception**: Receive W3C VC 1.1 and v2.0 credentials from OpenID4VCI issuers * **Local Storage**: Encrypted storage of credentials in device secure enclave * **Credential Display**: Render credential claims with issuer-defined templates (SVG in v2.0) * **Offline Access**: Stored credentials accessible without internet connection * **Selective Viewing**: Users can view specific claims without sharing all credential data * **Multi-VC Support**: Store 100s of credentials from multiple issuers *** #### OpenID4VCI (Verifiable Credential Issuance) **Specification**: (See Standards Library for details) **Mobile-Specific Implementation**: * **Credential Request**: Send `/credential` requests to issuer endpoints * **Authorization Headers**: Include OAuth access tokens in credential requests * **Requested Format**: Specify desired credential format (JSON-LD, JWT, SD-JWT) * **Proof of Possession**: Generate proofs (JWTs with app keys) for credential binding * **Batch Download**: Download multiple credentials in single flow * **Wallet Interaction**: Present credential\_offer QR codes to user for acceptance * **Status Tracking**: UI for tracking issuance progress and errors *** #### OpenID4VP (Verifiable Presentations) **Specification**: (See Standards Library for details) **Mobile-Specific Implementation**: * **Presentation Request Parsing**: Receive OpenID4VP presentation requests via QR or deep link * **Credential Matching**: Match holder credentials against verifier claim requirements * **Selective Disclosure**: Present only requested claims (especially important for SD-JWT) * **User Consent**: Explicit user approval before sharing credentials * **Multiple Presentation Modes**: * Cross-device: Scan verifier QR, send presentation back via HTTPS * Same-device: Deep link to verifier app, receive request, return presentation * BLE: Direct Bluetooth connection for offline scenarios * **Signature Generation**: Sign presentation with holder key proof * **Response Transmission**: Send signed VP back to verifier *** #### OpenID4VP-BLE (Offline Presentation) **Specification**: (offline extensions) (See Standards Library for details) **Mobile-Specific Implementation**: * **BLE Pairing**: Pair mobile with verifier via Bluetooth Low Energy * **Direct Communication**: P2P credential presentation without internet * **Offline Verification**: Verifier validates credentials locally using embedded proofs * **Use Cases**: Border control, refugee camps, low-connectivity areas * **Release Timeline**: Available v0.14.0+; expanded with each release *** #### W3C DIDs (Decentralized Identifiers) **Specification**: (See Standards Library for details) **Mobile-Specific Implementation**: * **Issuer DID Resolution**: Resolve issuer DIDs to retrieve public keys for signature validation * **Holder DID Support**: Option to bind credentials to holder DID (self-sovereign identity) * **DID Method Resolution**: Support did:mosip, did:ion, did:key methods * **Trust Anchors**: Anchor verifier trust to verifier DID * **Offline DID Resolution**: Cache resolved DIDs for offline verification *** #### JSON-LD (Linked Data) **Specification**: (See Standards Library for details) **Mobile-Specific Implementation**: * **Semantic Display**: Parse JSON-LD @context to display claims with human-friendly labels * **Language Support**: Multi-language credential display via JSON-LD context * **Linked Data Navigation**: Support for linked data references within credentials * **Context Caching**: Cache JSON-LD contexts for offline access *** #### Selective Disclosure JWT (SD-JWT) **Specification**: (See Standards Library for details) **Mobile-Specific Implementation**: * **Storage**: Store SD-JWT credentials with all salts and hashes * **Selective Presentation**: Generate disclosure tokens for only claims requested by verifier * **Claim Proof**: Provide salts and hashes proving disclosed claims match issuer's hashes * **Privacy**: Undisclosed claims remain private; verifier can't see them * **Release Timeline**: Available v0.10.0+; enhanced with each release *** #### W3C Bitstring Status List **Specification**: (See Standards Library for details) **Mobile-Specific Implementation**: * **Status Checking**: Before presenting, check credential status in issuer's bitstring * **Background Refresh**: Periodically refresh bitstring status in background * **Offline Caching**: Cache bitstring for offline status validation (if available) * **Revoked Credential Handling**: Notify user if credential is revoked; prevent presentation *** #### CBOR (Concise Binary Object Representation) **Specification**: (See Standards Library for details) **Mobile-Specific Implementation**: * **QR Decoding**: Decode CBOR-encoded payloads from Claim 169 QR codes * **Claim 169 Storage**: Store CBOR-encoded QR payloads as part of credentials * **Binary Parsing**: Efficient parsing of compact binary credentials * **Library Integration**: Uses PixelPass library (v0.7.0+) for CBOR decoding *** #### CWT/COSE (CBOR Web Token & Object Signing and Encryption) **Specification**: (See Standards Library for details) **Mobile-Specific Implementation**: * **CWT Signature Verification**: Verify Ed25519 or ECC signatures on CWT tokens * **Claim 169 Validation**: Validate COSE signatures on Claim 169 QR codes * **Embedded Proofs**: Extract and validate signatures embedded in CBOR payloads * **Offline Verification**: Verify signatures without server contact *** #### Claim 169: MOSIP QR Code Specification **Specification**: (See Standards Library for details) **Mobile-Specific Implementation**: * **QR Reception**: Receive Claim 169-encoded QR credentials from issuers * **QR Storage**: Store QR payloads securely in device encrypted storage * **CBOR Parsing**: Decode CBOR-encoded identity attributes * **Multiple QR Support**: Support credentials with multiple QR codes (different contexts) * **QR Display**: Show QR code to verifier for presentation (camera scanning) * **Offline QR Presentation**: Present QR via BLE for offline verification * **Credential Binding**: Link Claim 169 QR to holder identity * **Release Timeline**: Available v0.10.0+; enhanced v0.14.0+ *** #### ISO 18013-5 (Mobile Driver's License) **Specification**: (See Standards Library for details) **Mobile-Specific Implementation**: * **mDL Reception**: Receive ISO 18013-5 mDL credentials from government issuers * **NFC Presentation**: Present mDL via NFC for offline verification in readers * **BLE Presentation**: NFC-less presentation via Bluetooth * **Biometric Binding**: Holder biometric (face) bound to credential * **Selective Disclosure**: Present only fields requested by reader * **Release Timeline**: Available v0.12.0+; enhanced with each release *** #### JWT (JSON Web Token) **Specification**: (See Standards Library for details) **Mobile-Specific Implementation**: * **JWT Storage**: Store JWT-formatted credentials * **Signature Verification**: Verify JWT signatures (HMAC, RSA, ECDSA) * **Token Parsing**: Extract claims from JWT payload * **Presentation**: Present JWT credentials to verifiers via OpenID4VP *** #### Cryptographic Signature Verification **Mobile-Specific Implementation**: | Algorithm | Versions | Status | | --------- | ----------- | ----------------------- | | Ed25519 | 2018 & 2020 | Available (verify only) | | RSA | 2048, 4096 | Available (verify only) | | ECDSA K1 | secp256k1 | Available (verify only) | | ECDSA R1 | P-256 | Available (verify only) | *** # Architecture Inji Wallet is a mobile application designed to enhance user convenience by allowing them to securely download and manage their Verifiable Credentials (VC) offline. The diagram below illustrates the extensive features of Inji Mobile Wallet, highlighting the essential modules involved in issuing Verifiable Credentials. Furthermore, this overview outlines various user flows, detailing the seamless processes users can follow. These processes include downloading VC by utilizing eSignet for authentication, securely activating VC, logging in to eSignet, and effortlessly sharing VCs.

Inji Wallet Architecture

The Inji Mobile Wallet adopts a layered architecture pattern, ensuring clear separation of concerns and robust security for verifiable credentials. Built with React Native, it delivers a seamless, cross-platform experience on both iOS and Android. ### Architecture Layers 1. **Presentation Layer (Green)** * **Component:** Inji Wallet UI (React Native) * **Purpose:** Renders the user interface and manages application state using xState. * **Features:** Cross-platform UI, declarative state management, user interaction handling. 2. **Communication Bridge Layer (Yellow)** * **Component:** React Native Bridge * **Purpose:** Enables communication between JavaScript and native code (Java, Kotlin, Swift). * **Functionality:** Accesses native platform features from React Native. 3. **Native Platform Layer (Orange)** * **Components:** Android Native Modules (Kotlin), iOS Native Modules (Swift), External Modules * **Purpose:** Handles platform-specific operations and SDK integrations. 4. **Device Hardware & API Layer (Blue)** * **Component:** Device APIs & SDKs (Camera, Bluetooth, etc.) * **Purpose:** Interfaces with device hardware and system APIs for features like camera access and BLE communication. 5. **Backend Services Layer (Purple)** * **Component:** Mimoto (Backend for Frontend) * **Purpose:** Orchestrates API calls, formats data, and manages authentication between the app and backend services. ### Detailed Component Breakdown #### React Native Application Components * **UI Screens & Components:** User interface elements and screens. * **State & Context:** Application state management with context providers. * **API Communication:** Uses React Native Fetch for backend requests. * **Local Storage:** MMKV for high-performance key-value storage and local caching. #### Native Modules * **Secure Keystore:** Manages cryptographic keys and secure storage. * **VCI Client:** Handles verifiable credential issuance. * **VC Verifier:** Validates and verifies credentials. * **Pixelpass:** Renders and displays credentials securely. * **OpenId4VP:** Implements OpenID for Verifiable Presentations. * **Tuvali:** Enables BLE-based peer-to-peer credential sharing. #### External Modules * **Face Match SDK:** Provides biometric authentication and face matching. ### Data Flow & Component Interactions * **Vertical Flow:**\ User Input → UI Screens → State Management → API Calls → Data Persistence (MMKV/Cache) → Native Operations → Hardware Access * **Horizontal Integrations:** * **Backend Communication:** Mimoto (BFF) * **Security:** Secure Keystore * **Credential Management:** VCI Client, VC Verifier * **Peer-to-Peer Sharing:** Tuvali (BLE) * **Biometric Security:** Face Match SDK ### Key Architectural Principles * **Layered Separation:** Distinct boundaries between UI, business logic, and data. * **Cross-Platform Compatibility:** Single codebase for iOS and Android. * **Security-First Design:** Hardware-backed keystore and biometric integration. * **Modular Architecture:** Independent native modules for extensibility. * **Standards Compliance:** OpenID4VP and W3C Verifiable Credentials. * **Performance Optimization:** MMKV storage and local caching. ### Technology Stack Summary * **Frontend:** React Native, xState * **State Management:** xState * **Storage:** MMKV * **Native Development:** Kotlin (Android), Swift (iOS) * **Communication:** BLE (Tuvali), HTTP (REST APIs) * **Security:** Secure keystore, biometric authentication * **Standards:** OpenID4VP, W3C Verifiable Credentials This architecture ensures scalability, security, and maintainability, delivering a seamless digital credential management experience. # Technical Stack ## Wallet Application The following table summarizes the main technologies, tools, and frameworks used to build the Inji Wallet application: | Tool / Technology | Version | Description | License | | --------------------------------------------- | -------------------------------------------- | ------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------ | | [React Native](https://reactnative.dev/) | 0.74.5 | JavaScript framework for building native mobile apps using React. | [MIT License](https://github.com/facebook/react/blob/main/LICENSE) | | [TypeScript](https://www.typescriptlang.org/) | 5.3.3 | Strongly typed language that builds on JavaScript, enabling static type checking and improved tooling. | [Apache-2.0 License](https://www.apache.org/licenses/LICENSE-2.0) | | [Jest](https://jestjs.io/docs/tutorial-react) | 29.7.0 | JavaScript testing framework, commonly used for React applications. | [MIT License](https://github.com/facebook/react/blob/main/LICENSE) | | [Android](https://developer.android.com/) | minSDk - 24, compileSDK - 34, targetSDK - 34 | Mobile OS based on Linux kernel, used for building and running the app on Android devices. | | | [iOS](https://developer.apple.com/ios/) | 26+ | Mobile OS developed by Apple for its devices. Swift is used for iOS development. | | | [Xcode](https://developer.apple.com/xcode/) | 26+ | Apple IDE and toolchain required to build and run the iOS app. | | ## Native Libraries The following table lists the technologies, tools, and frameworks used for building native libraries: | Tool / Technology | Version | Description | License | | ----------------------------------------- | ----------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------- | ------- | | [Kotlin](https://kotlinlang.org/) |

2.0.0
Java 17

| Modern statically typed programming language. | | | [Android](https://developer.android.com/) | minSDk 23 compileSDK 34 | Mobile OS based on a modified Linux kernel and open-source software, designed for touchscreen devices. Used to build the app for Android devices. | | | [iOS](https://developer.apple.com/ios/) | 14 | Mobile OS developed by Apple for smartphones. Swift is used for iOS development. | | # Components Inji Wallet utilizes multiple libraries to provide a seamless experience. These library are accessible as AAR for Android app and SPM(Swift Package Manager) for iOS App. Android libraries are written in Kotlin and can be easily integrated with cross platform applications like React Native or Flutter. This helps with seamless integration with other mobile wallets. The libraries are as follows: 1. Secure Keystore SDK 2. VCI Client SDK 3. PixelPass SDK 4. Tuvali - Sharing via BLE SDK 5. OpenID4VP - Online Sharing SDK 6. Face Match SDK 7. Telemetry SDK(coming soon)
### **1. Tuvali - Sharing via BLE SDK** * This library facilitates the transfer of downloaded Verifiable Credential from the Wallet to Verifier. * Tuvali enables offline VC transfer between mobile devices via Bluetooth Low Energy (BLE). The below table represents the supported roles for Android and iOS devices.
WalletVerifierVC transfer support
AndroidAndroidYes
iOSAndroidYes
AndroidiOSNo
iOSiOSNo
* Tuvali is actively developed and maintained by MOSIP. * [Kotlin Implementation](https://github.com/mosip/tuvali) * [Swift Implementation](https://github.com/mosip/tuvali-ios-swift) * It does not support iOS for initiating the BLE exchanges, hence preventing two iOS devices from transferring VC. {% hint style="info" %} Note: * To learn more about Tuvali's implementation, refer [here](https://docs.mosip.io/inji/integration-guide/tuvali). * For information on Tuvali's permissions and requirements, refer [here](https://docs.mosip.io/inji/integration-guide/tuvali/tuvali-requirements). * To understand Tuvali and Inji Wallet integration, along with API documentation, refer[ here](https://docs.mosip.io/inji/integration-guide/tuvali/tuvali-inji). * Maven snapshots are available [here](https://central.sonatype.com/artifact/io.mosip/tuvali) {% endhint %} ### **2. Face Match SDK** The face matcher SDK internally implements native functionalities for Android and iOS, utilizing [Tensorflow](https://www.tensorflow.org/) and [Google ML Kit](https://developers.google.com/ml-kit) to identify faces. This SDK internally employs a `tflite` model, which is now bundled within the app. The face matcher functionality is also available via the [iriscan/biometric-sdk-react-native](https://www.npmjs.com/package/@iriscan/biometric-sdk-react-native) NPM module, which is already integrated for offline face authentication in Inji Wallet. The SDK is employed in two scenarios: **During Both Offline and Online VC Sharing**: Residents can perform selfie authentication before sharing the VC with the relying party. The app opens the camera, allowing residents to take a selfie, which is then validated against the VC image to verify the resident's presence. This process is supported for both offline VC sharing (e.g., via BLE) and online login (e.g., scanning a QR code from the relying party portal and logging in using Inji Wallet). Refer [here](/inji-wallet/inji-mobile/technical-overview/integration-guide/building-verifiable-credentials-wallet-with-inji-libraries/face-match) to check the API specifications for the face matcher model. ### **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: * **For Android**: Refer to the [secure-keystore Kotlin library](https://github.com/mosip/secure-keystore). * **For iOS**: Refer to the [secure-keystore-iOS Swift library](https://github.com/mosip/secure-keystore-ios-swift). Inji Wallet integrates with the secure-keystore library to ensure secure key management. To optimize the key size during credential download requests, Inji Wallet uses RSA-2048, ECR1, ECK1, ED25519 keys. To check all the APIs supported by this module, refer [here](https://github.com/mosip/documentation/blob/inji/docs/technical-overview/components.md). {% hint style="info" %} **Note:** * Compatible with devices that support a hardware keystore. * To understand the library and access API documentation, refer [here](/inji-wallet/inji-mobile/technical-overview/integration-guide/building-verifiable-credentials-wallet-with-inji-libraries/secure-keystore). * Maven snapshots are available [here](https://central.sonatype.com/artifact/io.mosip/secure-keystore). {% endhint %} ### **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. Additionally, for a JSON data, the library employs CBOR encoding and decoding to minimize the size even further. When a JSON Mapper similar to [Claim 169](https://docs.mosip.io/1.2.0/overview/standards-and-specifications/169-qr-code-specification) is provided, PixelPass maps the data, applies CBOR encoding/decoding, and compresses the data, achieving maximum size reduction. Developed and maintained by MOSIP, PixelPass is continually updated to provide reliable and efficient QR code generation and decoding capabilities. {% hint style="info" %} Note: * Refer to the PixelPass repository * [Kotlin Implementation](https://github.com/mosip/pixelpass/tree/master/kotlin) * [JS Implementation](https://github.com/mosip/pixelpass/tree/master/js) * [Swift Implementation](https://github.com/mosip/pixelpass-ios-swift) * To understand about the installation and the API documentation, refer [here](/inji-wallet/inji-mobile/technical-overview/integration-guide/building-verifiable-credentials-wallet-with-inji-libraries/pixelpass). * For a hands-on experience of Generate a VC, Generate QR Code for the VC and Verify the same using Inji Verify, please click [here](https://docs.inji.io/inji-verify/build-and-deploy/creating-verifiable-credentials-and-generating-qr-codes). * To check the NPM module, click[ here](https://www.npmjs.com/package/@mosip/pixelpass). * Maven snapshots are available \[here] * [For Android](https://central.sonatype.com/artifact/io.mosip/pixelpass-aar) * [For Java](https://central.sonatype.com/artifact/io.mosip/pixelpass-jar) {% endhint %} ### **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. {% hint style="info" %} Note: * Refer to the VCI-Client repository * [Kotlin Implementation](https://github.com/mosip/inji-vci-client) * [Swift Implementation](https://github.com/mosip/inji-vci-client-ios-swift) * To understand about the installation and the API documentation, refer [here](https://docs.mosip.io/inji/inji-mobile-wallet/integration-guide/vci-client). * Maven snapshots are available [here](https://central.sonatype.com/artifact/io.mosip/inji-vci-client) {% endhint %} ### **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. Validates the received Authorization Request to check if the required details are present or not and then returns the Authorization Request to the consumer application once all the validations are successful. 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. {% hint style="info" %} Note: * Refer to the inji-openid4vp repository * [Kotlin Repository](https://github.com/mosip/inji-openid4vp) * [Swift Repository](https://github.com/mosip/inji-openid4vp-ios-swift) * To understand about the installation and the API documentation, refer [here](https://docs.mosip.io/inji/inji-wallet/inji-mobile/technical-overview/integration-guide/openid4vp). * Maven snapshots are available [here](https://central.sonatype.com/artifact/io.mosip/inji-openid4vp) * Currently, the `vp_token` uses the `Ed25519Signature2020` type for digital signatures. {% endhint %} ### **7. Telemetry SDK** The [telemetry](https://github.com/mosip/sunbird-telemetry-sdk) module is derived from the [sunbird telemetry](https://github.com/project-sunbird/sunbird-telemetry-sdk) module. It is responsible for generating events that can provide valuable analytics. ***Note***: *The publication of this project is currently a work in progress and has not been released yet. Stay tuned for further announcements!* > To know more about each of these, refer [Integration Guides](/inji-wallet/inji-mobile/technical-overview/integration-guide). # Integration Guides This section provides guidelines and specifications for integrating any software development kit (SDK) with **Inji Wallet**. It also contains references to available SDKs and tools that developers, system integrators, relying parties, and end users may find useful. ### SDK Integration Specifications To ensure seamless integration with **Inji Wallet**, SDKs must follow these requirements: * **Availability** * The SDK should be published as an **npm module** for integration with React Native applications. * For **Android**, integration must be supported via a **Maven dependency**. * For **iOS**, integration must be supported via **Swift Package Manager (SPM)**. For example, the npm modules [**tuvali**](https://www.npmjs.com/package/@mosip/tuvali) and [**secure-keystore**](https://www.npmjs.com/package/@mosip/secure-keystore) demonstrate suitable implementations. * **API Design** * Provide a simple API surface for easy integration. * Must include an **initialization API** (e.g., `init` or a constructor API). * Include all necessary functional APIs to perform core actions. * Provide a **disconnect API** to safely detach the SDK when needed. * Preferably design APIs to be **asynchronous**, allowing users to continue app usage without UI blocking. * **Traceability & Logging** * APIs may optionally accept a parameter such as `traceabilityId` to enhance logging and request traceability. ### **Build Your Own Wallet with Inji Libraries** Use Inji’s modular SDKs and libraries to assemble a wallet tailored to your needs. Each library provides specific capabilities that can be integrated into your application. Build your own wallet using Inji libraries – click [here](/inji-wallet/inji-mobile/technical-overview/integration-guide/building-verifiable-credentials-wallet-with-inji-libraries)! **List of Libraries and SDKs** * [**VCI Client Library**](/inji-wallet/inji-mobile/technical-overview/architecture) – Issue and download Verifiable Credentials (VCs). * [**PixelPass Library**](/inji-wallet/inji-mobile/technical-overview/architecture) – Compress, encode, and decode JSON for QR codes. * [**OpenID4VP Library**](/inji-wallet/inji-mobile/technical-overview/architecture) – Enable credential sharing through OpenID4VP protocols. * [**BLE Verifier Library** ](/inji-wallet/inji-mobile/technical-overview/architecture)– Verify VCs received over Bluetooth. * [**Tuvali Library** ](/inji-wallet/inji-mobile/technical-overview/architecture)**(BLE Sharing)** – Share credentials offline via Bluetooth Low Energy. * [**Secure Keystore Library** ](/inji-wallet/inji-mobile/technical-overview/architecture)– Manage secure storage of keys and sensitive data. * [**Face Match SDK** ](/inji-wallet/inji-mobile/technical-overview/architecture)– Add biometric face matching for enhanced verification. * [**Telemetry**](/inji-wallet/inji-mobile/technical-overview/architecture) – (Details coming soon!) for monitoring and analytics. # Building Verifiable Credentials Wallet with Inji Libraries ## Overview This guide provides step-by-step documentation for building a **Kotlin-based verifiable credential wallet** from scratch using **Inji stack libraries**. The purpose of this guide is to demonstrate how developers can leverage the Inji ecosystem to securely **download, verify, store, and present verifiable credentials (VCs)**. The guide is currently focused on **Android-based implementations**, but all the Inji libraries are also available in **Swift for iOS**. This guide is aimed at developers who want to either **create a custom wallet** or **enhance an existing application** to support VC-based digital identity functionality. The sample app illustrates how to: * Securely generate and manage cryptographic keys * Download credentials from trusted issuers * Verify the authenticity of credentials * Store and display credentials to end users * Optionally present credentials via QR code {% hint style="success" %} **Note:**\ The terms **“custom wallet”** and **“verifiable credentials wallet”** are used interchangeably throughout this document. Both refer to a wallet application built using Inji libraries to securely **download, verify, store, and present verifiable credentials (VCs)**. {% endhint %} ### Key Features of the Custom Wallet By following this “build your own digital credentials wallet” flow, your application achieves: * **Secure Key Management** * Hardware-backed RS256/ES256 keys, safely managed by Secure Keystore. * **End-to-End Credential Issuance** * Complete flow from user authentication to credential download. * **Credential Verification** * Ensures authenticity with cryptographic checks and expiry validation. * **Secure Storage & Display** * Verified credentials are saved in the app and rendered as cards for users. * **Issuer Management** * Supports multiple trusted issuers and their metadata. * **Credential Presentation** * Option to present credentials via QR code (Pixelpass). * **Extensible Architecture** * Modular libraries allow developers to extend or replace parts of the flow. **For the detailed feature list of Inji Mobile Wallet, refer** [**here**](https://docs.inji.io/inji-wallet/inji-mobile/overview/features) **!** ### Prerequisites for Building a Custom Wallet Before starting, ensure you have: * **Android Studio** (latest stable version) * **Kotlin** (with Gradle support) * **Internet access** for API calls to the Authorization Server and Issuing Authority * **Trusted Issuer configuration** (issuer metadata like `client_id`, `credential_configuration_id`, `redirect_uri`, etc.) ### Inji Libraries Used for Building a Custom Wallet The custom wallet application integrates several **Inji stack libraries**, which provide ready-made methods for credential flows. | Component | Library | Primary Function | | ------------------------------- | ----------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Secure Keystore** | [secure-keystore](https://github.com/mosip/secure-keystore/tree/master) | Generates and stores cryptographic key pairs (RS256 / ES256). Used to create Proof JWT. | | **VCI Client** | [inji-vci-client](https://github.com/mosip/inji-vci-client) | Handles the credential issuance protocol: authorization, token exchange, proof generation, and downloading the credential. | | **VC Verifier** | [vc-verifier](https://github.com/mosip/vc-verifier) | Verifies credentials by checking digital signatures, expiration, and issuer authenticity. | | **Pixelpass** (optional) | [pixelpass](https://github.com/mosip/pixelpass/tree/master) | Generates QR codes for credential presentation. | | **Issuing Authority (Certify)** | [inji-certify](https://github.com/mosip/inji-certify) | Authority from which the final credential (VC) is issued and downloaded. | | **Authorization Server (AS)** | (External) | Service where users authenticate to get authorization codes. In case of Inji eSignet can also be used as authorization server as it is a MOSIP product so both are compatible. | ### Setup 1. **Create Activity** * In Android Studio, create a new project with an empty activity. 2. **Add Dependencies** * Open `app/build.gradle` and add the required dependencies for the Inji libraries: `implementation "org.inji:inji-actor-secure-keystore:" implementation "org.inji:inji-vci-client:" implementation "org.inji:inji-vc-verifier:" implementation "org.inji:inji-pixelpass:" // optional` 3. **Resolve Dependencies** * Sync the project to fetch dependencies. * You can now call the methods provided by the Inji libraries. ### **Step-by-step guide:** The flow below shows how the custom verifiable credentials wallet downloads and verifies a credential.
#### Step 1: Initialization & Key Generation * Call `generate_key_pair()` from **Secure Keystore**. * Generates RS256 or ES256 key pair, stored in Android hardware keystore. * Retrieve **issuer metadata** (`client_id`, `redirect_uri`, etc.) from trusted issuers list. * Call `request_credential_from_trusted_issuer()` in **VCI Client** , passing credential configuration and client metadata. #### Step 2: User Authorization * **VCI Client** returns a callback requiring user authorization. * Wallet opens a web-view to the **Authorization Server**. * User authenticates, and an **authorization code** is returned to the wallet. * Wallet sends the authorization code to the **VCI Client**, fulfilling the callback. #### Step 3: Token Exchange * VCI Client triggers `get_token_response` callback. * Wallet makes a **POST request** to the token endpoint with auth code. * **Authorization Server** responds with an access token + `cNonce`. * Wallet returns a token response to the **VCI Client**. #### Step 4: Proof Generation & Credential Download * VCI Client requests a Proof JWT (`get_proof_JWT`). * Wallet constructs JWT with claims: `nonce`, `aud`, `iat`, `exp`. * Wallet uses **Secure Keystore** to sign JWT. * Wallet sends signed Proof JWT to **VCI Client**. * **VCI Client** requests credentials from **Issuing Authority** and returns the final credential JSON. #### Step 5: Verification & Storage * Wallet calls `verify()` from **VC Verifier 🔎**, passing credential JSON. * **VC Verifier** checks validity (signature, expiry, issuer). * Verification result returned (`True/False` with message). * If valid, the wallet stores credentials and renders as a card view. #### Optional Step: Credential Presentation * Wallet calls **Pixelpass** to generate QR code. * Pixelpass returns a QR image for displaying to the verifier. {% hint style="success" %} Using **Inji libraries and SDKs**, which are built on open standards, developers can build their own custom wallets or integrate these libraries into existing applications, effectively transforming them into **VC-based wallets**.\\ {% endhint %} # OpenID4VCI Library (VCI Client) ## Verifiable Credentials Issuance (VCI Client) VCI Client library enables carrying out the credential request from the consumer application (mobile wallet or web) and downloading the VC. ## Features: * Request credentials from OID4VCI-compliant credential issuers * Supports both the Verifiable Credential download flows defined in the OID4VCI specification: * Issuer Initiated Flow (Credential Offer Flow). * Wallet-initiated flow (Trusted Issuer Flow). * Authorization server discovery for both download flows * PKCE-compliant OAuth 2.0 Authorization Code flow (RFC 7636) * PKCE session is managed internally by the library * Well-defined exception handling with VCI-XXX error codes (see more on this) * Support for multiple Credential formats: * ldp\_vc * mso\_mdoc * vc+sd-jwt / dc+sd-jwt * Presentation During Issuance (PDI) support for both download flows > ⚠️ Consumer of this library is responsible for processing and rendering the credential after it is downloaded. * Kotlin and Swift artifacts are available to integrate with the native mobile applications. The section details the steps for integrating the Kotlin and Swift packages into the app. ## Kotlin package for vci-client: ### Repository * inji-vci-client repo is [here](https://github.com/inji/inji-vci-client) ### Supported platforms * Android (via aar) * JVM (via jar) ### Installation Snapshot builds are available [here](https://central.sonatype.com/artifact/io.inji/inji-vci-client-aar). {% hint style="info" %} Note: implementation "io.inji:inji-vci-client:0.7.0" {% endhint %} ## iOS: Swift package for vci-client: ### Repository * [inji-vci-client-ios-swift repository](https://github.com/inji/inji-vci-client-ios-swift/) ### Installation Add VCIClient to your Swift Package Manager dependencies: ```shell .package(url: "https://github.com/inji/inji-vci-client-ios", from: "0.7.0") ``` ## APIs The library provides the following APIs for credential issuance: | Use Case | Method Name | Description | | --------------------------------------- | ---------------------------------------- | --------------------------------------------------------------- | | **Obtain Issuer Metadata** | `getIssuerMetadata()` | Retrieve issuer metadata from well-known endpoint | | **Get Supported Credentials** | `getCredentialConfigurationsSupported()` | Get supported credential configurations from issuer | | **Fetch Credential (Credential Offer)** | `fetchCredentialUsingCredentialOffer()` | Request credential using credential offer (Pre-Auth/Auth flows) | | **Fetch Credential (Trusted Issuer)** | `fetchCredentialFromTrustedIssuer()` | Request credential from a trusted issuer (Auth flow) | > **Note:** For detailed API documentation including parameters, return types, and usage examples, refer to the [Kotlin API Reference](https://github.com/inji/inji-vci-client/tree/master/kotlin#-api-overview) or [Swift implementation documentation](https://github.com/inji/inji-vci-client-ios-swift/tree/master/#-api-overview). ### VCI-Client and Inji Wallet integration: The diagram below shows how Inji Wallet utilises the vci-client library.
# OpenID4VP Library ## Verifiable Presentation - Online Sharing This library is for **wallet-side** processing of [OpenID for Verifiable Presentations](https://openid.net/specs/openid-4-verifiable-presentations-1_0.html) (OpenID4VP). This library validates incoming authorization requests, helps build Verifiable Presentations (with signing delegated to your app), and sends responses to the verifier. **Key Responsibilities:** * **OpenID4VP Library** * Handles OpenID4VP protocol workflows and compliance * Simplifies Verifiable Presentation creation and response exchange * Reduces development complexity and integration time * **Library Consumer App** * Owns user consent and credential selection * Performs secure cryptographic signing Build OpenID4VP capabilities faster with a library designed to remove protocol complexity, reduce implementation risk, and accelerate your journey toward interoperable digital credentials. ## Supported features ### Feature Matrix by Specification Version **Legend:** ✅ = Supported | ❌ = Not Implemented | N/A = Not Applicable | Feature | Draft 23 | Version 1.0 | Notes | | --------------------------------------------- | :-------: | :---------: | ------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Device Flow** | | | | | Cross device flow | ✅ | ✅ | Wallet scans QR code and passes data to this library | | Same device flow | ✅ | ✅ | Wallet receives VP request via deeplink | | **Client ID Prefix** | | | Equivalent to Client ID Scheme in draft 23 | | pre-registered | ✅ | ✅ | Validated via `WalletConfig.trustedVerifiers` | | redirect\_uri | ✅ | ✅ | | | decentralized\_identifier | ✅ (`did`) | ✅ | | | **Authorization Request Delivery** | | | Per [RFC 9101](https://www.rfc-editor.org/info/rfc9101/#name-authorization-request) | | By value (signed request) | ✅ | ✅ | | | By value (unsigned request) | ✅ | ✅ | Via URL-encoded parameters | | By reference (request\_uri) | ✅ | ✅ | Fetched via HTTP GET/POST | | Request signing algorithms | ✅ | ✅ | Ed25519 | | **Presentation Request** | | | | | DCQL Query | ❌ | ✅ | | | Presentation Definition | ✅ | ❌ | By value or via `presentation_definition_uri` | | Scope parameter | ❌ | ❌ | Not implemented | | **VP Response Modes** | | | | | direct\_post | ✅ | ✅ | | | direct\_post.jwt | ✅ | ✅ | Unsigned and Encrypted response | | iar-post / iae\_post | ✅ | ✅ | | | iar-post.jwt / iae\_post.jwt | ✅ | ✅ | Unsigned and Encrypted response | | **VP Response Type** | | | | | vp\_token | ✅ | ✅ | | | vp\_token id\_token | ❌ | ❌ | Not implemented | | code | ❌ | ❌ | Not implemented | | **Authorization Response Encryption** | | | For `direct_post.jwt` and `iar-post.jwt` / `iae_post.jwt` modes | | Encryption algorithm (content) | ✅ | ✅ | A256GCM | | Key agreement algorithm | ✅ | ✅ | ECDH-ES | | **VP Token Generation** | | | | | DCQL Query-based | ❌ | ✅ | | | Presentation Definition-based | ✅ | ❌ | | | Error responses | ✅ | ✅ | Any failure during VP request validation / user consent rejection / VP response preparation is prepared as Authorization Error response and sent to Verifier | | **Supported Verifiable Presentation Formats** | | | | | ldp\_vp | ✅ | ✅ | | | mso\_mdoc | ✅ | ✅ | | | vc+sd-jwt / dc+sd-jwt | ✅ | ✅ | | ## Platform & Library Support This library is available in Kotlin and Swift, supporting Android, JVM and iOS platforms. * **Kotlin**: [Android (AAR) & JVM (JAR)](https://github.com/inji/inji-openid4vp/tree/master/kotlin) * **Swift**: [iOS](https://github.com/inji/inji-openid4vp-ios-swift) ### Core Methods The library provides the following methods organized into different workflow patterns: #### Primary Flow Methods | Method | Purpose | | -------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------ | | **`authenticateVerifier()`** | Validates incoming authorization requests from verifiers. Resolves request objects, verifies signatures, and returns a structured request. | | **`getMatchingCredentials()`** | *(DCQL Helper)* Evaluates DCQL queries against your wallet's credentials to determine which satisfy the verifier's requirements. | | **`constructUnsignedVPToken()`** | Prepares VP tokens based on selected credentials. Returns unsigned data that your wallet must sign. | #### Response Submission: Two Patterns Available **Option 1: Construct & Send (Recommended)** — SDK handles VP Response submission | Method | Purpose | | -------------------------------- | -------------------------------------------------------------------------------------------------------- | | **`sendVPResponseToVerifier()`** | Assembles signed VP tokens into an OpenID4VP response **and submits it** to the verifier. | | **`sendErrorInfoToVerifier()`** | Constructs and sends error/rejection responses to the verifier (e.g., user denial, validation failures). | **Option 2: Construct Only (Advanced)** : You handle VP Response submission yourself | Method | Purpose | | --------------------------- | ------------------------------------------------------------------------------------ | | **`constructVPResponse()`** | Constructs the VP response **without sending**. You handle VP Response submission. | | **`constructErrorInfo()`** | Constructs an error response **without sending**. You handle VP Response submission. | > **For detailed API reference including parameters, response structures, examples, and exceptions, refer to the** [**Kotlin API Reference**](https://github.com/inji/inji-openid4vp/tree/master/docs/integration-guide.md) **or** [**Swift API Reference**](https://github.com/inji/inji-openid4vp-ios-swift/docs/integration-guide.md) **accordingly.** #### OpenID4VP library and Wallet integration: The below diagram shows the interactions between Wallet, Verifier and OpenID4VP library. ```mermaid sequenceDiagram participant Verifier as 🔍 Verifier participant Wallet as 📱 Wallet participant Library as 📚 OpenID4VP Library Note over Verifier: Generate QR Code with
Authorization Request Wallet -->> Verifier: Scan QR Code Wallet -->> Library: Forward Authorization Request activate Library Note over Library: Validate Request against:
1. Client ID
2. Response URI
3. Trusted Verifiers Note over Library: Validate Required Fields
and Values deactivate Library Library-->>Wallet: Return Validated Authorization activate Wallet Note over Wallet: Display Matching VCs
to User deactivate Wallet Wallet-->>Library: Send Selected VCs
with User Consent Library-->>Library: Construct VP Token Library-->>Wallet: Return the unsigned VP Token activate Wallet Note over Wallet: Sign VP Token deactivate Wallet Wallet-->>Library: Send Signed data activate Library Note over Library: Create Verifiable Presentation Note over Library: Populate VP response deactivate Library Library-->>Verifier: HTTP POST Request with: VP Response ``` # PixelPass Library ## 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. ### Availability PixelPass is available across multiple platforms and programming languages, making it accessible for diverse development environments: * [**Node.js/JavaScript**](https://github.com/inji/pixelpass/tree/master/js): Available as an NPM package for web and Node.js applications * [**Kotlin/Android**](https://github.com/inji/pixelpass/tree/master/kotlin): Published as an AAR (Android Archive) library for native Android development * [**Java**](https://github.com/inji/pixelpass/tree/master/kotlin): Available as a JAR (Java Archive) for Java backend applications * [**Swift/iOS**](https://github.com/inji/pixelpass-ios-swift): Available as a Swift package for native iOS development ### Features PixelPass provides essential features for efficient data encoding and QR code generation: * 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. * Supports multiple output formats including base64-encoded PNG images and base45-encoded strings. * Provides comprehensive error handling for robust data processing. ### APIs Overview PixelPass exposes six primary APIs for different use cases: * **generateQRCode**: Creates a visual QR code (base64 PNG) from compressed and encoded data * **generateQRData**: Produces base45-encoded strings suitable for raw data transfer * **decode**: Reverses the encoding process to retrieve original JSON from base45 strings * **decodeBinary**: Decompresses binary zip data * **getMappedData**: Transforms JSON using a mapper and applies optional CBOR encoding for reduced size * **decodeMappedData**: Reverses mapped and encoded data back to original JSON structure * **toJson(base64UrlEncodedCborEncodedString: String)**: Decodes base64 URL-encoded CBOR data and converts it into its JSON structure. These APIs support multiple compression and encoding strategies, allowing developers to choose the approach that best fits their credential sharing scenarios. > **Note**: For comprehensive API documentation and detailed usage examples, refer to the API sections in the respective repositories: > > * [JavaScript/Node.js API Guide](https://github.com/inji/pixelpass/tree/master/js#apis) > * [Kotlin/Android API Guide/Java API Guide](https://github.com/inji/pixelpass/blob/master/kotlin/Readme.md#apis) > * [Swift/iOS API Guide](https://github.com/inji/pixelpass-ios-swift#api-reference) ## Use Cases ### 1. Sharing Credentials as QR Codes Credential sharing as QR codes is a core use case that leverages the PixelPass library. A Wallet application encodes credential data using `pixelPass.generateQRData(data, header)` into a QR code, which can then be shared with or scanned by a Verifier application. The Verifier uses PixelPass to decode and validate the credential data. This use case is available within the Inji Ecosystem with the following components: * **Wallet**: Inji Wallet * **Verifier**: Inji Verify * **Issuer**: Inji Certify * **Applicable Credential Formats**: * ldp\_vc **User Flow** 1. User downloads a credential from Inji Certify via Inji Wallet 2. User opens the credential detail view, which displays a QR code 3. User opens Inji Verify and chooses to scan or upload the credential QR code: * **Scan Option**: Select the "Scan QR Code" tab and allow Inji Verify to scan the QR code using the device camera * **Upload Option**: Select the "Upload QR Code" tab and upload the QR code image downloaded from Inji Wallet 4. After scanning or uploading, Inji Verify decodes the QR data, validates the credential, and displays it in the UI **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.
For more details on this use case, refer to the [detailed guide](/inji-verify/build-and-deploy/creating-verifiable-credentials-and-generating-qr-codes). ### 2. Displaying mDoc Credential Data For credentials in the `mso_mdoc` format, the Issuer provides credentials as base64 URL-encoded CBOR data. Wallet applications can use the `toJson(base64UrlEncodedCborEncodedString)` API to convert the CBOR data to JSON format for display in the UI. This use case is available within the Inji Ecosystem with the following components: * **Wallet**: Inji Wallet * **Issuer**: Inji Certify **User Flow** 1. User downloads a Mobile Driving License from Inji Certify via Inji Wallet 2. User opens the credential detail view where the mDoc data is displayed in a readable format *** # Inji VC Renderer Library ### Overview Inji VC Renderer is a library designed to render Verifiable Credentials (VCs) by converting SVG templates into visual SVG images. The library dynamically replaces placeholders in SVG templates with actual Verifiable Credential JSON data, strictly following the JSON Pointer Algorithm (RFC6901) for value extraction. **Key Responsibilities:** * **VC Rendering Library** * Downloads SVG templates from the VC's render method * Replaces template placeholders with actual VC data * Supports multiple rendering methods and generates visual credential displays * Follows JSON Pointer Algorithm (RFC6901) for accurate data extraction * **Library Consumer App** * Provides the Verifiable Credential data * Handles the display of credentials ### Supported Features #### Core Capabilities * **SVG Template Processing**: Downloads SVG templates from URLs specified in the VC render method * **Dynamic Placeholder Replacement**: Replaces Mustache-style placeholders with actual VC data using JSON Pointer Algorithm (RFC6901) * **VC Data Model 2.0 Support**: Compatible with the latest Verifiable Credential specification * **QR Code Embedding**: Optionally embeds QR codes within SVG templates for credential verification #### Supported Credential Formats Currently supported credential format: * **ldp\_vc** - Linked Data Proofs Verifiable Credentials ### Libraries Available In Inji VC Renderer is available in Kotlin and Swift, supporting Android, JVM and iOS platforms. * **Kotlin**: [Android (AAR) & JVM (JAR)](https://github.com/inji/inji-vc-renderer/tree/master/kotlin) * **Swift**: [iOS](https://github.com/inji/inji-vc-renderer-ios-swift/tree/master) #### Core Methods The library provides a primary API for rendering credential display content: **`generateCredentialDisplayContent()`** Converts a Verifiable Credential into visual SVG representation by processing render methods and replacing template placeholders. **Parameters:** * `credentialFormat` - Enum specifying the credential format (currently supports `ldp_vc`) * `vcJsonString` - The Verifiable Credential in stringified JSON format * `wellKnownJson` (Optional) - Well-known metadata in stringified JSON format * `qrCodeData` (Optional) - Custom data for QR code generation. If provided, QR code is generated using this value; if not provided or empty, the full VC JSON string is used as fallback. **Note**: `qrCodeData` should be pre-encoded (e.g., Base45-encoded) **Returns:** * List of rendered SVG templates as strings * Multiple SVG templates are returned if multiple render methods are present in the VC > **For comprehensive API documentation and detailed usage examples, refer to the respective repository documentation:** > > * [Kotlin/Java Repository](https://github.com/inji/inji-vc-renderer/tree/master/kotlin#api) > * [Swift/iOS Repository](https://github.com/inji/inji-vc-renderer-ios-swift/tree/master#api) #### Rendering Process Flow The library follows these steps to render credential display content: 1. **Render Method Extraction** - Extracts render method information from the VC JSON 2. **SVG Template Download** - Downloads the SVG template from the URL specified in the render method 3. **Placeholder Replacement** - Uses JSON Pointer Algorithm (RFC6901) to extract values from VC JSON and replace placeholders in the SVG 4. **QR Code Generation** - Optionally generates and embeds a QR code (if `qrCodeData` is provided) 5. **Output Generation** - Returns the fully rendered SVG as a string If multiple render methods exist in the VC, this process is repeated for each, and all rendered SVGs are returned as a list. *** > Refer to the Inji Certify documentation for details on issuing credentials with SVG Rendering Support and the corresponding credential structure. # BLE Verifier Library * This is the module built for verifiers to receive VC via BLE. This is a wrapper built on Tuvali with simplified APIs. ## Repository {% embed url="" %} ## Installation * Add a dependency in package.json * Publishing npm module is WIP. Once it's published, it can be integrated as any other npm module. ## API Specification The following APIs are exposed to instantiate, start the transfer and stop the transfer ### Constructor for initialization * This API initializes the BLE module using the provided configuration. This initialization process allows for the sharing of configuration information for advertisement purposes. A new instance is created with each initialization. * It is recommended to use one instance per session and to initialize a new instance for each subsequent session. * The configuration passed to the constructor includes a parameter called `deviceName`. This name is included in the advertisement payload during the BLE advertisement. It is important to note that this field has a character limit of 11 characters. **Signature** ``` constructor(configOptions: ConfigOptions) { Initialise verifier service with provided configuration } ConfigOptions { deviceName: string; } ``` **Parameters** | **Name** | **Description** | **ConfigOptions** | | ------------- | ------------------------------------- | --------------------------- | | configOptions | device name used during advertisement | deviceName is the parameter | ### API to start transfer * This API starts with advertisement for establishing the connection * Internally interacts with Tuvali to start advertisement * Update state to Advertising * Once the secure connection is established, navigate through to state to complete the transfer **Signature** ``` startTransfer() { Start Advertisement Interact with tuvali to start advertisement update state to Advertising } ``` ### API to stop transfer * This API has to be called explicitly to stop the connection * Connection can be stopped either after successful transfer or user wants to cancel the transfer * Once the connection is disconnected, state is updated to Idle **Signature** ``` stopTransfer() { disconnect the connection update state to Idle } ``` ### Types of states supported * Idle * Advertising * Connected * Secure Connection Established * Requested * Received * Error * Disconnected Transitions between states is shown below:

State diagram

**Note***:* If either the sender or receiver decides to cancel the transfer at any stage, the state will transition to Disconnected and become Idle as a result. #### Inji Wallet integration workflow with BLE Verifier SDK and Face Match SDK

Verifier App integration

--- [Next Page](/llms-full.txt/1)