Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
In today's fast-paced, interconnected world, ensuring seamless access to essential services—such as healthcare, financial inclusion, global mobility, and social support—has never been more critical. The need for trusted identity authentication and secure data exchange is at the heart of accessing these services. Traditionally, individuals have relied on multiple physical identification documents and certificates to prove their eligibility for various rights and services. However, managing physical documents is cumbersome and exposes individuals to risks of loss, fraud, and inefficiencies. Additionally, millions of people remain excluded from the formal economy due to an outdated reliance on paper-based credentials that cannot be verified digitally.
To address this, Inji offers a transformative solution – enabling the secure issuance, digitalization, storage, exchange and seamless verification of trusted data as verifiable credentials, through a comprehensive set of tools. By shifting away from physical documents to a digital-first approach, Inji simplifies the process, enhances security, and empowers a digital economy. With Inji, individuals can experience a future where accessing essential services is as simple as a few clicks, reducing the complexity of juggling numerous physical documents while maintaining the highest level of trust and security.
For a quick overview of Inji, which primarily includes Inji Wallet, Inji Verify and the Inji Certify as key components, you can watch the video titled "Inji Stack End To End Use Case Demonstration". This video provides a visual walkthrough of the key features and showcases how all modules interact through a persona-based demonstration, highlighting its real-world application. Head to the section titled “What Does Inji Include” for a comprehensive overview of how Inji functions, explaining how each component operates independently, while maintaining the interoperability necessary for seamless and secure credential verification.
Inji, meaning "knowing" or "recognizance" in Korean, is evolving into a comprehensive digital credential stack with a strong focus on user empowerment. Inji simplifies the management and verification of credentials by providing secure solutions that work across multiple interfaces. It aims to streamline the process of creating, sharing, and verifying all types of digital and physical credentials by offering:
Secure Issuance of Verifiable Credentials: Credentials are issued in both digital and physical formats, ensuring they are cryptographically secure and easy to share.
User-Centric Credential Management: Inji empowers individuals by providing them with tools to securely manage and share their credentials.
Simplified Instant Verification: It offers utilities that verify the authenticity of credentials, making the process efficient and user-friendly.
Interoperability: By adhering to global standards like the Verifiable Credentials Data Model (W3C VC) and OpenID for Verifiable Credential Issuance (OI4VCI), Inji facilitates seamless interactions across government, social, and private sectors.
Inji provides a complete solution for issuing, managing and exchanging trusted data as verifiable credentials across its entire lifecycle. Key components include:
Inji Certify: Converting data to trustworthy credentials, it enables trusted issuers to create, sign, issue, and bind credentials, in multiple formats.
Inji Wallet: Making data trustworthy and portable, it consists of two main interfaces that cater to diverse user needs:
Inji Mobile: A secure, decentralized mobile wallet that enables users to download, manage, share, and verify verifiable credentials directly from their smartphones. This mobile-first approach provides a seamless, trustworthy way to handle credentials on the go.
Inji Web: A user-friendly web interface that complements the mobile application, allowing individuals without access to smartphones, to manage their credentials through a browser. It provides features to download, print, store, and share credentials physically, ensuring broad accessibility across different platforms.
Inji Verify: Enabling exchange of trusted data with service providers, it is an essential tool to verify the authenticity of shared credentials.
Inji Infra: Supports functionalities like revocation, ledger management, status checks, and federation for verifiable credentials.
Inji Govern: Offers a governance framework to define policies, schemas, and assurance mechanisms, ensuring the security and trustworthiness of the ecosystem.
In summary, Inji provides a comprehensive solution that ensures all credential interactions - from issuance to verification - are secure, efficient, and aligned with global standards. This fosters high levels of trust at a low cost, supporting the development of a trusted digital economy. By bridging the gap between traditional and digital systems, Inji establishes a foundation for inclusive, secure, and transparent frameworks, paving the way for a more accessible and digital future for all, thereby ensuring widespread access to essential services.
Here we present the product roadmap for the whole of 'Inji Stack' for the calendar year 2025.
The quarters are defined as follows:
Q1: Jan'25 – Mar'25
Q2: Apr'25 – Jun'25
Q3: Jul'25 – Sep'25
Q4: Oct'25 – Dec'25
Q1
Cross-Device Enhancements for Credential Sharing ( OpenIDVP: Verifier Metadata Management)
🟠 In-progress
v0.16.0
Q1
Support for Sharing mDL/mDoc Credentials
🟠 In-progress
v0.17.0
Q1
Secure Wallet Setup with Key Binding (SIOP)
🔵 Planned
v0.17.0
Q1
Support for Advanced Cryptographic Keys (ECC K1)
🔵 Planned
v0.17.0
Q2
W3C Data Model 2.0 & SVG Render Method
🔵 Planned
v0.18.0
Q2
Credential Revocation
🔵 Planned
v0.18.0
Q2
SD JWT VC Support
Selective disclosure of user information while sharing
🔵 Planned
v0.18.0
Q2
Wallet Login with Unified Key Management
🔵 Planned
v0.19.0
Q2
Secure Key Recovery with Shamir’s Secret Sharing
🔵 Planned
v0.19.0
Q2
Profile Creation using a Single Credential
🔵 Planned
v0.19.0
Q3
Same Device Flow: Multiple credential requests during the presentation (OpenIDVP)
🔵 Planned
v0.20.0
Q3
OpenID4VCI Support for credential offer endpoint and pre-authorised code flow
🔵 Planned
v0.20.0
Q3
Advanced Privacy Features with BBS+
🔵 Planned
v0.20.0
Q3
Android App Security with Play Integrity
🔵 Planned
v0.20.0
Q4
One-Time-Use Credentials for Privacy
🔵 Planned
v1.0
Q4
Multi-User Family Credentials
🔵 Planned
v1.0
Q4
Support for JWT Credentials
🔵 Planned
v1.0
Q4
Support for Advanced Cryptographic Keys (ECC R1)
🔵 Planned
v1.0
Q1
User Login & Profile Management
🔵 Planned
v0.12.0
Q1
Unified Key Management for Web & Mobile
🔵 Planned
v0.12.0
Q1
W3C Data Model 2.0 & SVG Render Method
🔵 Planned
v0.13.0
Q2
Secure Key Recovery Using Shamir’s Secret Sharing
🔵 Planned
v0.13.0
Q2
Support for Advanced Cryptographic Keys (ED25519 Signature Support 2018 & 2020)
🔵 Planned
v0.13.0
Q2
Support for Advanced Cryptographic Keys (ECC K1)
🔵 Planned
v0.14.0
Q2
Support for mDoc/mDL Credentials
🔵 Planned
v0.14.0
Q2
CBOR Credential Format Support
🔵 Planned
v0.14.0
Q3
SD-JWT Credential Support
🔵 Planned
v0.14.0
Q3
Same-Device Credential Sharing Flow
🔵 Planned
v0.15.0
Q3
OpenID4VCI Support for credential offer endpoint and pre-authorised code flow
🔵 Planned
v0.15.0
Q3
Credential Revocation
🔵 Planned
v0.15.0
Q4
Advanced Privacy with BBS+ Support
🔵 Planned
v0.16.0
Q4
One-Time-Use Credentials for Privacy
🔵 Planned
v0.16.0
Q4
Multi-User Family Credentials
🔵 Planned
v1.0
Q4
Support for JWT Credentials
🔵 Planned
v1.0
Q4
Support for Advanced Cryptographic Keys (ECC R1)
🔵 Planned
v1.0
Q1
Support for ECC K1 & R1
🔵 Planned
Q1
Discovery and Metadata
did.json, openid verification to be created during issuer creation
🔵 Planned
Q1
Credential Revocation Mechanism
🔵 Planned
Q1
Credential Formats Support for
SD JWT
mDoc
🔵 Planned
Q1
Pre-authorized Code Flow
🔵 Planned
Q2
Presentation during issuance of Credential
🔵 Planned
Q2
Issuer initiated Credential Issuance
🔵 Planned
Q2
Anon Credential
🔵 Planned
Q3
VC Generation: Create Credentials from the Request Payload
🔵 Planned
Q3
Multi-issuers: Onboarding of multiple issuers
🔵 Planned
Q3
Subject Holder relationship for VC
🔵 Planned
Q3
Allow bulk generation of onetime credentials
🔵 Planned
Q4
Deferred Credential Endpoint
🔵 Planned
Q4
Multi-User Credentials
🔵 Planned
Q4
Issue a physical credential (PDF / Printable)
🔵 Planned
Q1
Inji Verify SDK
🟠 In-progress
v0.12.0
Q1
OpenIDVP: Same Device Flow (QR code based Verifiable Presentation), Multiple credential requests during the presentation
🔵 Planned
v0.12.0
Q1
Support for Country QR code - CWT Format
🟠 In-progress
Q1
Verify mDoc and mDL Credentials
🔵 Planned
Q1
Credentials Revocation
🔵 Planned
Q2
Templatizing post-VC verification on Inji Verify (SVG Rendering)
🔵 Planned
Q2
Support Server Side VC Verification: ECC- K1 and R1
🔵 Planned
Q2
Support for verification of W3C VC, SD JWT
🔵 Planned
Q2
Verify document (pdf) with multiple QR Codes
🔵 Planned
Q3
Support for multi proof: Single credential should support multiple proofs
(both embedded and linked)
🔵 Planned
Q3
GA Release:
Support multiple issuers
Support common crypto algorithms
Support various QR codes, VPs
Data Model 1.1, 2.0 VCs
Scalability
Bug Fixes
Performance Testing - 1 mill/day
Security Testing
Test Coverage>80%
Sonar Coverage
🔵 Planned
v1.0
Q3
Credential Correction
🔵 Planned
Q4
Offline Verification SDK
🔵 Planned
Q4
BLE based verifiable presentation
🔵 Planned
&
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!
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.
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.
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
Community leaders are responsible for clarifying and enforcing our standards of acceptable behaviour and will take appropriate and fair corrective action in response to any behaviour that they deem inappropriate, threatening, offensive, or harmful.
Community leaders have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, and will communicate reasons for moderation decisions when appropriate.
This Code of Conduct applies within all community spaces and also applies when an individual is officially representing the community in public spaces. Examples of representing our community include using an official e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event.
Instances of abusive, harassing, or otherwise, unacceptable behaviour may be reported to the community leaders responsible for enforcement at MOSIP. All complaints will be reviewed and investigated promptly and fairly.
All community leaders are obligated to respect the privacy and security of the reporter of any incident.
Community leaders will follow these Community Impact Guidelines in determining the consequences for any action they deem in violation of this Code of Conduct:
Community Impact: Use of inappropriate language or other behaviour deemed unprofessional or unwelcome in the community.
Consequence: A private, written warning from community leaders, providing clarity around the nature of the violation and an explanation of why the behaviour was inappropriate. A public apology may be requested.
Community Impact: A violation through a single incident or series of actions.
Consequence: A warning with consequences for continued behaviour. No interaction with the people involved, including unsolicited interaction with those enforcing the Code of Conduct, for a specified period of time. This includes avoiding interactions in community spaces as well as external channels like social media. Violating these terms may lead to a temporary or permanent ban.
Community Impact: A serious violation of community standards, including sustained inappropriate behaviour.
Consequence: A temporary ban from any sort of interaction or public communication with the community for a specified period of time. No public or private interaction with the people involved, including unsolicited interaction with those enforcing the Code of Conduct, is allowed during this period. Violating these terms may lead to a permanent ban.
Community Impact: Demonstrating a pattern of violation of community standards, including sustained inappropriate behaviour, harassment of an individual, or aggression toward or disparagement of classes of individuals.
Consequence: A permanent ban from any sort of public interaction within the community.
This Code of Conduct is adapted from the Contributor Covenant, version 2.1, available at https://www.contributor-covenant.org/version/2/1/code_of_conduct.html.
Community Impact Guidelines were inspired by Mozilla's code of conduct enforcement ladder.
For answers to common questions about this code of conduct, see the FAQ at https://www.contributor-covenant.org/faq. Translations are available at https://www.contributor-covenant.org/translations.
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.
For code contributions, refer here.
To engage with us on our community forum, visit here.
Current Challenge: Patients often need to share medical records and test results securely across different healthcare providers. This process is cumbersome, requiring manual handling of paper documents or insecure sharing via email and other communication channels.
Solution with Verifiable Credentials: Healthcare providers can issue VCs for vaccination records, allergies, or medication history. VCs can securely store and share medical records, test results, and vaccination history digitally. Patients can then easily share these credentials with other providers, ensuring continuity of care and faster treatment. Patients can control access to their data, ensuring only authorized healthcare providers can verify and access their information.
Benefits:
Reduced Friction: Patients can easily share verified medical credentials with healthcare professionals, streamlining the consultation and treatment process
Enhanced Privacy and Security: Verifiable credentials use cryptography to ensure data integrity and protect sensitive medical information
Current Challenge: Students often require verified academic transcripts and certificates when applying for further education or job opportunities, which they often carry physical transcripts or certifications. Requesting and verifying these documents can be time-consuming and prone to fraud.
Solution with Verifiable Credentials: Educational institutions can issue VCs such as digital diplomas, certificates, and transcripts. Students can share these credentials with potential employers or other educational institutions quickly and securely, streamlining verification and reducing wait times.
Benefits:
Efficient Verification: Employers and educational institutions can instantly verify the authenticity of academic credentials without relying on manual checks or third-party verification services
Prevention of Fraud: Verifiable credentials use cryptographic signatures to ensure the integrity and authenticity of educational documents, reducing the risk of forgery
Current Challenge: Customers often need to prove their identity and financial history when applying for loans, opening bank accounts, or accessing other financial services. This process typically involves submitting multiple paper documents and undergoing lengthy identity verification procedures.
Solution with Verifiable Credentials: Financial institutions can issue VCs that include identity information, credit scores, and financial history. Customers can use these credentials to securely and selectively share their information with authorized institutions.
Benefits:
Streamlined Onboarding Process: VCs enable faster and more efficient customer onboarding, reducing paperwork and administrative overhead for financial institutions
Enhanced Data Privacy: Customers have greater control over their personal and financial data, minimizing the risk of identity theft and unauthorized access
Current Challenge: Travelers often face challenges proving their identity and vaccination status when crossing borders. Paper-based documents are prone to loss or damage, leading to delays and disruptions during travel. Travelers juggle multiple documents for border crossings (passports, visas, health certificates) leading to delays and frustration.
Solution with Verifiable Credentials: Governments and health authorities can issue verifiable credentials for vaccination records, identity verification, and travel permissions. Travelers can present these digital credentials at checkpoints or border crossings securely and efficiently. These credentials can be easily accessed via mobile wallets and verified electronically, speeding up border processing and reducing queues.
Benefits:
Facilitated Cross-Border Travel: Verifiable credentials enable seamless verification of identity and vaccination status, reducing wait times and administrative hurdles at immigration checkpoints
Improved Public Health Measures: Authorities can track and verify vaccination records more effectively using digital credentials, supporting efforts to manage public health crises such as pandemics
Challenge: Job seekers often face delays due to lengthy background checks and verification of employment history and skills
Solution: Employers can issue verifiable credentials for past employment and skills acquired. Job seekers can then share these credentials with potential employers, allowing for faster verification and a smoother hiring process
Challenge: Citizens often need to present physical documents (birth certificates, proof of residence) to access government services, leading to inefficiency and potential loss of documents
Solution: Government agencies can issue verifiable credentials for citizen information. These credentials can be securely accessed and shared for various services, reducing administrative burdens and streamlining access
Reduced Friction: Verifiable credentials eliminate the need for physical documents, simplifying processes and speeding up transactions
Enhanced Security: Cryptographic verification ensures the authenticity and integrity of credentials, reducing the risk of fraud
User Control: Individuals control their data, choosing what information to share and with whom
Improved Efficiency: Streamlined workflows and faster access to services for both users and institutions
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.
Welcome to the "Try It Out" section! Here, we offer you hands-on experience to better understand how our product works and how you can leverage its features. This section will guide you through some simple steps to get started.
If you're a developer or a partner interested in experiencing or integrating with Inji Web, we invite you to explore our designated sandbox environments.
Collab serves as our development integration environment, featuring QA-tested dockers. It's a dedicated space where our partners and contributors can build on the platform or integrate with the latest QA-tested version of the code.
This environment undergoes regular nightly builds from our engineering team, making it a hub for continuous development activities.
Access resources on Collab, our sandbox environment, through the provided link.
Explore the guides of the various Inji Modules from below:
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.
If you require any assistance or encounter any issues during the testing and integration process, kindly reach out to us through the support mechanism provided below.
Navigate to Community.
Provide a detailed description about the support you require or provide detailed information about the issue you have encountered, including steps to reproduce, error messages, logs and any other relevant details.
\
The 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.
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.
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.
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.
The GenderMag Methodology aims to analyze and mitigate gender biases in users’ problem-solving interactions with software. It underscores the importance of accounting for gender differences in human-computer interaction (HCI) during the software design process.
Process
We identified two personas based on their familiarity with technology and their ability to embrace technological progress. The personas are:
Abi, who is either Abigail or Abishek, is 45 years old. She works as a homemaker, is literate, but not very tech- savvy. Her internet connectivity is moderate, and she does not have a personal phone.
Tim, who is either Timothy or Timara, a 24-year-old financial consultant, is literate, tech-savvy, and boasts excellent internet connectivity. Additionally, he owns the latest phone.
Examine the feature, systematically walk through the process, assess their information handling, and pinpoint any problems.
During the walkthrough, we pinpointed inclusivity concerns in the Inji Wallet app’s user interface and experience. Subsequently, we took steps to mitigate these issues, aiming to eliminate digital entry barriers.
As part of Phase1, below P1 items are fixed in the v0.11.0-Inji Wallet release:
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”.
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".
3
When the user clicks on the "Add" button, the options "Generate your card" or "Retrieve your ID" might be confusing.
The description should also include an explanation of why the verification process is necessary.
When the user glances at the screen, the "AID" is not immediately evident.
Update main screen name to "Download your card".
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).
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.
Update bottom line text to "Don't have UIN / VID? Get it now using your AID."
As part of Phase2, below P1, P2 items are fixed in the v0.12.0 release of Inji Wallet:
1
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/VID
2
The Resend Code is unclear in the OTP screen.
The Resend Code Text can be more descriptive. “Resend OTP” would be more clear than “Resend code”
The Resend code is confusing as to whether it is clickable or not.
Rename “Resend code” as “Resend OTP”
3
Though 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.
4
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.
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:
Provide assurance wrt Privacy
Terminology update: Face Authentication to Face Verification
Acquaint user with text about "Share with selfie" feature, informing user about face authentication - Through FAQs
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.
5
The 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”.
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."
Change CTA from "Scan" to "Share"
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
7
During 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
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.
Q1: Jan24 - Mar24
Q2: Apr24 - Jun24
Q3: Jul24 - Sep24
Q4: Oct24 - Dec24
Quarter
Feature
Status
Feature Details
Release Details
Q1-Q4
Threat modelling.
In-progress
Q1
Abstract INJI features (Tuvali, Secure-keystore) in to SDK/NPM libraries
Completed
Q1
Sunbird RC - Issuer integration
Completed
Q1
User data backup
Completed
Q1-Q2
INJI new UI - Gendermag (P1, P2, P3)
Completed
Q2
Different Views of Cards
Completed
Q2
VC Sharing Flow Optimisation
Completed
Q2
Credential Type Selection
Completed
Q2
VC Verification
Completed
Q2
QR Code Generation (PixelPass)
Completed
Q3
Native artefacts:
inji-vci-client
Secure keystore
Tuvali
PixelPass
Completed
Q3
Ease of Deployment
In-progress
Q3
Inji Certify Integration
In-progress
v0.14.0
Q3
Draft 13 changes of OpenID4VCI spec
In-progress
v0.14.0
Q3
Java upgrade to 21
In-progress
v0.14.0_Mimoto:
Q4
OpenID4VP
In-progress
v0.15.0
Q4
VC render spec based wallet rendering
In-progress
v0.15.0
Q4
OpenID4VP for BLE: Implementation of non QR based sharing as per OpenID for BLE specification
In-progress
v0.15.0
Q4
Support for different VC formats and proof types
In-progress
v0.15.0
Q4
Data Model 2.0
In-progress
v1.0.0
Q4
Performance Testing
In-progress
v1.0.0
Q4
Security Testing
In-progress
v1.0.0
Q4
OpenID4VCI enhancements
In-progress
v1.1.0
Q4
Wallet Login
In-progress
v1.1.0
Q4
BBS+ support
In-progress
v1.1.0
Q1: Jan24 - Mar24
Q2: Apr24 - Jun24
Q3: Jul24 - Sep24
Q4: Oct24 - Dec24
Quarter
Feature
Status
Feature Details
Release Details
Q2
Fetch & download credentials in PDF format
Issuer and credential type selection
Completed
Q2
Localization
Completed
Q2
Responsive View
Completed
Q2
Theme customization
Completed
Q2
Tech Upgrades:
Movement from Material UI to Tailwind
Conversion of JS to TS
Completed
Q2
QR Code in PDF
In-progress
v0.10.0
Q2
Online Sharing
In-progress
v0.10.0
Q2
Persistent storage
In-progress
v0.10.0
Q3
Secure time bound storage
Planned
v1.0.0
Q3
Performance Testing
Planned
v1.0.0
Q3
Security Testing
Planned
v1.0.0
Q3
Web UI enhancements:
Home Page
svg template in PDF
Planned
v1.0.0
Q4
User login, VC management, profile management (profile menu)
In-progress
v1.1.0
Q4
VC Validation & Verification
Planned
v1.1.0
Q4
OpenID4VCI enhancements
Planned
v1.1.0
Q4
Categorization of issuers
Planned
v1.2.0
Q4
mDoc/mDL & CBOR VC download
In-progress
v1.2.0
Q1: Jan24 - Mar24
Q2: Apr24 - Jun24
Q3: Jul24 - Sep24
Q4: Oct24 - Dec24
Quarter
Feature
Status
Feature Details
Release 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.
Completed
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
In-progress
Q3
Movement to Data Model 2.0
In-progress
v0.10.0
Q3
OpenID for Verifiable Credential Issuance - draft 13 Spec
Pre-Authorized Code Flow
Credential Offer End Point
In-progress
v0.10.0
Q3
VC Generation: Create Credentials from the Request Payload
W3C VC Issuance API
Planned
v0.10.0
Q3
Simplify the process of onboarding an issuer for a single entity
Planned
v0.11.0
Q3
Multi-tenancy: Onboarding of multiple issuers
Planned
v0.11.0
Q3
Persistent store for credentials
Pre-generated credentials
Credentials Registry (Hosted Infra)
Planned
v0.11.0
Q4
Issue a physical credential (PDF / Printable)
Support PDF or other formats of presentation based on plugins - PDF, PCF, PKPASS
Planned
v0.11.0
Q4
Vault Integration - Key manager support
Planned
v0.12.0
Q4
Vault - Key management
Planned
v0.12.0
Q4
Revocation Mechanism
Planned
v0.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)
Planned
v0.12.0
Q4
Allow Bulk/Batch Issuance
Issue certificates from an existing database
Planned
v0.12.0
Q4
Deferred Credential Endpoint
OpenIDVCI - Draft 13
Planned
v0.12.0
Q4
Inji Certify - Beta 1 - LTS
Planned
v1.0
Q1-Q4
Extend Credentials
Ability to issue extension on existing credential
Moved to 2025
Depriortized
Q1-Q4
Credential Correction
Support to retire the old credential and issue the new credential
Moved to 2025
Depriortized
Q1-Q4
Credential Formats Support - Selective Disclosure - Support SD JWT
Moved to 2025
Depriortized
Q1-Q4
[Credential Formats Support - Support mDocs
Moved to 2025
Depriortized
Q1-Q4
Business models (central, third-party SaaS, self-hosted)
Moved to 2025
Depriortized
Q1: Jan24 - Mar24
Q2: Apr24 - Jun24
Q3: Jul24 - Sep24
Q4: Oct24 - Dec24
Quarter
Feature
Status
Feature Details
Release Details
Q2
Web-based VC Verification functionality
Completed
Q2
UI/UX Enhancements based on GenderMag
Completed
Q2
Mobile Responsive Version - Upload and Scan feature
Completed
Q2
Material UI to Tailwind
Completed
Q2
Bug Fixes
Completed
Q3
Request Credential - OpenIDVP - OVP Flow
In-progress
v0.10.0
Q3
Docker Compose
In-progress
v0.10.0
Q3
Support for Country QR code - CWT Format
In-progress
v0.11.0
Q3
Verification SDK
In-progress
v0.11.0
Q3
Displaying Issuer Details post validation on UI
On-Hold
v0.11.0
Q3
Templatizing post-VC verification on Inji Verify(Render)
Planned
v0.11.0
Q3
Receive Credentials
(QR-based Verifiable Presentation)
Planned
v0.11.0
Q4
Multi-lingual UI Support - Localization
Planned
v0.12.0
Q4
VP requestor SDK
Planned
v0.12.0
Q4
Consume Data from credential
Planned
v0.12.0
Q4
Production Ready - Inji Verify - LTS Release 1.0.0
Planned
v1.0
Q1-Q4
BLE based verifiable presentation
Moved to 2025
Depritoritized
Q1-Q4
Credential Correction
Moved to 2025
Depritoritized
Q1-Q4
Revoked Credentials
Moved to 2025
Depritoritized
Q1-Q4
VC Reciever SDK
Moved to 2025
Depritoritized
Q1-Q4
Upload document(pdf) with multiple QR Codes
Moved to 2025
Depritoritized
Q1-Q4
Verify mDoc and mDL
Moved to 2025
Depritoritized
Q1-Q4
Mobile App (Login with Inbox & Logout)
Moved to 2025
Depritoritized
Q1-Q4
Offline Verification SDK
Moved to 2025
Depritoritized
The documentation is licensed under a Creative Commons Attribution 4.0 International License.
All MOSIP's core repositories are licensed under the terms of Mozilla Public License 2.0.
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.
The recommended Github workflow here is for developers to submit code and documentation contributions to Inji open-source repositories.
Fork the repository.
Clone the fork to your local machine. E.g.:
Set the upstream project as the original from where you forked. E.g.:
Make sure you never directly push upstream.
Confirm the origin and upstream.
This should display origin and upstream as below:
1. Create a new issue in GitHub.
Follow the issue template provided.
Please provide as much information as possible.
If you want to develop a new feature, please elaborate on the idea and discuss the design before starting development. 2. In your local repository, fetch the upstream.
3. On your local repo, switch to a branch if you are working on an older release or stay in main/develop
branch.
You will get a warning from git. Don't worry, our next step will take care of this warning.
4. Create a new issue branch with the name of the issue.
5. Make sure you are up-to-date with the upstream repo.
You should do this quite often to ensure you are up to date.
7. Once again ensure that you are up-to-date with the upstream repo as it may have moved forward.
8. Build and test your code. Make sure to follow the coding guidelines. Provide unit test cases for the changes you have built.
9. Push to your forked repo (origin).
10. On your forked remote repository from GitHub, create a pull request using the Contribute button. Direct the pull-request to main
or any specific branch upstream.
Most often it's the same branch in the upstream (as in Step 3).
11. Make sure the automatic tests/checks on GitHub for your pull request pass.
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.
The MOSIP project follows a simple structure with 3 levels.
Level 1 - MOSIP Technology Committee. This committee is responsible for high level roadmap and policy decisions such as licensing, and technology stack.
Level 2 - Project leadership. This is the executive leadership at MOSIP that includes key project roles within MOSIP such as product owner, engineering lead, and architects. These members will be appointed as maintainers and lead in the project by MOSIP.
Level 3 - Members. This is a set of people who are working on the project.
Given below is a list of specific roles and their responsibilities.
Maintainers are individuals who have “Commit” rights; And are the primary caretakers of the code and the strategic vision of the project. They are empowered to make decisions and resolve disputes for all contributions. They are appointed by MOSIP.
Project Lead is the chair of the committee of maintainers. They are appointed by MOSIP.
Contributors are the people or organisations who take part actively in the project and its meetings, code, design, and test and are recognized for their contributions. The contributors are part of the GitHub Members and would be actively involved in the discussion of a PR and review. Members strongly influence the Maintainer's decision.
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).
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
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:
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.
Attribution is in accordance with the relevant licence. Individual and affiliated contributors will be listed.
The key decisions to be taken are for the following activities
Roadmap and backlog priority
Triaging of bugs and requirements
Accepting a contribution Pull Request)
Releases
Most decisions will be made in periodical meetings where owners of the relevant aspect of work present a case for a decision and the decision will be made either by consensus, or by majority where a quorum exists. The maintainers of the project will be the decision makers. The project lead will have veto power on decisions due to their expertise and commitment to the vision of the project. Contributors can share their views in these meetings for consideration.
This document delineates the workflow for essential functionalities of Inji Wallet.
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)
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:
Download credentials using Knowledge Based Identification (KBI)
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
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.
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.
Inji Wallet utilizes multiple libraries to provide a seamless experience.
These libraries are accessible as NPM modules, allowing seamless integration with other mobile wallets.
The libraries are as follows:
Tuvali - Sharing via BLE SDK
Face Match SDK
Secure Keystore SDK
PixelPass SDK
VCI-client SDK
OpenID4VP - Online Sharing SDK
BLE Verifier SDK
Telemetry SDK(coming soon)
The transfer of downloaded Verifiable Credential from the Wallet to Verifier is facilitated by a React Native library named Tuvali.
Tuvali enables offline VC transfer between mobile devices via Bluetooth Low Energy (BLE). The below table represents the supported roles for Android and iOS devices.
Tuvali is actively developed and maintained by MOSIP.
It does not support iOS for initiating the BLE exchanges, hence preventing two iOS devices from transferring VC.
Note:
This SDK internally employs a tflite
model, which must be created by the integrating party. The model, trained using resident faces, is stored on the MOSIP file server. Inji Wallet currently utilizes the face matcher SDK (soon to be replaced by the NPM module) for offline face authentication.
The SDK is employed in two scenarios:
During Offline VC Sharing: Residents can perform selfie authentication before sharing the VC with the relying party. The app opens the camera, allowing residents to take a selfie, which is then validated against the VC image to verify the resident's presence. During Online Login: Residents can scan the QR code from the relying party portal and opt to log in using Inji Wallet for services. In this process, residents undergo selfie authentication against the VC to confirm their presence.
The secure-keystore library is designed for creating and storing key pairs in the hardware keystore of devices. The library supports encryption, decryption, HMAC calculation, and signing with aliases created during key pair generation.
This library is available for both Android and iOS platforms:
Inji Wallet integrates with the secure-keystore library to ensure secure key management. To optimize the key size during credential download requests, Inji Wallet uses RSA-2048, ECR1, ECK1, ED25519 keys.
Note:
Compatible with devices that support a hardware keystore.
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.
Note:
Refer to the PixelPass repository
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.
Note:
Refer to the VCI-Client repository
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.
Receives the Verifier's Authorization Request sent by the consumer application (mobile wallet).
Authenticates the Verifier using the received client_id and validates the whole Request to check if the required details are present or not and then returns the Authorization Request to the consumer application if all the validations are successful.
Receives the list of Verifiable Credentials from the consumer application which are selected by the consumer application end-user based on the credentials requested as part of Verifier Authorization request.
Constructs the vp_token without proof section and sends it back to the consumer application for generating Json Web Signature (JWS).
Receives the generated signature along with the other details and generates vp_token with proof section & presentation_submission.
Sends a POST request with generated vp_token and presentation_submission to the received Verifier's response_uri endpoint.
Note:
Refer to the inji-openid4vp repository
Note:
Note: The publication of this project is currently a work in progress and has not been released yet. Stay tuned for further announcements!
The Inji Mobile application is designed to securely store all types of digital credentials, from national IDs to certificates, in one easy-to-use mobile wallet. It offers a simple way to manage and share trusted data through Verifiable Credentials (VCs), making it portable, convenient, secure, and private for users.
Key features of Inji Mobile include secure storage, seamless sharing, and offline verification capabilities including face authentication, making it an essential tool for users managing digital credentials.
Secure Download and Storage of Verifiable Credentials (VCs): The Inji Mobile allows users to download, store, and manage their Verifiable Credentials securely. This makes it a dependable mobile solution for keeping identity credentials, ensuring users have access to their digital IDs anytime, anywhere.
Seamless Offline Credential Sharing: Users can share their credentials with service providers without requiring internet connectivity by utilizing Bluetooth Low Energy (BLE) technology. This offline sharing supports decentralized ID verification, making it possible to share VCs even in areas with limited to no internet connectivity, ensuring the user’s credentials are always accessible. This offline capability makes it ideal for users in rural or low-connectivity areas.
Offline Face Authentication for Secure Transactions: The app offers offline face authentication, verifying the user’s presence during credential sharing with service providers. This feature adds an additional layer of security when sharing credentials, ensuring the identity of the user is authenticated in real-time.
QR Code-Based Access to Online Services: The wallet enables users to log in to service provider portals by scanning QR codes, simplifying access to various services. It also supports single sign-on (SSO) capabilities, allowing users to access multiple services with the same credentials securely.
Privacy and Control Over Data Shared: Inji Mobile puts users in control of their data, allowing them to decide what information is shared with service providers. This consent-driven approach ensures that users' privacy is protected throughout all interactions.
Enhanced Efficiency for Government Services: Inji Mobile streamlines the registration process for government benefits, such as pensions and healthcare services. It also facilitates the use of VCs during travel and at security checkpoints, such as airports, ensuring that digital IDs are always readily accessible.
Robust Security with Verifiable Credentials: The digital credentials managed within Inji Mobile adhere to the Verifiable Credentials (VC) Data Model, ensuring the adherence to global standards for security and authenticity. Before downloading to the device, each credential is authenticated by the issuer's digital signature, and a unique HASH is generated to verify the integrity of the credential at any time.
Inji Mobile allows users to securely obtain and manage their verifiable credentials through a simple process. Users can download their credentials by using their unique ID (such as UIN or VID for a government-issued National ID) or the card details they already have (via the KBI method).
To validate their identity, users authenticate their request with a one-time password (OTP) sent to their registered mobile number or email.
Once validated, the verifiable credential is securely downloaded and stored in the app.
For added security, users have the option to authenticate their credentials through offline face verification during transactions.
Users maintain full control over what information is shared, through the consent mechanism that comes along.
Inji Mobile ensures that the digital signatures of the issuer are verified before the credential is stored, and it generates a unique HASH for each ID to confirm its integrity before displaying it in the app.
To summarize, Inji Mobile is an all-in-one mobile solution for securely managing and sharing Verifiable Credentials. By offering both online and offline features, privacy protection, and seamless integration with service providers, it empowers individuals to have complete control over their digital credentials, wherever they are.
Welcome to the Inji ecosystem, which encompasses the Inji Mobile Wallet, Inji Web Wallet, Inji Verify, and Inji Certify. These tools provide a powerful platform for managing and verifying digital credentials with ease. This document guides you through using mock data to explore the functionalities of each component, allowing you to understand and leverage their capabilities effectively. Read on to discover how you can interact with Inji's ecosystem, using demo credentials and mock data as explained below.
This guide explains the use of mock data for following:
Inji Mobile Wallet
Inji Web Wallet
Inji Verify
What would you need?
You will need UIN (Unique identification number) as a demo credential whic will allow you to explore Inji's capabilities and experience seamless VC sharing. You can also try this with 'Sample Insurance Credentials'.
Issuance of UIN (Unique identification number) as a demo credential will allow you to explore Inji's capabilities and experience seamless VC sharing firsthand.
Note: You can use 111111 as the OTP, for any OTP based feature in Collab environment.
For sample Insurance Credentials, please provide the below details in the eSignet authentication page:
Policy id: 7070
Name: aswin
DOB: 19/02/2025
The mock data you will need for Inji Web Wallet is same as that of Inji Mobile Wallet (Explained above).
Follow the procedure to try out Inji Verify in our collab environment:
To 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:
Feel free to scan or upload these QR codes to experience the functionality firsthand.
Inji Wallet is a mobile application designed to enhance user convenience by allowing them to securely download and manage their Verifiable Credentials (VC) offline. The diagram below illustrates the extensive features of Inji Wallet, highlighting the essential modules involved in issuing Verifiable Credentials.
Furthermore, this overview outlines various user flows, detailing the seamless processes users can follow. These processes include downloading VC by utilizing eSignet for authentication, securely activating VC, logging in to eSignet, and effortlessly sharing VCs.
.
Let’s go through a brief overview these components.
eSignet: Server enables user authorization and generates Verifiable Credentials (VCs) securely from user data.
Mimoto: This is a BFF(Backend for Frontend) for routing API calls to services.
Tuvali: This is an SDK that transfers data securely over BLE following OpenID4VPBLE specification.
Biometric SDK / Face Match SDK: This is an SDK used for face verification.
Secure Key Store: This is an SDK used for key-pair generation, signing and encryption/ decryption for Android.
Below is a comprehensive overview of the features provided by Inji Wallet.
Downloading your digital credentials (IDs) with you at all times just got easier. This can be done as below:
Residents can download a VC using a configured third-party issuer which complies with OpenID for VCI standard. For Inji Wallet, MOSIP IDA (National ID) and Veridonia Insurance (Insurance credentials) are example integrations.
Inji Wallet introduces a new feature that empowers users to select the specific type of credential they require. Upon choosing an issuer, users are presented with a list of Credential Types issued by the ID provider. This functionality provides users with flexibility and control, allowing them to download their Verifiable Credentials to their precise needs.
Inji Wallet offers a robust feature for verifying Verifiable Credentials using the Digital Bazaar library. This advanced functionality ensures that the issuer's signature is validated and verified based on the proof type provided by the issuer. This step is ingrained as part of the VC download flow. Currently, the support is for the RSA signature type, providing users with reliable verification capabilities. Additionally, we are actively working to expand our support to include the Ed25519 proof type, further enhancing the security and versatility of our verification process. With these advancements, users can trust that their Verifiable Credentials are verified with precision and integrity, regardless of the proof type utilized by the issuer.
PixelPass library is capable of generating QR codes for Verifiable Credentials with smaller size data. The library is integrated with Inji Wallet and users can now see a QR code which has Verifiable Credentials embedded in it. These QR codes, visible in the detailed view of the card, offer a convenient way for users to share their credentials with relying parties or service providers. Users can display the QR code so that the relying party / service provider can either:
Scan the QR code displayed in the wallet app showcased by the resident.
Upload the QR code as an image to the service provider verification website.
Reference Implementation: QR Code generation for Veridonia Insurance VC.
Inji Wallet allows users to securely share their downloaded VCs with other Inji users using Bluetooth Low Energy (BLE) technology, removing the necessity for an internet connection.
Users can verify the authenticity of their shared VCs by taking a self-portrait photograph on their mobile device. Inji Wallet compares this photograph with the image on the VCs, confirming the correct source and owner.
Inji Wallet users have the ability to choose which downloaded VC should be enabled for online authentication and selectively share the credentials on their ID. This capability provides users with an additional layer of security and control over the utilization of their stored information.
In order to safeguard against potential data loss in case of any unprecedented circumstances such as phone / app crashes, device change etc, and to improve user experience in the Inji app, users can now utilize the Backup and Restore feature for their Verifiable Credentials (VCs).
Depending on their device platform, users can choose to store and retrieve VCs securely using either Google Drive (for Android users) or iCloud (for iOS users). This is a one-time setup process, where Android users can select their respective Google email account, while iOS users can back-up data using their default logged-in Apple account.
Inji Wallet, as a digital Verifiable Credential wallet, implements robust measures to safeguard PII data and protect against cyber-attacks. Inji Wallet undergoes rigorous Penetration Testing and Threat Modelling by certified experts, further enhancing its resilience against cyber threats.
Utilization of Hardware Keystore:
Inji Wallet securely stores private encryption keys by utilizing the Android hardware keystore.
Cryptographic Protection for PII Data:
Inji Wallet employs industry-standard SHA-256 and Argon2 cryptographic libraries to hash and strengthen Personally Identifiable Information (PII) data. The app actively detects and responds to any suspicious activities, ensuring enhanced security of user data.
Automatic biometric change detection:
Inji Wallet automatically resets itself in case of biometric change, thereby ensuring the security of information.
Inji Wallet functions as a comprehensive repository for a diverse array of VCs, leveraging its interface design to benefit users.
Multiple views of VCs: Users can access multiple views of VCs, ranging from a mini view to detailed insights.
Organized UI: Inji Wallet provides a clear demarcation between downloaded and received VCs enhancing user clarity.
Quick Access menu: Users can now directly Share, Share with Selfie directly by accessing the kebab menu from the mini view in the Home Page and the detailed view of the VC.
Also, watch the video below for a quick glimpse of the features available.
Inji Mobile is a versatile digital wallet designed to securely manage, store, and share trusted data as Verifiable Credentials (VCs) through a seamless and user-friendly interface. This mobile application offers several key functionalities aimed at enhancing the user experience, ensuring robust data security, and simplifying digital credential management.
Key features include:
Inji Wallet enables users to securely download their verifiable credentials (VCs) directly onto their mobile devices. As part of this process, verification occurs to ensure the authenticity and validity of the credentials. Once verified, the VCs are securely stored using the device’s hardware-based secure keystore, ensuring that the credentials are protected from unauthorized access.
Inji Wallet offers a robust data backup feature, allowing users to protect their verifiable credentials by securely backing them up in either Google Drive (for android) or iCloud (for iOS devices). This ensures that even in the event of a device loss or replacement, users can easily restore their credentials and continue using them without re-verifying their identity with issuers.
Inji Wallet supports Single Sign-On (SSO), simplifying the authentication process by allowing users to log in using their existing credentials from trusted identity providers. This eliminates the need to manage multiple credentials and provides a seamless experience when accessing or sharing verifiable credentials across platforms.
Inji Wallet offers a seamless way to share the trusted data as verifiable credentials without internet connection, but through BLE-based (Bluetooth Low Energy) sharing. For added security, users must complete decentralized face verification for presence assurance during offline interactions, ensuring the rightful owner is sharing their credentials.
Screen name: Retrieve your UIN/VID on clicking link
Please note! Documentation has now moved to a new address and that is . This means we will gradually phase out the docs from being staying available at older URL i.e. .
6. Now feel free to make the change in the code or documentation. Reach out to for any queries. Once done with the work, commit your changes by referring to the Issue ID in the commit message. Eg:
12. Reviewers shall review the pull request. Reach out to the for a faster response.
We use to track the work associated with the project (account required). That is where issues open for community contribution can be found.
The process to contribute the code is present . Once code is submitted, it is reviewed through the following process:
Project Lead initiates the release process. The process can be found .
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 .
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 .
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 .
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 documentation.
To learn more about Tuvali's implementation, refer .
For information on Tuvali's permissions and requirements, refer .
To understand Tuvali and Inji Wallet integration, along with API documentation, refer.
Maven snapshots are available
The face matcher SDK internally implements native functionalities for Android and iOS, utilizing and to identify faces.
Upon the initial launch of Inji Wallet, the model is downloaded in the background and stored in the cache. Refer to check the API specifications for the face matcher model.
For Android: Refer to the .
For iOS: Refer to the .
To check all the APIs supported by this module, refer .
To understand the library and access API documentation, refer .
Maven snapshots are available .
Additionally, for a JSON data, the library employs CBOR encoding and decoding to minimize the size even further. When a JSON Mapper similar to 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.
To understand about the installation and the API documentation, refer .
For a hands-on experience of Generate a VC, Generate QR Code for the VC and Verify the same using Inji Verify, please click .
To check the NPM module, click.
Maven snapshots are available
To understand about the installation and the API documentation, refer .
Maven snapshots are available
To understand about the installation and the API documentation, refer .
Maven snapshots are available
The is the module built for verifiers for receiving VC via BLE. This is a wrapper built on Tuvali with simplified APIs.
To know more about API and how to integrate, refer .
To check the NPM module, click .
The module is derived from the module. It is responsible for generating events that can provide valuable analytics.
To know more about each of these, refer .
These credentials can then be shared with relying parties via Bluetooth, using the .
Inji Mobile also integrates with , enabling users to log in to service provider portals by simply scanning a QR code.
Inji Mobile is compatible with the protocol, offering a wide range of Identity Providers (IdP) for users to select from when downloading their verifiable credentials.
The app leverages for generating, downloading and activating Verifiable Credentials (VCs).
Additionally, it utilizes to enable seamless online login for users.
For any queries or contributions, please engage with us .
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 environment. Let's begin this journey of seamless setup and exploration.
Fill out the here and we will generate the demo credentials, which you can use subsequently on the Inji Mobile app to download and share Verifiable Credentials (VCs).
To obtain sample verifiable credentials embedded in a QR code, please initiate the process by following the steps to generate the QR code, click !
To know more about QR code verification, read about Inji Verify .
To understand the workflow, please refer .
The Inji Wallet application facilitates a Single Sign-On (SSO) function, empowering supported partners to enable a seamless login to online portals. This is achieved through the efficient process of scanning a QR code and sharing user data with their explicit consent. To understand the QR code login flow, refer .\
To understand the backup and restore flow, refer .
For a quick look at these features, refer the .
To understand the workflow of key features, refer .
Android
Android
Yes
iOS
Android
Yes
Android
iOS
No
iOS
iOS
No
Secure Keystore is a library exclusively for Android platform. The devices which have a Hardware Keystore can use this library to perform encryption, decryption and computation of HMAC on the native side using the Hardware backed security features.
The Secure Keystore is an independent module published as NPM module which provides Android APIs for the same on React. On a React Native application, this can be installed via
For RSA based Key Pair
For symmetric key
deviceSupportsHardware: boolean
Checks if the device supports hardware keystore.
generateKey(alias: string) => void
Generates a symmetric key for encryption and decryption.
generateKey(alias: string) => string
Generates an asymmetric RSA key Pair for signing.
encryptData(alias: string, data: string) => string
Encrypts the given data using the key that is assigned to the alias. Returns back encrypted data as a string.
decryptData(alias: string, encryptionText: string) => string
Decrypts the given encryptionText
using the key that is assigned to the alias. Returns back the data as a string.
sign(alias: string, data: string) => string
Creates a signature for the given data using the key that is assigned to the alias. Returns back the signature as a string.
hasAlias(alias: string) => boolean
Checks if the given alias is present in the keystore.
Following permissions are required to be included in the AndroidManifest.xml
to access Bluetooth Low Energy on Android.
Permissions required for Central (Wallet) when target is Android 12 or higher
Permissions required for Central (Wallet) when target is Android 11 or lower
Permissions required for Peripheral (Verifier) when target is Android 12 or higher
Permissions required for Peripheral (Verifier) when target is Android 11 or lower
Following permissions are required to be included in info.plist
to access the Core Bluetooth APIs on iOS.
BLE version: BLE 4.2 and above.
Android version: Android version 9 (API level 28) and above.
iOS version: The SDK requires iOS minimum deployment target version as 13.0.
Wallet: In this role, Tuvali can discover Verifier devices over BLE and can connect and share data. This role is supported on both, Android and iOS devices meeting minimum version requirement.
Verifier: In this role, Tuvali can advertise itself to Wallets and receive data. This role is supported only on Android devices at the moment. iOS doesn't support being a Verifier.
Name: Inji Wallet 0.15.1
Date: 27th March, 2025
Name: Inji Wallet 0.15.0
Date: 18th Feb, 2025
Name: Inji Wallet 0.14.1(Patch)
Date: 24th Feb, 2025
Name: Inji Wallet 0.14.0
Date: 25th Nov, 2024
Name: Inji Wallet 0.13.1 Patch release
Date: 10th Sep, 2024
Type: Developer
Name: Inji Wallet 0.13.0
Date: 2nd Aug, 2024
Name: Inji 0.12.0
Date: 31st May, 2024
Name: Inji 0.11.0-Inji
Date: 29th March, 2024
Name: Inji 0.11.0
Date: 23rd February, 2024
Name: Inji DP2
Date: 22nd January, 2024
Name: Inji 0.10.0
Date: 19th December, 2023
Name: Inji DP1 (Beta)
Date: 28th September, 2023
Name: Inji 0.9.1 (Beta)
Date: 25th July, 2023
Name: Inji 0.9.0 (Beta)
Date: 14th April, 2023
Name: Inji 0.8.0 (Alpha)
Date: 20th October, 2022
This telemetry module is derived from the sunbird telemetry module. It is responsible for generating events that can provide valuable analytics.
Note: The publication of this project is currently a work in progress and has not been released yet. Stay tuned for further announcements.
Face Match is an optional component in Inji Wallet. This is built as a standard that allows anyone to integrate their Facematch SDK. Its expected that the wallet providers would integrate the SDK that matches the specification.
The current specification is in draft state.
We extend our sincere appreciation to the IRIScan team for their invaluable support to MOSIP by providing an opensource face match SDK for our internal reference integration. We are truly impressed by your commitment and outstanding contribution. We welcome and invite our other esteemed partners to collaborate with MOSIP, for a similar integration.
To install any face sdk module, please add it's dependency in the package.json
file.
Once done rebuild the Inji Wallet.
The Inji Wallet should be able to integrate and use the face sdk.
This feature enables Inji Wallet to verify specific parameters for liveness. We utilize local face verification to guarantee the user's presence during a transaction. This measure is implemented to combat fraud, going beyond the ISO/IEC 30101 standard.
The following guidelines apply to individuals who are developing the face SDK:
It is prohibited to collect any personally identifiable information (PII) or phone details.
Inji Wallet includes built-in telemetry, and all telemetry data must be transmitted to the designated system. Telemetry enhances Inji Wallet's observability features by capturing specific events, creating measures, and monitoring various user actions and events.
Recording or transmitting IP addresses, user details, Phone IMEI, phone numbers, or user photos in telemetry or logs is strictly prohibited.
The use of phone numbers and device fingerprints should be limited to managing the SDK license.
This is the module that supports transferring verifiable credentials (VC) over Bluetooth Low Energy (BLE).
Let's have a look at how BLE communication works in general between the two devices A & B.
tuvali presents the kotlin library for tuvali
tuvali-ios-swift to get details on swift artifact.
tuvali contains the artefacts in maven.
In build.gradle.kts add the following:
The kotlin library has been added to your project.
Download swift artifact (ios-tuvali-library) from the repository.
Open your project in XCode.
Goto File > Add Package Dependencies.
Select Add Local option.
Add the artifact folder.
The swift library has been added to your project.
Before we understand how Tuvali works, let's go through BLE communication.
In BLE communication, one device is designated as Peripheral and another one designated as Central.
Peripheral can perform advertisement which can be read by a Central device and connected to it, if the advertisement is connectable.
Once the connection is made, Central can perform further actions on the device like
discovering services and characteristics
subscribing to notifications on characteristics
write/ read data from characteristics
disconnect from device
While peripheral can perform actions like
sending notifications to subscribed characteristics
respond to read requests from Central
The above diagram explains the sequence of actions for BLE communication in general.
Advertisement from Peripheral
Connection establishment & additional data exchange
Service & Characteristic discovery from Central
The characteristic subscription on Peripheral
Write with response to characteristic
Write without response to the characteristic
Send Notification from GATT Server
Disconnection from GATT Server/ Client
More details about other BLE terminology used here can be found in standard BLE specifications of 4.2 and above.
Note: Tuvali is supposed to implement OpenID for VP over BLE specification. As part of it, both VP request and response transfer should be implemented. However the current version of Tuvali only transfers VC from Central to Peripheral.
In the case of Tuvali, the entire VC transfer flow can be divided into the following stages
Connection Setup & Cryptographic key exchange
Data transfer
Connection Closure
Steps 1 to 6 mentioned in the above diagram explain how the first stage is achieved. Before even the advertisement is started, the peripheral generates a 32-byte public key. This public key is sent to Central in two parts. The first part will have 5 bytes of the public key sent as part of the advertisement payload and while the second part is sent as part of SCAN_RESP.
Since the advertisement from Peripheral is of connectable type, Central would send out a SCAN_REQ on receiving the advertisement and gets the remaining 27 bytes of the peripheral public key. Post that, Central would derive a public key pair and send its 32 bytes public key on Identify characteristic of Peripheral.
Once the public keys are exchanged between Central and Peripheral, a set of keys are derived on both sides which would be used for encryption and decryption of data on the wire.
Cryptographic Algorithm usage:
Ephemeral Key Pair is generated from X25519 curve
Key Agreement uses ECKA-DH (Elliptic Curve Key Agreement Algorithm – Diffie-Hellman) as defined in BSI TR-03111
Wallet and Verifier derives respective keys using HKDF as defined in RFC5869
Encryption/Decryption uses AES-256-GCM (192) (GCM: Galois Counter Mode) as defined in NIST SP 800-38D
Steps 7 to 11 mentioned in the above diagram explain how the second stage is achieved. Before VC is transferred, Central performs encryption and compression and communicates the resultant data size by writing to Response Size characteristic to Peripheral. The actual data transfer would happen on Submit Response
characteristic.
Since the maximum allowed write value for a characteristic is limited to 512 bytes. The actual VC data is split by a component called Chunker into multiple smaller chunks. After the split, the data is transferred on the Submit response
characteristics one after another until all chunks are completely sent.
Peripheral on the other hand, receives data on the Submit response
characteristic. The received chunks are collected and the final VC is assembled by a component called Assembler.
At the end of sending one frame of data from Central. It would request a transfer report via Transfer report request
characteristic. Peripheral response with a summary of missing/corrupted chunks sequence numbers via another Transfer report summary
characteristic.
Central would read the Transfer report summary to understand if the Peripheral received all the chunks properly. If the summary report has at least one chunk sequence number. Central would send those specific chunks to the Peripheral which is called the Failure frame.
The failure frame will be sent from Central repeatedly until the Transfer report summary is successful. If during the process, Central reached the maximum allowed failure frame retry limit, the transfer is halted, devices will be disconnected and an error is generated (Please refer to API documentation on how this error can be read).
Gzip is the Compression algorithm used with default compression level
Each chunk have 2 bytes of CRC-16/Kermit added. Parameters for the same are: width=16 poly=0x1021 init=0x0000 refin=true refout=true xorout=0x0000 check=0x2189 residue=0x0000 name="CRC-16/KERMIT"
On a successful data transfer
On non-recoverable error occurred on Peripheral
Peripheral notify Central to perform disconnection via Disconnect
characteristic mentioned in Step 12 of the above diagram.
Central also performs disconnect in the following scenarios:
On a successful data transfer
Non-recoverable error on Central
Peripheral is out of range/ disconnected
Destroy Connection API
As part of connection closure, both central and peripheral clean the held resources, cryptographic keys, and Bluetooth resources, to ensure that the subsequent transfer happens smoothly.
Note: All the cryptographic keys generated/ derived are used only for a single VC transfer session. The library strictly ensures they are not re-used in subsequent VC transfers post connection closure.
Error Code Format: <Component(2 Character)Role(1 Character)>-<Stage(3 Character)>-<Number(3 Character)>
Current Supported Stages: CON(Connection) | KEX(Key Exchange) | ENC(Encryption) | TRA(Transfer) | REP(Report) | DEC(Decryption) | UNK (Stage is unknown) Current Component+ Role Combinations: TVW(Tuvali+Wallet) | TVV(Tuvali+Verifier) | TUV(Tuvali where role is unknown)
List of Supported Error Codes:
UnknownException: TUV_UNK_001
WalletUnknownException: TVW_UNK_001
CentralStateHandlerException: TVW_UNK_002
WalletTransferHandlerException: TVW_UNK_003
VerifierUnknownException: TVV_UNK_001
PeripheralStateHandlerException: TVV_UNK_002
VerifierTransferHandlerException: TVV_UNK_003
InvalidURIException: TVW_CON_001
MTUNegotiationException: TVW_CON_002
ServiceNotFoundException: TVW_CON_003
TransferFailedException: TVW_REP_001
UnsupportedMTUSizeException: TVV_CON_001
CorruptedChunkReceivedException: TVV_TRA_001
TooManyFailureChunksException: TVV_TRA_002
Failed to transfer
message and wallet receive a Disconnected
message on the screen.Possible error scenarios:
During VC transfer, if there is a failure in the transfer of more than 70% of the data we get an exception on the verifier side and it disconnects from the wallet.
After the verifier and wallet establish a connection, the wallet initiates an MTU negotiation with the verifier. If the negotiated MTU is less than 64 Bytes, then the verifier throws an exception and disconnects from the wallet.
If the verifier receives the size of the VC as 0, it raises an exception and disconnects from the wallet.
Failed to transfer
message and the verifier receives a Disconnected
message on the screen.Possible error scenarios:
After the verifier and wallet establish a connection, the wallet initiates an MTU negotiation with the verifier. If the wallet is unable to negotiate the MTU with the verifier, it raises an exception and disconnects from the verifier.
During VC transfer, if the transfer cannot be completed within the specified limit of retries, the wallet raises an exception and disconnects from the verifier.
After the wallet sends all the chunks, it requests a transfer report. If the wallet is not able to send the request, it raises an exception and disconnects from the verifier.
Below are the exception message and the disconnect message which appears on the screen during the error.
This message is displayed on the device throwing the exception.
This message is displayed whenever a device gets disconnected.
Backoff Strategy: Exponential Backoff is a technique that retries a failing operation, with an exponentially increasing wait time, up to a maximum retry count(MAX_RETRY_LIMIT) or maximum backoff time(MAX_ELAPSE_TIME).
Initially, it starts with 2 ms as wait time (INITIAL_WAIT_TIME) and increases exponentially with each failure until the count reaches MAX_EXPONENT after which the wait time becomes constant (INITIAL_WAIT_TIME ^ MAX_EXPONENT).
BLE Service Discovery: After the connection is established, the central attempts to discover all the services hosted by the peripheral. If it fails to discover our service, then the exponential backoff-based retry will kick in. Here are the values:
MAX_RETRY_LIMIT is 5 for Android and 10 for IOS
MAX_ELAPSE_TIME is 100 ms
MAX_EXPONENT is 5
Request Transfer Report [only for iOS]: After the wallet writes all the chunks to the verifier, it requests the transfer report. If the transfer report request write fails, then the exponential backoff-based retry will kick in. Here are the values:
MAX_RETRY_LIMIT is 5
MAX_ELAPSE_TIME is 100 ms
MAX_EXPONENT is 5
Dynamic MTU negotiation:
Android: After the connection is established, the wallet initiates an MTU negotiation with an initial value of 512 bytes. If it fails, it retries with 185 and 100 bytes subsequently with a wait time of 500 ms each. If the negotiation fails after all retries, it throws an exception and disconnects from the wallet.
iOS: iOS kicks off an MTU exchange automatically upon connection
MAX_ALLOWED_DATA_LEN (509 Bytes): Maximum data length allowed for one write for both wallet and verifier.
MIN_MTU_REQUIRED (64 Bytes): Minimum number of bytes required to share public key transfer of the wallet is 46. In order not to operate in edges, we chose the nearest value in the power of 2 i.e., 64.
MAX_FAILURE_FRAME_RETRY_LIMIT (15): Maximum limit to retry sending failure chunks to the verifier.
IDENTIFY_REQUEST_CHAR_UUID (00000006-5026-444A-9E0E-D6F2450F3A77): Characteristic for sending the public key of the wallet.
REQUEST_SIZE_CHAR_UUID (00000004-5026-444A-9E0E-D6F2450F3A77): Characteristic for requesting VC size by wallet from verifier.
REQUEST_CHAR_UUID (00000005-5026-444A-9E0E-D6F2450F3A77): Characteristic for requesting the VC by the verifier.
RESPONSE_SIZE_CHAR_UUID (00000007-5026-444A-9E0E-D6F2450F3A77): Characteristic for sending VC size to the verifier.
SUBMIT_RESPONSE_CHAR_UUID (00000008-5026-444A-9E0E-D6F2450F3A77): Characteristic for sending the entire VC.
TRANSFER_REPORT_REQUEST_CHAR_UUID (00000009-5026-444A-9E0E-D6F2450F3A77): Characteristic for requesting for transfer report from the verifier.
TRANSFER_REPORT_RESPONSE_CHAR_UUID (0000000A-5026-444A-9E0E-D6F2450F3A77): Characteristic for sending transfer report to the wallet
VERIFICATION_STATUS_CHAR_UUID (00002037-0000-1000-8000-00805f9b34fb): Characteristic for informing the wallet if the VC is accepted or rejected.
DISCONNECT_CHAR_UUID (0000000B-5026-444A-9E0E-D6F2450F3A77): Characteristic for notifying the wallet to initiate the disconnection between the devices.
SERVICE_UUID (00000001-0000-1000-8000-00805f9b34fb): Service UUID of the verifier
SCAN_RESPONSE_SERVICE_UUID (00000002-0000-1000-8000-00805f9b34fb): Service UUID for uniquely identifying the scan response data to the wallet's SCAN_REQ
Below are the guidelines and specifications for integrating any software development kit (SDK) with Inji Wallet:
The SDK should be implemented as a npm module that supports the React Native framework.
For example, the npm modules, tuvali and secure-keystore, demonstrate suitable implementations.
The SDK should provide simple APIs for integration purposes.
These APIs should include an API for instantiation or initialization, such as the init or constructor API.
The SDK should also include additional APIs that perform the necessary actions.
There should be an API available to disconnect the SDK, if needed.
If possible, it would be beneficial for these APIs to be asynchronous. This enables users to continue using the application without experiencing any UI blocking.
To enhance logging and traceability, the API may accept an optional parameter known as traceabilityId
.
By adhering to these specifications, the integrated SDK will enhance the functionality and usability of the application.
This section contains various guides and information that could benefit the developers, system integrators, relying parties and end users.
For more information on how to get started with integrations, read through:
Tuvali - Sharing via BLE
Face Match
Secure Keystore
BLE Verifier
PixelPass
Telemetry (details coming up soon)
Important: We are in the process of updating screenshots and content in the End User Guide to reflect our new branding. These updates will be available soon, thank you for your patience!
This document serves as a concise user guide for end users, providing comprehensive information on the features and functionalities offered by Inji Wallet.
The below sections explain the steps for installing the Inji Wallet application on Android and iOS platforms.
To install the Inji Wallet app on an Android smartphone, click here to get the Inji Wallet apk
file for installation.
Transfer the apk
file onto the smartphone on which it is to be installed.
Click on the apk
file and follow the OS installation instructions.
Install the test flight app on your device.
Follow the steps mentioned here.
The below screenshots explain the next steps after you get access.
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.
Inji Wallet integrates with eSignet as an authorization layer to perform VC downloads based on OpenID4VCI standards. Let us understand how to download a National ID VC and an Insurance VC into the Mobile Wallet through the below sections:
Download National ID (MOSIP VC)
Download Insurance 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.
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.
Once we click on the downloaded VC on the Home Page, the detailed view opens up for the 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.
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.
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.
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 (...).
Two or more devices with Inji Wallet installed are required to share credentials. The relying party's phone should be an Android device.
All required permissions like Bluetooth, location, and camera access are enabled on both devices.
The parties involved are usually a Resident (sharing party) who wishes to share their credentials with a Relying party (receiving party), a banker, a health worker, or other professional service.
Users can now share their credentials using any of the methods listed below:
Share option from the NavBar.
Share or Share with Selfie option from the quick access menu (...) from a VC in the Home Page
Share or Share with Selfie option from quick access menu (...) in detailed view of VC.
Let us understand the process of sharing credentials using an example and see the step-wise process for all the above three methods. Suppose a Resident wishes to share their credentials with a Relying/ Requesting party through the receiver's phone, the following steps outline the procedure for both parties involved:
On the Sharing Party's phone:
The resident opens the QR Code Scanner by clicking on the Share
button in the NavBar. The application now prompts for permissions.
Upon granting the necessary permissions, the app opens a camera where the resident can scan the QR code of the recipient's (Verifier/Relying Party) phone.
Once the QR code is successfully scanned, both phones will establish a Bluetooth connection.
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.
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.
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.
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.
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.
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.
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.
To backup VCs, the user has to choose their preference for the cloud based on the device they are using.
Firstly, the user has to go to settings and click on the Backup and Restore menu options.
The User should consent for the app to use the drive, and once consented, the application displays a backup and restore screen.
In this screen, the user can manually take a backup by clicking on the Backup button and this asynchronously happens allowing the user to use the application.
Users will be notified of success or failure.
To restore backed-up VCs, the user has to choose their preference of the cloud based on the device and use the same Google/apple ID that they used for taking backups.
Firstly, the user has to go to settings and click on the Backup and Restore menu options.
The user should consent for the app to use the drive, and once consented, the application displays a backup and restore screen.
Users find the details of latest backup details in the Last Backup Details section.
In this screen, the user can manually restore a backup by clicking on the Restore button and this asynchronously happens allowing the user to use the application.
Users will be notified of success or failure.
Mimoto is a BFF(Backend for Frontend) for Inji Wallet. It's being used to get default configuration, download verifiable credentials (VC) and activate VC. It provides all necessary APIs to the Inji Wallet and acts as a proxy for resident services. Mimoto gets the request from Inji Wallet, performs all the validations and forwards it to respective services. Additionally, it subscribes to the web-sub event to be able to download the VC once it's ready.
Detailed API documentation of Mimoto is available here.
To get a list of issuers, this API is called. For retrieving the credential types and display properties, .well-known
location is referred for every issuer from the mimoto-issuers-config.json
Inji Wallet allows the users to download VC by redirecting the user to eSignet UI. Multiple APIs are being called to complete the process in the backend.
Inji Wallet initiates authenticate API by redirecting users to eSignet UI. On eSignet UI, user is given option to enter the unique ID, the user is asked to enter an OTP on the next screen. In the backend, token API is called to get a token. Refer here for more details.
After getting a token response, Inji Wallet initiates a download request. Refer here
Credentials have to be activated in order to use them for online login. When a user selects Activate option, an OTP is sent to the user and credentials are activated.
To send an OTP to a user, the below API is called.
After successful OTP validation, a keypair is generated in the phone and the public key is synced with server. The mimoto receives a certificate and create thumbprint which it stores in the keystore securely. This is called as the activation process.
The configurable properties for mimoto can be found at mimoto-default.properties. This property file is maintained as one for each deployment environment. On this repository, each environment configuration is placed in a corresponding branch specific to that environment.
Refer to mimoto-default.properties of Collab environment.
The implementers can choose to use the existing configurations or add new configurations to them.
The user is currently on the +
button on the Home screen, which will open Add new card
screen, where all the issuers are displayed Below issuers list API gives out all the issuers list
To get complete configuration of the specific issuer, below api is called.
This is the module built for verifiers to receive VC via BLE. This is a wrapper built on Tuvali with simplified APIs.
Add a dependency in package.json
Publishing npm module is WIP. Once it's published, it can be integrated as any other npm module.
The following APIs are exposed to instantiate, start the transfer and stop the transfer
This API initializes the BLE module using the provided configuration. This initialization process allows for the sharing of configuration information for advertisement purposes. A new instance is created with each initialization.
It is recommended to use one instance per session and to initialize a new instance for each subsequent session.
The configuration passed to the constructor includes a parameter called deviceName
. This name is included in the advertisement payload during the BLE advertisement. It is important to note that this field has a character limit of 11 characters.
Signature
Parameters
Name
Description
ConfigOptions
configOptions
device name used during advertisement
deviceName is the parameter
This API starts with advertisement for establishing the connection
Internally interacts with Tuvali to start advertisement
Update state to Advertising
Once the secure connection is established, navigate through to state to complete the transfer
Signature
This API has to be called explicitly to stop the connection
Connection can be stopped either after successful transfer or user wants to cancel the transfer
Once the connection is disconnected, state is updated to Idle
Signature
Idle
Advertising
Connected
Secure Connection Established
Requested
Received
Error
Disconnected
Transitions between states is shown below:
Note: If either the sender or receiver decides to cancel the transfer at any stage, the state will transition to Disconnected and become Idle as a result.
Tuvali module is based on the OpenID for Verifiable Presentations over BLE implementation to support sending vc/vp using Bluetooth Low Energy local channel. The below sections explains the APIs of the library in detail.
Firstly, for establishing the secured connection over BLE the connection params which include name
and key
needs to be exchanged between the two devices. This exchange of parameters can be accomplished but is not limited to by using a QR code.
For example, use a QR code generator to visually display params and a QR code scanner to get params. A mobile app that displays a QR code can act as an Verifier
by including its connection params as data in the QR code and another device can act as Wallet
which scans the QR code, it can extract the connection parameters and initiate a BLE connection with the advertising device.
The Verifier device generates a URI using the startAdvertisement()
method and displays it as a QR code. Once the advertisement starts, the Verifier continuously advertises with a payload derived from the URI.
URI structure can be found in the spec. Currently the library doesnot support iOS as a verifier.But it can act as a wallet for android verifier.
The device that scans the QR code will extract the connection parameters from the QR code and set its connection parameters using the startConnection()
method :
The connection param is a URI with a name & a key. The name
is the client's name & the key
is the verfier's public key.
The key
part of the data is the same data that will be advertised by the verifier
device but in hex-encoded form.
E.g: OVPMOSIP://connect:?name=<>&key=<verifier public key>
Once the connection is established, wallet app can send the data in a secured way to the Verifier. Note: At this moment, we currently support data transfer from Wallet to Verifier only.
and verifier app can acknowledge it.
The following sequence of actions should be performed to transfer data over BLE:
Verifier must start advertising by calling verifier.startAdvertisement(name)
method
Subscribe to events using wallet.handleDataEvents
Initiate the secure connection using wallet.startConnection(uri)
. The Wallet public keys are exchanged with verifier on successful connection.
Wallet calls wallet.sendData(payload)
to transfer requisite data over BLE.
Send VC response - Verifier can exchange "Accept/Reject" status to Wallet with the following message type for verifier.sendVerificationStatus
method
Data received from other apps via BLE can be subscribed to using: Tuvali sends multiple events to propagate connection status, received data etc. These events can be subscribed to by calling:
on Wallet:
on Verifier:
Here are the different types of events that can be received
Events which are emitted by both Wallet and Verifier
ConnectedEvent
on BLE connection getting established between Wallet and Verifier
SecureChannelEstablishedEvent
on completion of key exchange between Wallet and Verifier
ErrorEvent
on any error in Wallet or Verifier
DisconnectedEvent
on BLE disconnection between Wallet and Verifier
DataSentEvent
on completion of Data transfer from the Wallet Side
VerificationStatusReceivedEvent
on received verification status from Verifier
DataReceivedEvent
on receiving data from the Wallet Side
The device on which app is running can destroy the connection by calling disconnect() method:
The below diagram explains the series of handshakes between the Verifier and the Wallet device.
vci-client library enables to carry out the credential request from the consumer application (mobile wallet or web) and download the VC.
Creates a credential request with access token, issuer metadata, holder jwt proof.
Provide credential response (VC) to the consumer application.
Kotlin and Swift artefacts are available to integrate with the native mobile applications.
Below sections details on the steps for integrating the Kotlin and Swift packages into the app.
Snapshot builds are available here.
Note: implementation "io.mosip:inji-vci-client:0.1.0-SNAPSHOT"
1. Request Credential
Request for credential from the providers (credential issuer), and receive the credential.
Parameters
issuerMetaData
IssuerMetaData
Data object of the issuer details
IssuerMetaData(credentialAudience, credentialEndpoint, downloadTimeout, credentialType, credentialFormat)
proofJwt
Proof
The proof used for making credential request. Supported proof types : JWT.
JWTProof(jwtValue)
accessToken
String
token issued by providers based on auth code
""
DownloadFailedException is thrown when the credential issuer did not respond with credential response
NetworkRequestTimeoutException is thrown when the request is timedout
An example app is added under /example folder which can be referenced for more details.
Clone the repo
In your swift application go to file > add package dependency > add thehttps://github.com/mosip/inji-vci-client-ios-swift in git search bar> add package
Import the library and use.
1. Request Credential
Request for credential from the issuer, and receive the credential response back in string.
Parameters
issuerMeta
IssuerMeta
struct of the issuer details like audience, endpoint, timeout, type and format
IssuerMeta(credentialAudience, credentialEndpoint, downloadTimeout, credentialType, credentialFormat)
proofJwt
Proof
The proof type ProofJwt ex jwt
JWTProof(jwt: proofJWT)
accessToken
String
token issued by providers based on auth code
""
Exceptions
DownloadFailedError is thrown when the credential issuer did not respond with credential response
NetworkRequestTimeOutError is thrown when the request is timedout
More details
An example app is added under /SwiftExample folder which can be referenced for more details. Extract the swift example app out of the library and then follow the installation steps.
The below diagram shows how Inji Wallet utilises vci-client library.
This 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.
Receives the Verifier's Authorization Request sent by the consumer application (mobile wallet).
Authenticates the Verifier using the received client_id and validates the whole Request to check if the required details are present or not and then returns the Authorization Request to the consumer application if all the validations are successful.
Receives the list of Verifiable Credentials from the consumer application which are selected by the consumer application end-user based on the credentials requested as part of Verifier Authorization request.
Constructs the vp_token without proof section and sends it back to the consumer application for generating Json Web Signature (JWS).
Receives the generated signature along with the other details and generates vp_token with proof section & presentation_submission.
Sends a POST request with generated vp_token and presentation_submission to the received Verifier's response_uri endpoint.
Below sections details on the steps for integrating the Kotlin and Swift packages into the app. Below sections details on the steps for integrating the Kotlin and Swift packages into the app.
inji-openid4vp kotlin repo - here
Snapshot builds are available here.
Note: implementation "io.mosip:inji-openID4VP:0.1.0-SNAPSHOT"
val openID4VP = OpenID4VP("test-OpenID4VP")
Below are the APIs provided by this library:
1. authenticateVerifier
Receives a list of trusted verifiers & Verifier's encoded Authorization request from consumer app(mobile wallet).
Decodes and parse the request, extracts the clientId and verifies it against trusted verifier's list clientId.
Returns the Authentication response which contains validated Presentation Definition of the Authorization request.
Parameters
encodedAuthenticationRequest
String
Base64 encoded string containing the Verifier's authorization request
"T1BFTklENFZQOi8vYXV0"
trustedVerifiers
List
A list of trusted Verifier objects each containing a clientId and a responseUri list
listOf(Verifier("https://verify.env1.net",listOf("https://verify.env1.net/responseUri"))
Exceptions
DecodingException is thrown when there is an issue while decoding the Authorization Request
InvalidQueryParams exception is thrown if
query params are not present in the Request
there is an issue while extracting the params
both presentation_definition and presentation_definition_uri are present in Request
both presentation_definition and presentation_definition_uri are not present in Request
MissingInput exception is thrown if any of required params are not present in Request
InvalidInput exception is thrown if any of required params value is empty or null
InvalidVerifierClientID exception is thrown if the received request client_iD & response_uri are not matching with any of the trusted verifiers This method will also notify the Verifier about the error by sending it to the response_uri endpoint over http post request. If response_uri is invalid and validation failed then Verifier won't be able to know about it.
2. constructVerifiablePresentation
Receives a map of input_descriptor id & list of verifiable credentials for each input_descriptor that are selected by the end-user.
Creates a vp_token without proof using received input_descriptor IDs and verifiable credentials, then returns its string representation to consumer app(mobile wallet) for signing it.
Parameters
verifiableCredentials
Map<String, List>
A Map which contains input descriptor id as key and corresponding matching Verifiable Credentials list as value.
mapOf("id_123" to listOf("vc1","vc2"))
Exceptions
JsonEncodingFailed exception is thrown if there is any issue while serializing the vp_token without proof. This method will also notify the Verifier about the error by sending it to the response_uri endpoint over http post request. If response_uri is invalid and validation failed then Verifier won't be able to know about it.
3. shareVerifiablePresentation
This function constructs a vp_token with proof using received VPResponseMetadata, then sends it and the presentation_submission to the Verifier via a HTTP POST request.
Returns the response back to the consumer app(mobile app) saying whether it has received the shared Verifiable Credentials or not.
Parameters
vpResponseMetadata
VPResponseMetadata
This contains domain & proof details such as jws, signatureAlgorithm, publicKey, domain
VPResponseMetadata(jws = "eyJiweyrtwegrfwwaBKCGSwxjpa5suaMtgnQ",signatureAlgorithm = "RsaSignature2018",publicKey = "publicKey",domain = "https://domain.net")")
Exceptions
JsonEncodingFailed exception is thrown if there is any issue while serializing the generating vp_token or presentation_submission class instances.
InterruptedIOException is thrown if the connection is timed out when network call is made.
NetworkRequestFailed exception is thrown when there is any other exception occurred when sending the response over http post request. This method will also notify the Verifier about the error by sending it to the response_uri endpoint over http post request. If response_uri is invalid and validation failed then Verifier won't be able to know about it.
4. sendErrorToVerifier
Receives an exception and sends its message to the Verifier via an HTTP POST request.
Parameters
exception
Exception
This contains the exception object
new Exception("exception message")
Exceptions
InterruptedIOException is thrown if the connection is timed out when network call is made.
NetworkRequestFailed exception is thrown when there is any other exception occurred when sending the response over http post request.
inji-openid4vp-ios-swift swift repo -> here
Clone the repo.
In your swift application go to file > add package dependency > add the https://github.com/mosip/inji-openid4vp-ios-swift in git search bar > add package.
Import the library and use.
let openID4VP = OpenID4VP(traceabilityId: "AXESWSAW123", networkManager: NetworkManager)
1. authenticateVerifier
Receives a list of trusted verifiers & Verifier's encoded Authorization request from consumer app(mobile wallet).
Decodes and parse the request, extracts the clientId and verifies it against trusted verifier's list clientId.
Returns the Authentication response which contains validated Presentation Definition of the Authorization request.
Parameters
encodedAuthorizationRequest
String
Base64 encoded string containing the Verifier's authorization request
"T1BFTklENFZQOi8vYXV0"
trustedVerifierJSON
[Verifier]
A list of trusted Verifier objects each containing a clientId and a responseUri list
[Verifier(clientId: String, responseUris: [String])]
Exceptions
DecodingException is thrown when there is an issue while decoding the Authorization Request
InvalidQueryParams exception is thrown if
query params are not present in the Request
there is an issue while extracting the params
both presentation_definition and presentation_definition_uri are present in Request
both presentation_definition and presentation_definition_uri are not present in Request
MissingInput exception is thrown if any of required params are not present in Request
InvalidInput exception is thrown if any of required params value is empty or null
InvalidVerifierClientID exception is thrown if the received request client_iD & response_uri are not matching with any of the trusted verifiers This method will also notify the Verifier about the error by sending it to the response_uri endpoint over http post request. If response_uri is invalid and validation failed then Verifier won't be able to know about it.
2. constructVerifiablePresentation
Receives a map of input_descriptor id & list of verifiable credentials for each input_descriptor that are selected by the end-user.
Creates a vp_token without proof using received input_descriptor IDs and verifiable credentials, then returns its string representation to consumer app(mobile wallet) for signing it.
Parameters
credentialsMap
[String: [String]]
A Map which contains input descriptor id as key and corresponding matching Verifiable Credentials list as value
["bank_input":["VC1","VC2"]]
Exceptions
JsonEncodingFailed exception is thrown if there is any issue while serializing the vp_token without proof. This method will also notify the Verifier about the error by sending it to the response_uri endpoint over http post request. If response_uri is invalid and validation failed then Verifier won't be able to know about it.
3. shareVerifiablePresentation
This function constructs a vp_token with proof using received VPResponseMetadata, then sends it and the presentation_submission to the Verifier via a HTTP POST request.
Returns the response back to the consumer app(mobile app) saying whether it has received the shared Verifiable Credentials or not.
Parameters
vpResponseMetadata
VPResponseMetadata
This contains domain & proof details such as jws, signatureAlgorithm, publicKey, domain
VPResponseMetadata(jws: "jws", signatureAlgorithm: "signatureAlgoType", publicKey: "publicKey", domain: "domain")
Exceptions
JsonEncodingFailed exception is thrown if there is any issue while serializing the generating vp_token or presentation_submission class instances.
InterruptedIOException is thrown if the connection is timed out when network call is made.
NetworkRequestFailed exception is thrown when there is any other exception occurred when sending the response over http post request. This method will also notify the Verifier about the error by sending it to the response_uri endpoint over http post request. If response_uri is invalid and validation failed then Verifier won't be able to know about it.
4. sendErrorToVerifier
Receives an exception and sends its message to the Verifier via an HTTP POST request.
Parameters
error
Error
This contains the exception object
AuthorizationConsent.consentRejectedError(message: "User rejected the consent")
Exceptions
InterruptedIOException is thrown if the connection is timed out when network call is made.
NetworkRequestFailed exception is thrown when there is any other exception occurred when sending the response over http post request.
The below diagram shows the interactions between Inji Wallet, Verifier and OpenID4VP library.
PixelPass is a versatile and easy-to-use library designed to simplify working with QR codes and data compression. It allows you to generate QR codes from any given data with just a single function. If you’re working with JSON, PixelPass can take that data, compress it, and convert it into a compact format using CBOR encoding, making it smaller and more efficient for QR code generation. The library can also decode this compressed data, turning CBOR back into the original JSON format. Additionally, for more complex use cases, PixelPass offers the ability to map your JSON data to a specific structure, compress it, and encode it into CBOR. Later, you can also reverse this process, decoding the CBOR back into its mapped JSON structure. With these capabilities, PixelPass makes managing, compressing, and encoding data for QR codes easy and efficient.
PixelPass has NPM, Kotlin, Swift and Java artifacts available.
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.
As a node project:
npm i @mosip/pixelpass
As a Kotlin/Java dependency:
Gradle
implementation("io.mosip:pixelpass:0.5.0")
Maven
To include PixelPass in your Swift project, follow the below steps:
Clone the PixelPass library locally.
Create a new Swift project.
Add package dependency: PixelPass
Below are the APIs provided by the PixelPass library:
generateQRCode( data, ecc , header )
The generateQRCode
takes a data, ECC (Error correction level) which when not passed defaults to L and header which defaults to empty string if not passed. Returns a base64 encoded PNG image.
data
- Data needs to be compressed and encoded.
ecc
- Error Correction Level for the QR generated. defaults to "L"
.
header
- Data header need to be prepend to identify the encoded data. defaults to ""
.
generateQRData( data, header )
The generateQRData
takes a valid JSON string and a header which when not passed defaults to an empty string. This API will return a base45 encoded string which is Compressed > CBOR Encoded > Base45 Encoded
.
data
- Data needs to be compressed and encoded.
header
- Data header need to be prepend to identify the encoded data. defaults to ""
.
decode( data )
The decode
will take a string
as parameter and gives us decoded JSON string which is Base45 Decoded > CBOR Decoded > Decompressed
.
data
- Data needs to be decoded and decompressed without header.
decodeBinary( data )
The decodeBinary
will take a UInt8ByteArray
as parameter and gives us unzipped string. Currently only zip binary data is only supported.
data
- Data needs to be decoded and decompressed without header.
getMappedData( jsonData, mapper, cborEnable )
The getMappedData
takes 3 arguments a JSON and a map with which we will be creating a new map with keys and values mapped based on the mapper. The third parameter is an optional value to enable or disable CBOR encoding on the mapped data.
jsonData
- A JSON data.
mapper
- A Map which is used to map with the JSON.
cborEnable
- A Boolean which is used to enable or disable CBOR encoding on mapped data. Defaults to false
if not provided.
The example of a converted map would look like, { "1": "207", "2": "Jhon", "3": "Honay"}
decodeMappedData( data, mapper )
The decodeMappedData
takes 2 arguments a string which is CBOR Encoded or a mapped JSON and a map with which we will be creating a JSON by mapping the keys and values. If the data provided is CBOR encoded string the API will do a CBOR decode first ad then proceed with re-mapping the data.
data
- A CBOREncoded string or a mapped JSON.
mapper
- A Map which is used to map with the JSON.
The example of the returned JSON would look like, {"name": "Jhon", "id": "207", "l_name": "Honay"}
Shall you encounter any errors while using the APIs, please refer to the below:
Cannot read properties of null (reading 'length') - This error denotes that the string passed to encode is null.
Cannot read properties of undefined (reading 'length') - This error denotes that the string passed to encode is undefined.
byteArrayArg is null or undefined. - This error denotes that the string passed to encode is null or undefined.
utf8StringArg is null or undefined. - This error denotes that the string passed to decode is null or undefined.
utf8StringArg has incorrect length. - This error denotes that the string passed to decode is of invalid length.
Invalid character at position X. - This error denotes that the string passed to decode is invalid with an unknown character then base45 character set. Also denotes the invalid character position.
incorrect data check - This error denotes that the string passed to decode is invalid.
The below diagram shows how Inji Wallet utilises PixelPass library.
The below diagram shows how Inji Verify utilises PixelPass library.
The scope of testing is to verify fitment to the specification from the perspective of
Functionality Sanity
Automation UI
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 the readiness of software for use in multiple countries. Since MOSIP is an An automation Test Rig is created for the same.
The Inji testing scope revolves around sanity and covers the following flows:
Biometric unlock
Passcode unlock
Mosip download, activation and QR login
Sunbird download is working fine
Mock download is not working in qa-inji1 and working in collab & CRE
MDL download
Land registry
Sharing and share with selfie
Backup and restore
Key Management
Logout
INJI Wallet new logo
Remove VC is working.
Pinning VC is working
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 Sanity
Automation UI
The verification methods may differ based on how the need was addressed.
For regression check, "MOSIP Test Rig" - an automation testing suite - which is indigenously designed and developed for supporting persona-based testing. MOSIP Test Rig covers the end-to-end test execution and reporting. The end-to-end functional test scenarios are written starting from pre-registration to creation of packet in registration center, processing the packet through the registration processor, generating UIN and authenticating identity using IDA through various permutation and combinations of cases being covered. MOSIP Test Rig will be an open-source artifact which can also be enhanced and used by countries to validate the SI deliveries before going live. Persona classes include both negative and positive personas. Negative persona classes include users like Bribed Registration Office, Malicious Insider etc. The needs of positive persona classes must be met, whereas the needs of negative persona classes must be effectively restricted by the software.
The below section provides details on Ui Automation by executing MOSIP functional automation Framework.
Test Rate: 100%, With Pass Rate: 100%
Here is the detailed breakdown of metrics
Test Rate: 100%, Pass Rate: 100%
Test Rate: 100%, Pass Rate: 100%
The Home page help icon link is not working for activation and remove VC, for these two links it is showing page not found.
mosipqa/artifactory-server:0.10.x-INJI
mosipid/inji-certify:0.10.0
mosipid/inji-certify:0.10.0
mosipqa/inji-verify-service:develop
mosipqa/inji-verify-ui:develop
mosipid/data-share-service:1.3.0-beta.2
mosipqa/inji-web:0.11.0
mosipqa/mimoto:0.15.x
mosipqa/artifactory-server:0.10.x-INJI
mosipqa/inji-certify-with-plugins:develop
mosipqa/inji-certify-with-plugins:develop
mosipqa/inji-certify-with-plugins:develop
mosipqa/inji-certify-with-plugins:develop
mosipqa/inji-certify-with-plugins:develop
mosipqa/inji-certify-with-plugins:develop
mosipqa/dsl-packetcreator:develop
mosipdev/dsl-packetcreator:develop
mosipqa/inji-certify-with-plugins:develop
mosipid/mock-abis:1.2.0.2
mosipid/mock-mv:1.2.0.2
mosipid/hotlist-service:1.2.1.0
nginxinc/nginx-unprivileged:1.21.6-alpine
mosipid/admin-service:1.2.1.0
mosipid/admin-ui:1.2.0.1
mosipid/artifactory-server:1.4.1-ES
mosipid/authentication-demo-service:1.2.0.1
mosipid/authentication-demo-service:1.2.0.1
mosipdev/authentication-demo-service:develop
mosipdev/authentication-demo-service:develop
mosipid/biosdk-server:1.2.0.1
mosipqa/biosdk-server:develop
mosipdev/captcha-validation-service:develop
rancher/fleet-agent:v0.7.0
mosipid/data-share-service:1.2.0.1
mosipid/digital-card-service:1.2.0.1
mosipid/authentication-service:1.2.1.0
mosipid/authentication-internal-service:1.2.1.0
mosipid/authentication-otp-service:1.2.1.0
mosipid/credential-service:1.2.1.0
mosipdev/credential-request-generator:MOSIP-34070-v1210
mosipdev/id-repository-identity-service:MOSIP-34070-v1210
mosipid/id-repository-vid-service:1.2.1.0
mosipid/inji-verify:0.10.0
mosipid/data-share-service:1.3.0-beta.2
mosipid/inji-web:0.11.0
mosipid/mimoto:0.15.0
mosipid/kernel-auditmanager-service:1.2.0.1
mosipid/kernel-auth-service:1.2.0.1
mosipid/kernel-idgenerator-service:1.2.0.1
mosipid/kernel-masterdata-service:1.2.1.0
mosipid/kernel-notification-service:1.2.0.1
mosipid/kernel-otpmanager-service:1.2.0.1
mosipid/kernel-pridgenerator-service:1.2.0.1
mosipid/kernel-ridgenerator-service:1.2.0.1
mosipid/kernel-syncdata-service:1.2.1.0
mosipid/kernel-keymanager-service:1.2.0.1
mosipid/artifactory-server:0.10.0-INJI
mosipid/esignet:1.4.1
mosipid/inji-certify:0.10.0
mosipid/oidc-ui:1.4.1
mosipid/mock-identity-system:0.9.3
mosipid/mock-relying-party-service:0.9.3
mosipid/mock-relying-party-ui:0.9.3
mosipid/mock-smtp:1.0.0
mosipid/mosip-file-server:1.2.0.1
mosipid/artifactory-server:0.10.0-INJI
mosipid/mock-relying-party-service:0.9.3
mosipid/mock-relying-party-ui:0.9.3
mosipid/esignet:1.4.1
mosipid/inji-certify:0.10.0
mosipid/oidc-ui:1.4.1
mosipid/dsl-packetcreator:1.2.0.1
mosipid/dsl-packetcreator:1.2.0.1
mosipdev/dsl-packetcreator:develop
mosipdev/dsl-packetcreator:develop
mosipid/commons-packet-service:1.2.0.1
mosipid/pmp-ui:1.2.0.2
mosipid/partner-management-service:1.2.1.0
mosipid/policy-management-service:1.2.1.0
mosipid/pre-registration-application-service:1.2.0.1
mosipid/pre-registration-batchjob:1.2.0.1
mosipid/pre-registration-booking-service:1.2.0.1
mosipid/pre-registration-captcha-service:1.2.0.1
mosipid/pre-registration-datasync-service:1.2.0.1
mosipid/pre-registration-ui:1.2.0.1
mosipid/print:1.2.0.1
mosipid/registration-client:1.2.0.2
mosipid/registration-processor-common-camel-bridge:1.2.0.1
mosipid/registration-processor-stage-group-1:1.2.0.1
mosipid/registration-processor-stage-group-2:1.2.0.1
mosipid/registration-processor-stage-group-3:1.2.0.1
mosipid/registration-processor-stage-group-4:1.2.0.1
mosipid/registration-processor-stage-group-5:1.2.0.1
mosipid/registration-processor-stage-group-6:1.2.0.1
mosipid/registration-processor-stage-group-7:1.2.0.1
mosipid/registration-processor-notification-service:1.2.0.1
mosipid/registration-processor-dmz-packet-server:1.2.0.1
mosipid/registration-processor-reprocessor:1.2.0.1
mosipid/registration-processor-registration-status-service:1.2.0.1
mosipid/registration-processor-registration-transaction-service:1.2.0.1
mosipid/registration-processor-workflow-manager-service:1.2.0.1
mosipid/resident-service:1.2.1.0
mosipid/resident-ui:0.9.0
mosipid/artifactory-server:0.10.0-INJI
sunbird-rc-credential-schema:v2.0.0-rc3
sunbird-rc-credentials-service:v2.0.0-rc3
sunbird-rc-identity-service:v2.0.0-rc3
sunbird-rc-core:v1.0.0
mosipid/esignet:1.4.1
mosipid/inji-certify:0.10.0
mosipid/oidc-ui:1.4.1
mosipid/websub-service:1.2.0.1
mosipid/consolidator-websub-service:1.2.0.1
Vivo Y73 with Android 12 BLE 5.0
SS Galaxy A03 core with Android 11 BLE 4.2
iPhone 11 with i-OS 15 BLE 5.0
iPhone 8 with i-OS 16 BLE 5.0
iPhone 7 with i-OS 15.6 BLE 4.2
Redmi k20 pro with Android 13 BLE 5.0
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
This section contains the guides and information that could benefit the developers, system integrators, relying parties and the end users.
For more information on backend systems, read through:
The eSignet service is utilized by Inji Wallet for online login and downloading the VC. Users have the ability to log in to any service provider portal that is integrated with eSignet.
The user is required to open the portal integrated with eSignet and utilize the app scanner to scan the QR code.
After successfully scanning the QR code, Inji Wallet will access the API below and transmit the link code.
After successfully completing the offline face authentication and selecting the required and optional information, the two specified APIs are invoked.
The user is currently on the Add new card
screen and chooses the option to Download via eSignet
.
Inji Wallet utilizes the react-native-app-auth
library to authorize and redirect the user to the eSignet user interface. The configuration for redirection is retrieved as part of the issuer's configuration.
Once the user is on the eSignet user interface, they input the necessary information such as a unique ID and OTP (One-time Password). After entering the OTP, the user is redirected back to Inji Wallet in order to generate a key pair and initiate the request to download the credential.
For credential request, refer credential_endpoint attribute in issuer's configuration response.
This is a draft specification that is used to implement the face match in the Inji Wallet or any similar wallets.
This API is asynchronous and can be used for initializing the implementer's SDK. During initialization, the implementers can use this API to build logic to validate the license, download the latest model file if needed, or inform the server about its usage. This API is expected to return errors when there is a critical issue with the initialization process. If the API is called more than once, then the SDK can optionally return based on the current status. The implementation of this API should support offline mode. In offline mode, the implementor should ensure smooth usage. Care should be taken by the implementor to ensure the SDK is lightweight and does not slow down the app.
The implementation of this API should immediately return if initialization has already been completed.
The implementation should not attempt to initialize multiple times unless it's necessary.
The implementation should work in offline mode.
The implementation should support auto-downloading the latest models or any other configuration/artefacts necessary.
To enhance logging and traceability, the implementer should accept a parameter known as traceabilityId
, which helps to trace the logs on the server.
Signature
Inji Wallet would initialize the config as a JSON. The JSON would contain the following items
Standard Return Codes (true or false)
An asynchronous API that compares two images, allowing for different image formats such as PNG, JPG, HEIC or Template. Upon completion returns a boolean value. The API has an expected timeout and it is expected that the implementors clear the memory and processing upon timeout.
To enhance logging and traceability, the implementors should send telemetry using traceabilityId
. The id is set during the configure API call, It is expected that the same is used here. In Inji Wallet, AppId
is used as traceabilityId
.
Timeout is set in seconds.
Signature
Parameters
Standard Return Codes (match or no match)
The following guidelines apply to individuals who are developing the face SDK:
It is prohibited to collect any personally identifiable information (PII) or phone details.
Inji Wallet includes built-in telemetry, and all telemetry data must be transmitted to the designated system. Telemetry enhances Inji Wallet's observability features by capturing specific events, creating measures, and monitoring various user actions and events.
Recording or transmitting IP addresses, user details, Phone IMEI, phone numbers, or user photos in telemetry or logs is strictly prohibited
The use of device fingerprints should be limited to managing the SDK license.
Release Name: Inji Wallet 0.15.1(Patch)
Release Type: Developer
Release Date: 27th March, 2025
We are excited to announce the release of Inji Wallet Version 0.15.1! This update focuses on branding enhancements, including updated logos and visual identity across the wallet interface. While this is a minor update, it ensures consistency with our latest branding efforts and provides a refreshed user experience.
Updated Branding Logo: The Inji Wallet now features an updated logo and branding elements to align with the latest visual identity of the Inji ecosystem.
UI Enhancements: Adjustments have been made to ensure the new logo is seamlessly integrated across all screens.
Branding Updates:
Replaced the previous Inji logo with the new branding logo across all wallet screens.
Verified logo integration in the home screen, issuer selection, and credential views.
2. UI Improvements:
Adjusted logo positioning for enhanced visibility.
Ensured seamless branding consistency across mobile and web versions.
No functional & technical bug fixes were included in this release as it is focused exclusively on branding updates.
0.71.8
It brings the best parts of developing with React to native development. It's a best-in-class JavaScript library for building user interfaces.
4.9.5
A strongly typed programming language that builds on JavaScript and uses type inference to give great tooling without additional code.
29.5.11
Jest is a well-known JavaScript testing framework and is extensively used to test React applications
minSDK 24 compileSDK 24 targetSDK 34
Android is a mobile operating system based on a modified version of the Linux kernel and other open-source software, designed primarily for touchscreen mobile devices. This is used to build the application for running on Android devices
13.4
iOS is a mobile operating system developed by Apple exclusively for its smartphones. Swift is a high-level general-purpose, multi-paradigm, compiled programming language created to develop on iOS.
2.0.0 Java 17
Kotlin is a modern statically typed programming language
minSDK 23 compileSDK 33
Android is a mobile operating system based on a modified version of the Linux kernel and other open-source software, designed primarily for touchscreen mobile devices. This is used to build the application for running on Android devices
13.4
iOS is a mobile operating system developed by Apple exclusively for its smartphones. Swift is a high-level general-purpose, multi-paradigm, compiled programming language created to develop on iOS.
To ensure fraud prevention in compliance with , the faceAuth verification should include passive liveness checks, such as picture-in-picture.
There are no new known issues introduced in this release. For existing known issues, refer to
Total
Passed
Failed
Skipped
110
110
0
0
Platform
Category
Total
Passed
Failed
Skipped
iOS
Test cases
52
52
0
0
Platform
Category
Total
Passed
Failed
Skipped
Android
Test cases
58
58
0
0
Name
Description
Type
config
Configuration with model file and matcher threshold
Any object
Attribute Name
Description
traceabilityId
Traceability id is used to trace the telemetry data
io.inji.sdk.*
Any configuration that starts with io.inji.sdk would be sent in the config map.
Response
Status
true
Success
false
Error
Name
Description
Type
timeout
Timeout in seconds. After this time the SDK should stop processing.
integer
capturedImage
The image that is captured by the camera
Data URL format: data:image/imageformat base64 encoded image eg: data:image/jpeg
vcImage
The image that is given in the VC
Data URL format: data:image/imageformat base64 encoded image eg: data:image/jpeg
Response
Status
true
Matched
false
Not Matched
false
Error
Inji Mobile Wallet
inji-vci-client-ios-swift
pixelpass-ios-swift
Module
Version
Inji-config
eSignet
Inji Certify
Inji Verify
tuvali
tuvali-ios-swift
mimoto
vc-verifier
inji-vci-client-ios-swift
pixelpass
secure-keystore
secure-keystore-ios-swift
inji-vci-client
inji-openid4vp
The scope of testing is to verify fitment to the specification from the perspective of:
Functionality Sanity for iOS
Automation for iOS
Automation Mimoto API
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 the readiness of software for use in multiple countries. Since MOSIP is an "API First" product platform, Verification scope required comprehensive automation testing for all the MOSIP APIs. An automation Test Rig is created for the same.
The Inji testing scope revolves around the following flows:
Biometric unlock
Passcode unlock
VC download via MOSIP
VC download via Sunbird
Pinning a VC
Normal VC sharing
Deleting VC
Face Auth on Resident's phone
Multi language support
Backup and restore
Wallet binding
QR code Login
Logout
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 Sanity for iOS
Automation for iOS UI
Automation Mimoto API
The verification methods may differ based on how the need was addressed.
For regression check, "MOSIP Test Rig" - an automation testing suite - which is indigenously designed and developed for supporting persona-based testing. MOSIP Test Rig covers the end-to-end test execution and reporting. The end-to-end functional test scenarios are written starting from pre-registration to creation of packet in registration center, processing the packet through the registration processor, generating UIN and authenticating identity using IDA through various permutation and combinations of cases being covered. MOSIP Test Rig will be an open-source artifact which can also be enhanced and used by countries to validate the SI deliveries before going live. Persona classes include both negative and positive personas. Negative persona classes include users like Bribed Registration Office, Malicious Insider etc. The needs of positive persona classes must be met, whereas the needs of negative persona classes must be effectively restricted by the software.
The below section provides details on API test metrics by executing MOSIP functional automation Framework. All external API test executions were performed at module level isolation. Each end point is tested with the test data and expectations of each test data are mapped to assert the test case.
Total
Passed
Failed
Skipped
141
134
4
3
Test Rate: 97.97% , With Pass Rate: 97.10%
The below section provides details on Ui Automation by executing MOSIP functional automation Framework.
Here is the detailed breakdown of metrics
Platform
Category
Test cases
iOS
Total
48
Passed
48
Failed
0
Skipped
0
Test Rate: 100% With Pass Rate: 100%
Platform
Category
Test cases
Android
Total
60
Passed
60
Failed
0
Skipped
0
Test Rate: 100% With Pass Rate: 100%
Also Performed Manual Sanity with the Android APK, below is the updated result of the same:
Mosip VC download is working
Health insurance VC is working
Life insurance VC is working
Remove VC is working
Pinning VC is working
Share and share with selfie is working
QR code login is working
Backup and restore are working.
Logout is working
Unlock with biometric
Known issue:
The Home page help icon link is not working for activation and remove VC, for these two links it is showing page not found.
Functional and test rig code base branch which is used for the above metrics is:
Hash Tag:
SHA: sha256: 58e77d26fc1b98884c11638bba70c128d27994e3
mosipid/esignet:1.4.1
mosipqa/mimoto:develop
Tuvali Version - 0.5.1
mosipid/admin-service:1.2.0.1-B1
mosipid/admin-ui:1.2.0.1-B1
mosipid/artifactory-server:1.4.1-ES
mosipid/authentication-internal-service:1.2.0.1
mosipid/authentication-otp-service:1.2.0.1
mosipid/authentication-service:1.2.0.1
mosipid/biosdk-server:1.2.0.1
mosipid/commons-packet-service:1.2.0.1-B1
mosipid/config-server:1.1.2
mosipid/consolidator-websub-service:1.2.0.1-B1
mosipid/credential-request-generator:1.2.0.1
mosipid/credential-service:1.2.0.1
mosipid/data-share-service:1.2.0.1-B2
mosipid/hotlist-service:1.2.0.1-B1
mosipid/id-repository-identity-service:1.2.0.1
mosipid/id-repository-salt-generator:1.2.0.1
mosipid/id-repository-vid-service:1.2.0.1
mosipid/kernel-auth-service:1.2.0.1-B2
mosipid/kernel-idgenerator-service:1.2.0.1-B1
mosipid/kernel-keymanager-service:1.2.0.1
mosipid/kernel-notification-service:1.2.0.1-B1
mosipid/kernel-otpmanager-service:1.2.0.1-B1
mosipid/kernel-pridgenerator-service:1.2.0.1-B1
mosipid/kernel-ridgenerator-service:1.2.0.1-B1
mosipid/kernel-salt-generator:1.2.0.1-B2
mosipid/kernel-syncdata-service:1.2.0.1-B1
mosipid/keycloak-init:1.2.0.1
mosipid/keycloak-init:1.2.0.1-B2
mosipid/keycloak-init:1.2.0.1-B3
mosipid/keys-generator:1.2.0.1-B3
mosipid/masterdata-loader:1.2.0.1-B4
mosipid/mock-abis:1.2.0.1-B2
mosipid/mock-mv:1.2.0.1-B2
mosipid/mock-relying-party-service:0.9.1
mosipid/mock-relying-party-service:0.9.2
mosipid/mock-relying-party-ui:0.9.1
mosipid/mock-relying-party-ui:0.9.2
mosipid/oidc-ui:1.4.1
mosipid/partner-management-service:1.2.0.1-B3
mosipid/partner-onboarder:1.2.0.1-B4
mosipid/pmp-ui:1.2.0.1-B1
mosipid/policy-management-service:1.2.0.1-B3
mosipid/postgres-init:1.2.0.1-B4
mosipid/pre-registration-application-service:1.2.0.1-B1
mosipid/pre-registration-batchjob:1.2.0.1-B1
mosipid/pre-registration-booking-service:1.2.0.1-B1
mosipid/pre-registration-captcha-service:1.2.0.1-B1
mosipid/pre-registration-datasync-service:1.2.0.1-B1
mosipid/pre-registration-ui:1.2.0.1-B1
mosipid/print:1.2.0.1-B1
mosipid/registration-client:1.2.0.1-B1
mosipid/registration-processor-common-camel-bridge:1.2.0.1-B1
mosipid/registration-processor-dmz-packet-server:1.2.0.1-B1
mosipid/registration-processor-notification-service:1.2.0.1-B1
mosipid/registration-processor-registration-status-service:1.2.0.1-B1
mosipid/registration-processor-registration-transaction-service:1.2.0.1-B1
mosipid/registration-processor-reprocessor:1.2.0.1-B1
mosipid/registration-processor-stage-group-1:1.2.0.1-B1
mosipid/registration-processor-stage-group-2:1.2.0.1-B1
mosipid/registration-processor-stage-group-3:1.2.0.1-B2
mosipid/registration-processor-stage-group-4:1.2.0.1-B1
mosipid/registration-processor-stage-group-5:1.2.0.1-B1
mosipid/registration-processor-stage-group-6:1.2.0.1-B1
mosipid/registration-processor-workflow-manager-service:1.2.0.1-B1
mosipid/signup-service:1.0.0
mosipid/signup-ui:1.0.0
mosipid/softhsm:v2
mosipid/websub-service:1.2.0.1-B1
mosipint/digital-card-service:release-1.2.0.1-DP
mosipint/kernel-masterdata-service:develop-DP
mosipint/registration-processor-stage-group-7:develop-DP
mosipint/resident-service:develop-DP
mosipint/resident-ui:develop-DP
mosipqa/artifactory-server:0.9.0-INJI
mosipqa/artifactory-server:1.4.1-ES
mosipqa/authentication-demo-service:develop
mosipqa/automationtests:develop
mosipqa/dsl-orchestrator:develop
mosipqa/dsl-packetcreator:develop
mosipqa/inji-certify:0.9.x
mosipqa/inji-web:develop
mosipqa/kernel-auditmanager-service:1.2.0.1
mosipqa/keycloak-init:develop
mosipqa/mock-identity-system:0.9.3
mosipqa/mock-relying-party-service:0.9.x
mosipqa/mock-relying-party-ui:0.9.x
mosipqa/mock-smtp:0.0.2
mosipqa/mosip-artemis-keycloak:develop
mosipqa/mosip-file-server:develop
mosipqa/postgres-init:develop
mosipqa/softhsm:v2
Vivo Y73 with Android 12 BLE 5.0
SS Galaxy A03 core with Android 11 BLE 4.2
iPhone 11 with i-OS 15 BLE 5.0
iPhone 8 with i-OS 16 BLE 5.0
iPhone 7 with i-OS 15.6 BLE 4.2
Redmi 7A Android 10 BLE 4.2
Redmi note 10 lite Android 10 BLE 5.0
redmi K20 pro Android 11 BLE 5.0
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
Release Name: Inji 0.9.1 (Patch)
Upgrade From: Inji 0.9.0 (Beta)
Support: Developer Release
Release Date: 25th July, 2023
The 0.9.1 version of Inji Wallet is the first patch release on top of Inji 0.9.0. This release has bug fixes for features like Downloading and sharing the VC, Wallet binding, face authentication on resident’s phone, etc.
Below is a summary of some of the important bug fixes made in this version.
Added capabilitities to transfer the VC to more number of devices with an increase in device compatibility.
Introduction of error codes in case the transfer of VC fails.
Based on the android devices, Inji Wallet now asks for only the required Bluetooth permissions.
Migrated to MMKV storage from Async storage. With this, the devices can now store more number of VCs.
Renew auth token after expiry in Mimoto.
Added support for Filipino language (Philippines language).
Added support for languages whose semantics are Right-to-Left.
Added feature to restrict the downloading of ID card when the download of the card via UIN is blocked.
Updated VC thumbprints when the same VC is downloaded multiple times on the same device and is activated.
The 0.9.1 version of Inji Wallet mainly focuses on bug fixes along with some internal improvements like:
Ability to build on Windows
Abilty to build and push iOS builds to TestFlight without any human intervention
The older version of Inji Wallet app (0.9.0) will not be compatible with the newer version of Inji, due to the following reasons:
The storage has been changed from Async Storage to mmkv storage, which are two different storage mechanisms.
The VC sharing might break as Tuvali has updated the type of data shared across devices, hence it can cause array index out of bounds exception.
Bug fix: All the binded VCs will be shown and every binded VC can be used for online login irrespective of the timeframe of binding. #INJI-80
Bug fix: Tuvali now has the capability to specify an error code to let Inji know where the error has occurred during VC sharing instead of displaying the default error message. #INJI-71
Bug fix: In iOS, when the user tries to go back from the OTP screen while generating VID from AID, Inji was crashing. As a fix, it was made sure that the models (overlays) are not overlapping. #INJI-46
Bug fix: Inji now has the capability to render the resident's demographic information in the language chosen by the Residents. #INJI-44
Bug fix: Inji now has the capability to identify when the App is low on storage and notify the same to the Residents. #INJI-42
Bug fix: During wallet binding when the auth token is expired, the first call made for wallet binding will be used for refreshing the auth token, which then makes the current call to fail and subsequent calls to succeed. As a fix, the wallet binding call will refresh the token and complete the binding process. #INJI-41
Bug fix: Inji Wallet had a restriction to the overall storage size, in that, we were not able to download more than 29 VCs. As a fix, we migrated from Async storage to MMKV which does not have any upper limit on the storage size. #INJI-38
Bug fix: In the Home Screen, the tab indicators were not properly working in RTL. After the fix, RTL is being rendered properly. #INJI-36
Bug fix: The VCs that are added were getting stored in the app memory rather than user data. As a fix, MMKV storage was introduced (as opposed to async storage) to solve this by moving the VC data to user data instead of App memory. #INJI-35
Bug fix: A few texts were not being rendered in Arabic. The Arabic translations were added to make sure when the resident has chosen Arabic language, all the data is being rendered in Arabic. #INJI-34
Bug fix: The error popup shown during the BLE transfer is updated, the popup will now contain few error codes which depicts different stages where the failure has happened in the BLE layer. #INJI-28
Bug fix: There was a delay in reading and writing the VC from the device, so the storage mechanism has been changed from Async Storage to MMKV Storage, which ensures faster reading and writing. #INJI-7
Bug fix: Few devices failed to establish the connection while sharing of VCs were initiated (Vivo Y73 & Redmi K20 Pro). To resolve this, setting preferred PHY was removed and missing BLE permissions for Android 12 and above were added. #INJI-39
Bug fix: The VC transfers from iOS device always failed when Android 13 was the Verifier. As a fix, Bluetooth negotiation was updated to support Google Pixel (Android 13). #INJI-68
To know more about Inji Wallet, watch the video!
Release Name: Inji 0.9.0 (Beta)
Release Date: 14th April, 2023
The 0.9.0 version of Inji Wallet is the beta release which covers essential features such as Downloading and sharing the VC, Wallet binding, face authentication on resident' phone, etc.
The basic features such as,
Biometric Unlock
Passcode Unlock
VC download with VID
Renaming VC / Edit tag for VID
Normal VC sharing with VID
Online and Offine mode sharing
Face Auth on Resident's phone with VID
Multi-language support
Wallet binding
QR code Login
Logout
are available as part of this release.
Release Name: Inji Wallet 0.15.0
Release Type: Developer
Release Date: 18th Feb, 2025
We are excited to announce the release of Inji Wallet Version 0.15.0! This update brings significant improvements in credential handling, security enhancements, and expanded format support. Here are the key highlights of this release:
PixelPass - CWT Decode: Enhanced PixelPass capabilities with support for CWT decoding, increasing versatility in credential handling.
Support for Different VC Formats: Inji Wallet now supports various verifiable credential formats, including mDoc, mDL, and CBOR, broadening interoperability.
W3C-Based Wallet Rendering: Improved rendering for W3C-based verifiable credentials, ensuring seamless display and user experience.
Key Generation Enhancements: Added support for ECC (R1 & K1) and Ed25519 key generation, enhancing cryptographic flexibility.
OpenID4VP (Online Sharing): Implemented support for OpenID4VP, enabling secure online credential sharing.
VC Verification SDK Updates:
Added RSA support for Kotlin and Java SDKs.
Added EdDSA support for Kotlin and Java SDKs.
PixelPass Enhancements:
Added CWT decoding capabilities to enhance credential handling.
Expanded VC Format Support:
Support for mDoc, mDL, and CBOR formats to improve compatibility across different ecosystems.
W3C Rendering:
Improved rendering logic for better user interface consistency and compliance with W3C standards.
Cryptographic Key Generation:
ECC (R1 & K1) key generation.
Ed25519 key generation for improved security.
OpenID4VP Implementation:
Enabled online sharing of credentials via OpenID4VP protocol.
VC Verification SDK Enhancements:
RSA support added for Kotlin and Java SDKs.
EdDSA support added for Kotlin and Java SDKs.
Swift SDK support removed.
Module
Version
Inji Mobile Wallet
mimoto
vc-verifier
inji-openid4vp-ios-swift
inji-openid4vp
inji-vci-client-ios-swift
inji-vci-client
secure-keystore-ios-swift
secure-keystore
pixelpass-ios-swift
pixelpass
Module
Version
Inji-config
eSignet
Inji Certify
Inji Verify
tuvali
tuvali-ios-swift
Below is the list of known issues. To read in detail click here.
Jira Issue
Issue Description
[OpenId4VP] QR data is base64 encoded
Invalid URL Format for OPENID4VP on Android 14 and above version
Search is not working for the VCs from home page
INJI- In the Credential Registry popup, when entering an invalid URL in the 'Edit Credential Registry' field, the error message is overlapping
The activation VC is not working for a second time on the same device; the same VC displays a technical error message.
After we removed the mandatory configuration for the Mock issuer is not showing the error message in UI
During face authentication, the camera view is not opening in all IOS device
Automation run for sanity is failing few scenarios
Below is the list of fixes as part of the 0.15.0 release:
Jira Issue
Issue Description
Sunbird insurance VC download is failing with Ed25519 key
Automation(VC Verifier) - Verification of the mDL (mso_mdoc) against VC Verifier library is failing with no classFoundException
Disable the toggle for the biometric, but do not provide a passcode. Close and reopen the application; it still asks for a passcode to log in
qa-inji1 - Issuer page is not loading
DL VC download is failing in qa-inji1
INJIMOB- We are unable to download the MOSIP VC using the RegClient UIN, as it shows an 'Invalid UIN' error
The Help icon should be consistent across all pages
Intermittent download errors occur, causing the application to become unusable
After performing backup and restore, and then removing a VC, the actual count of VCs and the VCs present in the wallet are mismatched
Error screen CTAs not working in VC download flow
Injimobile- The download VC is stuck in a loading state
Intermediately We are unable to download the mock mdl VC; an error message appears.
We are unable to download the mosip VC; an error message appears
IOS - when biometric is cancelled multiple times during app launch the app data is deleted
Online login is failing with inji app crash from device
INJI - After providing biometric authentication, if the user clicks the cancel button, they should not be allowed to successfully download the VC
Inji- We are unable to download the VC via MOSIP ID due to an error message stating 'Failed to send OTP
Inji- The link from the help page leads to a 'Page Not Found' error when clicked
INJI- Intermittently, we are unable to download Sunbird as a 'Something went wrong' screen is being displayed
In INJI Mobile app, the issue type fails to load after selecting an issuer on Android and iOS devices
INJIMOB - Along with Insurance certify VC, an extra mock VC is getting downloaded
INJIMOB - Mock certify and mock fallback VC downloaded background color not reflecting, Only after close and reopen app it is reflecting
INJIMOB - About inji detail is different from IOS to android
Biometrics Toggle stop working after Inji tour guide is dismissed
INJIMOB- QR login is not working, we 're sorry! due to technical error we are unable to serve your request now, please try again later
INJIMOB- intermediately , the QR login is not working. We are encountering an error message
In the INJI 0.12x version, issues with downloading their UIN cards
User is getting a 'Technical error' message on the first attempt to download the VC after restarting the certify pod
Injimobile- After we removed the mandatory configuration for the Mock issuer is not showing the error message in UI
Search box close button is not working unless invoked on a specific point
Release Name: Inji Wallet 0.14.1(Patch)
Release Type: Developer
Release Date: 24th Feb, 2025
This patch release addresses a critical issue related to iOS dependency management, specifically fixing the checksum of the Boost library to enable a successful build and republishing of the iOS TestFlight release.
Fixed: Checksum issue with Boost dependency in iOS, ensuring successful package installation.
iOS TestFlight Republish: The previous TestFlight build for release-0.14.0 expired due to the 90-day limit. This patch enables republishing without requiring additional changes to the release branch.
Build Process Improvement: The IPA is rebuilt and republished from the same branch, ensuring smooth distribution on TestFlight.
This patch ensures that iOS builds remain functional and available for testing and deployment.
Note: The current release does not alter the android-build, it stays unchanged and is same as with Inji 0.14.0.
Module
Version
Inji Mobile Wallet
Module
Version
Mimoto
Inji-config
eSignet
Inji Verify
tuvali
tuvali-ios-swift
secure-Keystore
pixelpass
pixelpass-ios-swift
Inji-vci-client
Inji-vci-client-ios-swift
The list of known issues can be found here.
Jira Issue
Issue Description
iOS build failing in PR run due to failing `pod install`
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 the readiness of software for use in multiple countries. Since MOSIP is an “API First” product platform, Verification scope required comprehensive automation testing for all the MOSIP APIs. An automation Test Rig is created for the same.
The Inji testing scope revolves around the following flows:
Biometric unlock
Passcode unlock
VC download via MOSIP
VC download via esignet
VC download via Sunbird
Pinning a VC
Normal VC sharing with VID
Deleting VC
Face Auth on Resident's phone with VID
Multi language support
Credential registry
Backup and restore
Wallet binding
QR code Login
Logout
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.
For regression check, “MOSIP Test Rig” - an automation testing suite - which is indigenously designed and developed for supporting persona-based testing. MOSIP Test Rig covers the end-to-end test execution and reporting. The end-to-end functional test scenarios are written starting from pre-registration to creation of packet in registration center, processing the packet through the registration processor, generating UIN and authenticating identity using IDA through various permutation and combinations of cases being covered. MOSIP Test Rig will be an open-source artifact which can also be enhanced and used by countries to validate the SI deliveries before going live. Persona classes include both negative and positive personas. Negative persona classes include users like Bribed Registration Office, Malicious Insider etc. The needs of positive persona classes must be met, whereas the needs of negative persona classes must be effectively restricted by the software.
Verification is performed on various configurations as mentioned below
Default configuration - with 3 Lang
Virtual countries
1 Lang configuration
2 Lang configuration
3 Lang configuration
On Android Device:
On iOS Device:
Below are the test metrics by performing functional testing using mock MDS and mock ABIS. 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 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 languages and configurations. The testing cycle included simulation of multiple identity schema and respective UI schema configurations.
Total
Passed
Failed
Skipped (N/A)
2461
2203
214
44
Test Rate: 98.21% With Pass Rate: 91.14%
Here is the detailed breakdown of metrics for each module:
Test cases
On Android Device
Total
1315
Passed
1169
Failed
117
Skipped (N/A)
29
On iOS Device
Total
1146
Passed
1034
Failed
97
Skipped (N/A)
15
The below section provides details on API test metrics by executing MOSIP functional automation Framework. All external API test executions were performed at module level isolation. Each end point is tested with the test data and expectations of each test data are mapped to assert the test case.
Total
Passed
Failed
Skipped
141
134
4
3
Test Rate: 97.97% With Pass Rate: 97.10%
The below section provides details on Ui Automation by executing MOSIP functional automation Framework.
Total
Passed
Failed
Skipped
108
106
2
0
Test Rate: 100% With Pass Rate: 98.14%
Here is the detailed breakdown of metrics
Test cases
Android
Total
60
Passed
58
Failed
2
Skipped
0
iOS
Total
48
Passed
48
Failed
0
Skipped
0
Functional and test rig code base branch which is used for the above metrics is:
Hash Tag:
SHA: sha256: 58e77d26fc1b98884c11638bba70c128d27994e3
Below are the test metrics by performing VC Sharing functionality on various device combinations
Total
Passed
Failed
Skipped
192
192
0
0
Test Rate: 100% With Pass Rate: 100%
Tested with Components
mosipid/esignet:1.4.1
mosipqa/mimoto:develop
Tuvali Version - 0.5.1
Tested with MOSIP Components
mosipid/admin-service:1.2.0.1-B1
mosipid/admin-ui:1.2.0.1-B1
mosipid/artifactory-server:1.4.1-ES
mosipid/authentication-internal-service:1.2.0.1
mosipid/authentication-otp-service:1.2.0.1
mosipid/authentication-service:1.2.0.1
mosipid/biosdk-server:1.2.0.1
mosipid/commons-packet-service:1.2.0.1-B1
mosipid/config-server:1.1.2
mosipid/consolidator-websub-service:1.2.0.1-B1
mosipid/credential-request-generator:1.2.0.1
mosipid/credential-service:1.2.0.1
mosipid/data-share-service:1.2.0.1-B2
mosipid/hotlist-service:1.2.0.1-B1
mosipid/id-repository-identity-service:1.2.0.1
mosipid/id-repository-salt-generator:1.2.0.1
mosipid/id-repository-vid-service:1.2.0.1
mosipid/kernel-auth-service:1.2.0.1-B2
mosipid/kernel-idgenerator-service:1.2.0.1-B1
mosipid/kernel-keymanager-service:1.2.0.1
mosipid/kernel-notification-service:1.2.0.1-B1
mosipid/kernel-otpmanager-service:1.2.0.1-B1
mosipid/kernel-pridgenerator-service:1.2.0.1-B1
mosipid/kernel-ridgenerator-service:1.2.0.1-B1
mosipid/kernel-salt-generator:1.2.0.1-B2
mosipid/kernel-syncdata-service:1.2.0.1-B1
mosipid/keycloak-init:1.2.0.1
mosipid/keycloak-init:1.2.0.1-B2
mosipid/keycloak-init:1.2.0.1-B3
mosipid/keys-generator:1.2.0.1-B3
mosipid/masterdata-loader:1.2.0.1-B4
mosipid/mock-abis:1.2.0.1-B2
mosipid/mock-mv:1.2.0.1-B2
mosipid/mock-relying-party-service:0.9.1
mosipid/mock-relying-party-service:0.9.2
mosipid/mock-relying-party-ui:0.9.1
mosipid/mock-relying-party-ui:0.9.2
mosipid/oidc-ui:1.4.1
mosipid/partner-management-service:1.2.0.1-B3
mosipid/partner-onboarder:1.2.0.1-B4
mosipid/pmp-ui:1.2.0.1-B1
mosipid/policy-management-service:1.2.0.1-B3
mosipid/postgres-init:1.2.0.1-B4
mosipid/pre-registration-application-service:1.2.0.1-B1
mosipid/pre-registration-batchjob:1.2.0.1-B1
mosipid/pre-registration-booking-service:1.2.0.1-B1
mosipid/pre-registration-captcha-service:1.2.0.1-B1
mosipid/pre-registration-datasync-service:1.2.0.1-B1
mosipid/pre-registration-ui:1.2.0.1-B1
mosipid/print:1.2.0.1-B1
mosipid/registration-client:1.2.0.1-B1
mosipid/registration-processor-common-camel-bridge:1.2.0.1-B1
mosipid/registration-processor-dmz-packet-server:1.2.0.1-B1
mosipid/registration-processor-notification-service:1.2.0.1-B1
mosipid/registration-processor-registration-status-service:1.2.0.1-B1
mosipid/registration-processor-registration-transaction-service:1.2.0.1-B1
mosipid/registration-processor-reprocessor:1.2.0.1-B1
mosipid/registration-processor-stage-group-1:1.2.0.1-B1
mosipid/registration-processor-stage-group-2:1.2.0.1-B1
mosipid/registration-processor-stage-group-3:1.2.0.1-B2
mosipid/registration-processor-stage-group-4:1.2.0.1-B1
mosipid/registration-processor-stage-group-5:1.2.0.1-B1
mosipid/registration-processor-stage-group-6:1.2.0.1-B1
mosipid/registration-processor-workflow-manager-service:1.2.0.1-B1
mosipid/signup-service:1.0.0
mosipid/signup-ui:1.0.0
mosipid/softhsm:v2
mosipid/websub-service:1.2.0.1-B1
mosipint/digital-card-service:release-1.2.0.1-DP
mosipint/kernel-masterdata-service:develop-DP
mosipint/registration-processor-stage-group-7:develop-DP
mosipint/resident-service:develop-DP
mosipint/resident-ui:develop-DP
mosipqa/artifactory-server:0.9.0-INJI
mosipqa/artifactory-server:1.4.1-ES
mosipqa/authentication-demo-service:develop
mosipqa/automationtests:develop
mosipqa/dsl-orchestrator:develop
mosipqa/dsl-packetcreator:develop
mosipqa/inji-certify:0.9.x
mosipqa/inji-web:develop
mosipqa/kernel-auditmanager-service:1.2.0.1
mosipqa/keycloak-init:develop
mosipqa/mock-identity-system:0.9.3
mosipqa/mock-relying-party-service:0.9.x
mosipqa/mock-relying-party-ui:0.9.x
mosipqa/mock-smtp:0.0.2
mosipqa/mosip-artemis-keycloak:develop
mosipqa/mosip-file-server:develop
mosipqa/postgres-init:develop
mosipqa/softhsm:v2
Devices Used For Testing
Vivo Y73 with Android 12 BLE 5.0
SS Galaxy A03 core with Android 11 BLE 4.2
iPhone 11 with i-OS 15 BLE 5.0
iPhone 8 with i-OS 16 BLE 5.0
iPhone 7 with i-OS 15.6 BLE 4.2
Redmi 7A Android 10 BLE 4.2
Redmi note 10 lite Android 10 BLE 5.0
redmi K20 pro Android 11 BLE 5.0
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
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 the readiness of software for use in multiple countries. Since MOSIP is an "API First" product platform, Verification scope required comprehensive automation testing for all the MOSIP APIs. An automation Test Rig is created for the same.
The Inji testing scope revolves around the following flows:
Biometric unlock
Passcode unlock
VC download via MOSIP
VC download via esignet
VC download via Sunbird
Pinning a VC
Normal VC sharing with VID
Deleting VC
Face Auth on Resident's phone with VID
Multi language support
Credential registry
Backup and restore
Wallet binding
Deep link navigation
OpenID4VP
QR code Login
Key Management
Logout
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.
For regression check, "MOSIP Test Rig" - an automation testing suite - which is indigenously designed and developed for supporting persona-based testing. MOSIP Test Rig covers the end-to-end test execution and reporting. The end-to-end functional test scenarios are written starting from pre-registration to creation of packet in registration center, processing the packet through the registration processor, generating UIN and authenticating identity using IDA through various permutation and combinations of cases being covered. MOSIP Test Rig will be an open-source artifact which can also be enhanced and used by countries to validate the SI deliveries before going live. Persona classes include both negative and positive personas. Negative persona classes include users like Bribed Registration Office, Malicious Insider etc. The needs of positive persona classes must be met, whereas the needs of negative persona classes must be effectively restricted by the software.
Verification is performed on various configurations as mentioned below:
Default configuration - with 3 Lang
Virtual countries
1 Lang configuration
2 Lang configuration
3 Lang configuration
On Android Device:
On iOS Device:
Below are the test metrics by performing functional testing using mock MDS and mock ABIS. 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 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 languages and configurations. The testing cycle included simulation of multiple identity schema and respective UI schema configurations.
Total
Passed
Failed
Skipped (N/A)
2942
2659
283
0
Test Rate: 100% With Pass Rate: 90%
Here is the detailed breakdown of metrics for each module:
Module
Total
Passed
Failed
Skipped (N/A)
On Android Device
1562
1408
154
0
On iOS Device
1380
1251
129
0
The below section provides details on API test metrics by executing MOSIP functional automation Framework. All external API test executions were performed at module level isolation. Each end point is tested with the test data and expectations of each test data are mapped to assert the test case.
Total
Passed
Failed
Ignored
Skipped
176
143
0
33
0
Test Rate: 81% With Pass Rate: 100%
The below section provides details on UI Automation by executing MOSIP functional automation Framework.
Total
Passed
Failed
Skipped
112
112
0
0
Test Rate: 100% With Pass Rate: 100%
Here is the detailed breakdown of metrics:
Module
Total
Passed
Failed
Skipped
Android
60
60
0
0
iOS
52
52
0
0
Functional and test rig code base branch which is used for the above metrics is:
Hash Tag: SHA: sha256:01511fa220941a03f760550f3373ecc273dd6222000ab8030097858ece94ae29
Total
Passed
Failed
Skipped
97
77
20
0
Test Rate: 100% With Pass Rate: 79.38%
Below are the test metrics by performing VC Sharing functionality on various device combinations
Total
Passed
Failed
Skipped
192
192
0
0
Test Rate: 100% With Pass Rate: 100%
mosipqa/artifactory-server:0.10.x-INJI
mosipid/inji-certify:0.10.0
mosipid/inji-certify:0.10.0
mosipqa/inji-verify-service:develop
mosipqa/inji-verify-ui:develop
mosipid/data-share-service:1.3.0-beta.2
mosipqa/inji-web:0.11.0
mosipqa/mimoto:0.15.x
mosipqa/artifactory-server:0.10.x-INJI
mosipqa/inji-certify-with-plugins:develop
mosipqa/inji-certify-with-plugins:develop
mosipqa/inji-certify-with-plugins:develop
mosipqa/inji-certify-with-plugins:develop
mosipqa/inji-certify-with-plugins:develop
mosipqa/inji-certify-with-plugins:develop
mosipqa/dsl-packetcreator:develop
mosipdev/dsl-packetcreator:develop
mosipqa/inji-certify-with-plugins:develop
mosipid/mock-abis:1.2.0.2
mosipid/mock-mv:1.2.0.2
mosipid/hotlist-service:1.2.1.0
nginxinc/nginx-unprivileged:1.21.6-alpine
mosipid/admin-service:1.2.1.0
mosipid/admin-ui:1.2.0.1
mosipid/artifactory-server:1.4.1-ES
mosipid/authentication-demo-service:1.2.0.1
mosipid/authentication-demo-service:1.2.0.1
mosipdev/authentication-demo-service:develop
mosipdev/authentication-demo-service:develop
mosipid/biosdk-server:1.2.0.1
mosipqa/biosdk-server:develop
mosipdev/captcha-validation-service:develop
rancher/fleet-agent:v0.7.0
mosipid/data-share-service:1.2.0.1
mosipid/digital-card-service:1.2.0.1
mosipid/authentication-service:1.2.1.0
mosipid/authentication-internal-service:1.2.1.0
mosipid/authentication-otp-service:1.2.1.0
mosipid/credential-service:1.2.1.0
mosipdev/credential-request-generator:MOSIP-34070-v1210
mosipdev/id-repository-identity-service:MOSIP-34070-v1210
mosipid/id-repository-vid-service:1.2.1.0
mosipid/inji-verify:0.10.0
mosipid/data-share-service:1.3.0-beta.2
mosipid/inji-web:0.11.0
mosipid/mimoto:0.15.0
mosipid/kernel-auditmanager-service:1.2.0.1
mosipid/kernel-auth-service:1.2.0.1
mosipid/kernel-idgenerator-service:1.2.0.1
mosipid/kernel-masterdata-service:1.2.1.0
mosipid/kernel-notification-service:1.2.0.1
mosipid/kernel-otpmanager-service:1.2.0.1
mosipid/kernel-pridgenerator-service:1.2.0.1
mosipid/kernel-ridgenerator-service:1.2.0.1
mosipid/kernel-syncdata-service:1.2.1.0
mosipid/kernel-keymanager-service:1.2.0.1
mosipid/artifactory-server:0.10.0-INJI
mosipid/esignet:1.4.1
mosipid/inji-certify:0.10.0
mosipid/oidc-ui:1.4.1
mosipid/mock-identity-system:0.9.3
mosipid/mock-relying-party-service:0.9.3
mosipid/mock-relying-party-ui:0.9.3
mosipid/mock-smtp:1.0.0
mosipid/mosip-file-server:1.2.0.1
mosipid/artifactory-server:0.10.0-INJI
mosipid/mock-relying-party-service:0.9.3
mosipid/mock-relying-party-ui:0.9.3
mosipid/esignet:1.4.1
mosipid/inji-certify:0.10.0
mosipid/oidc-ui:1.4.1
mosipid/dsl-packetcreator:1.2.0.1
mosipid/dsl-packetcreator:1.2.0.1
mosipdev/dsl-packetcreator:develop
mosipdev/dsl-packetcreator:develop
mosipid/commons-packet-service:1.2.0.1
mosipid/pmp-ui:1.2.0.2
mosipid/partner-management-service:1.2.1.0
mosipid/policy-management-service:1.2.1.0
mosipid/pre-registration-application-service:1.2.0.1
mosipid/pre-registration-batchjob:1.2.0.1
mosipid/pre-registration-booking-service:1.2.0.1
mosipid/pre-registration-captcha-service:1.2.0.1
mosipid/pre-registration-datasync-service:1.2.0.1
mosipid/pre-registration-ui:1.2.0.1
mosipid/print:1.2.0.1
mosipid/registration-client:1.2.0.2
mosipid/registration-processor-common-camel-bridge:1.2.0.1
mosipid/registration-processor-stage-group-1:1.2.0.1
mosipid/registration-processor-stage-group-2:1.2.0.1
mosipid/registration-processor-stage-group-3:1.2.0.1
mosipid/registration-processor-stage-group-4:1.2.0.1
mosipid/registration-processor-stage-group-5:1.2.0.1
mosipid/registration-processor-stage-group-6:1.2.0.1
mosipid/registration-processor-stage-group-7:1.2.0.1
mosipid/registration-processor-notification-service:1.2.0.1
mosipid/registration-processor-dmz-packet-server:1.2.0.1
mosipid/registration-processor-reprocessor:1.2.0.1
mosipid/registration-processor-registration-status-service:1.2.0.1
mosipid/registration-processor-registration-transaction-service:1.2.0.1
mosipid/registration-processor-workflow-manager-service:1.2.0.1
mosipid/resident-service:1.2.1.0
mosipid/resident-ui:0.9.0
mosipid/artifactory-server:0.10.0-INJI
sunbird-rc-credential-schema:v2.0.0-rc3
sunbird-rc-credentials-service:v2.0.0-rc3
sunbird-rc-identity-service:v2.0.0-rc3
sunbird-rc-core:v1.0.0
mosipid/esignet:1.4.1
mosipid/inji-certify:0.10.0
mosipid/oidc-ui:1.4.1
mosipid/websub-service:1.2.0.1
mosipid/consolidator-websub-service:1.2.0.1
mosipqa/inji-certify:0.10.x
mosipqa/inji-web:release-0.11.x
mosipqa/mimoto:release-0.15.x
Vivo Y73 with Android 12 BLE 5.0
SS Galaxy A03 core with Android 11 BLE 4.2
iPhone 11 with i-OS 15 BLE 5.0
iPhone 8 with i-OS 16 BLE 5.0
iPhone 7 with i-OS 15.6 BLE 4.2
Redmi 7A Android 10 BLE 4.2
Redmi note 10 lite Android 10 BLE 5.0
Redmi K20 pro Android 11 BLE 5.0
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
Testing is conducted on build version mimoto 0.15.0 with ESignet 1.4.1.
Expired VC is tested for mock through docker compose.
For deep link navigation, testing is performed against build version ESignet 1.5.0.
Github link for the xls file is here
Release Name: Inji 0.13.0
Support: Developer Release
Release Date: 2nd Aug, 2024
We are delighted to announce the release of Inji Wallet Version 0.13.0. This update includes a significant change: The Inji repository has been renamed to inji-wallet and is now compatible with Mimoto v0.13.1. In this latest version, Inji Wallet introduces the following key features:
Libraries:
Native artefacts (Kotlin & Swift) available for:
Secure Keystore
Pixelpass
VCI client
Tuvali
UUID changes for verifier services in tuvali
Secure-keystore changes (credential request keypair change from RSA-4096 to RSA-2048 bits)
Enhancements:
Issuer’s Well-known as a source of truth
OTP flow disabled for MOSIP VC
Deployment:
Docker compose for mimoto
Please find below the details for the Inji Version 0.13.0 release:
Libraries:
Inji Wallet utilizes the Secure Keystore SDK to store keypairs, ensuring enhanced security. The SDK now includes native artifacts and is fully integrated with Inji Wallet. Additionally, the keypair generation for credential requests has been updated from RSA-4096 to RSA-2048 bits to reduce the size of the VCs.
Tuvali: UUID for all the verifier services is modified to reflect the UUID service definition as per the spec. In addition, Tuvali SDK which enables offline sharing based on BLE, has native artifacts (Kotlin and Swift) now and is integrated with Inji Wallet.
With this release, Java, Kotlin, and Swift artifacts are available for the PixelPass library, and native artifacts are integrated into the Inji Wallet app. Additionally, the Java library facilitates QR code generation on the server side.
The VCI client library handles credential requests from issuance, provided it has the accessToken, proof, and issuer metadata.
Enhancements:
The issuer's well-known URL will serve as the source of truth, providing details on locale settings for fields, credential types, display properties, and order. This URL will be accessible in the [specific location].
With this release, the OTP flow for downloading MOSIP VC, which connects to MOSIP ID Repo, credential service and websub has been disabled. Instead, MOSIP VC can now be downloaded using the OpenID4VCI flow.
Deployment:
To simplify the deployment process for Mimoto in local environment, a Docker Compose file is now available. Click here to know more.
The Inji repo is renamed to inji-wallet
Steps to update local github configuration:
Repositories
Tags Released
inji-wallet
mimoto
inji-config
tuvali
tuvali-ios-swift
secure-keystore
pixelpass
pixelpass-ios-swift
inji-vci-client
inji-vci-client-ios-swift
The following table outlines the tested and certified compatibility of Inji Wallet 0.13.0 with other modules.
Mimoto
eSignet
Inji Verify
Redmi devices are not supported in this release. To know more, refer here.
Mentioned below is the list of other known issues.
Jira Issue
Description
INJIMOB- During face authentication, the camera view is not opening in all IOS device
INJIMOB- In Android when the user clicks + icon from home page issuer page is not getting loaded
INJIMOB- Users are unable to upload the VC QR code shared via email and WhatsApp, or stored locally
INJI - unable to scroll the page add new card page
INJIMOB - IOS - "Share QR Code" is not working on iPhone 8.
INJIMOB - IOS - The buttons in the INJI tour guide are not properly aligned.
INJIMOB - Android - The backup and restore process is failing on Android devices when the size of the backup exceeds 10MB.
INJIMOB - Backup is not triggering automatically when VC is removed.
INJI - logo of Inji Wallet stretched while booting the app
Inji mob- During face authentication, the camera view is wider than the face.
INJI - VC download failed because of eSignet pod being down doesn't have a proper error message
IOS -Specific devices the User not able to see the iCloud ID in iCloud setting section of backup and restore page.
INJI- Error message is not proper when invalid QR is scanned after changing language to other than English.
INJI - Backup & restore Name Is Different In Settings And in Backup & restore Page
INJI - Help Icon Language not Changing when we select other language that english
Backup and Restore heading Alignment is not proper in Backup& restore page
IOS - Associated app ID is missing in the Backup and restore page.
Inji- Date format is not proper in the e-signet Vc
INJI- Sometimes VC activate the button and back button responses is very slow
INJI - VC getting created without image while generating the UIN with lower and higher iso files.
Android - Intermediately while doing the face authentication the app is getting crashed
INJI - Iderpo UINs are failing in VC verification
Inji - Screen header and back button are overlapping
Inji- In specific devices, the Pin and Unpin feature is not working.
Android- Occasionally, unable to activate the restored VC
IOS - Upon sharing sunbird VC twice and then upon sharing Mosip VC, app crashes
Android - During face authentication, app crashes on a specific device
INJI - Backup doesn't append the new data, but replaces the data
Upon changing the finger authentication in the device, application does not display the error pop up for biometrics change
The 0.13.0 release includes the following bug fixes:
INJIVER- The user is unable to upload the VC QR code shared via email and WhatsApp
Critical
INJIVER-The user is unable to scan the QR code when it is stored locally
Critical
INJIVER-The user is unable to scan the VC QR code shared via email and WhatsApp
Critical
INJIMOB - IOS - The "Share with Selfie" is causing the app to crash after face verification.
Critical
INJI - VC verification is passing for missing atribute VC
Critical
INJI - VC download failed because of eSignet pod being down doesn't have a proper error message
Major
Share with selfie flow from card mini view in home page is not showing the Share with Selfie pop-up before face verification.
Major
INJI - onboarding of new issuer is affecting the existing issuers
Blocker
Inji- E-Mail OTP channel is not mentioned on the OTP verification page.
Minor
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 the readiness of software for use in multiple countries. Since MOSIP is an “API First” product platform, Verification scope required comprehensive automation testing for all the MOSIP APIs. An automation Test Rig is created for the same.
The Inji testing scope revolves around the following flows:
Biometric unlock
Passcodes unlock
VC download via MOSIP
VC download via eSignet
VC download via Sunbird
Retrieving UIN/ via AID
Pinning a VC
Normal VC sharing with VID
Deleting VC
Face Auth on Resident's phone with VID
Multi language support
Credential registry
Backup and restore
Wallet binding
QR code Login
Logout
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
Deploy ability
Configurability
Customizability
The verification methods may differ based on how the need was addressed.
For regression check, “MOSIP Test Rig” - an automation testing suite - is indigenously designed and developed for supporting persona-based testing. MOSIP Test Rig covers the end-to-end test execution and reporting. The end-to-end functional test scenarios are written starting from pre-registration to the creation of the packet in the registration center, processing the packet through the registration processor, generating UIN, and authenticating identity using IDA through various permutations and combinations of cases being covered. MOSIP Test Rig will be an open-source artifact that can also be enhanced and used by countries to validate the SI deliveries before going live. Persona classes include both negative and positive personas. Negative persona classes include users like Bribed Registration Office, Malicious Insider, etc. The needs of positive persona classes must be met, whereas the needs of negative persona classes must be effectively restricted by the software.
Verification is performed on various configurations as mentioned below
Default configuration - with 3 Lang
Virtual countries
1 Lang configuration
2 Lang configuration
3 Lang configuration
On Android Device:
Below are the test metrics by performing functional testing using mock MDS and mock ABIS. 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 languages and configurations. The testing cycle included the simulation of multiple identity schema and respective UI schema configurations.
1236
1085
124
27
Test Rate: 98% With Pass Rate: 89.74%
Here is the detailed breakdown of metrics for each module:
1236
1085
124
27
The below section provides details on API test metrics by executing the MOSIP functional automation Framework. All external API test executions were performed at module level isolation. Each endpoint is tested with the test data and expectations of each test data are mapped to assert the test case.
64
58
6
0
Test Rate: 90.6% With Pass Rate: 9.4%
Here is the detailed breakdown of metrics:
64
58
6
0
The below section provides details on Ui Automation by executing the MOSIP functional automation Framework.
61
59
2
0
Test Rate: 100% With Pass Rate: 96.72%
Here is the detailed breakdown of metrics:
61
59
2
0
Functional and test rig code base branch which is used for the above metrics is:
SHA: sha256: b477f64889c7340a1d1ca6b17601473c30d206de8de9c8a69e8879be38e1dbb5
mosipid/esignet:1.4.0
mosipqa/mimoto:develop
Tuvali Version - 0.5.1
mosipid/admin-service:1.2.0.1-B1
mosipid/admin-ui:1.2.0.1-B1
mosipid/artifactory-server:1.4.0-ES
mosipid/authentication-internal-service:1.2.0.1
mosipid/authentication-otp-service:1.2.0.1
mosipid/authentication-service:1.2.0.1
mosipid/biosdk-server:1.2.0.1
mosipid/commons-packet-service:1.2.0.1-B1
mosipid/config-server:1.1.2
mosipid/consolidator-websub-service:1.2.0.1-B1
mosipid/credential-request-generator:1.2.0.1
mosipid/credential-service:1.2.0.1
mosipid/data-share-service:1.2.0.1-B2
mosipid/hotlist-service:1.2.0.1-B1
mosipid/id-repository-identity-service:1.2.0.1
mosipid/id-repository-salt-generator:1.2.0.1
mosipid/id-repository-vid-service:1.2.0.1
mosipid/kernel-auth-service:1.2.0.1-B2
mosipid/kernel-idgenerator-service:1.2.0.1-B1
mosipid/kernel-keymanager-service:1.2.0.1
mosipid/kernel-notification-service:1.2.0.1-B1
mosipid/kernel-otpmanager-service:1.2.0.1-B1
mosipid/kernel-pridgenerator-service:1.2.0.1-B1
mosipid/kernel-ridgenerator-service:1.2.0.1-B1
mosipid/kernel-salt-generator:1.2.0.1-B2
mosipid/kernel-syncdata-service:1.2.0.1-B1
mosipid/keycloak-init:1.2.0.1
mosipid/keycloak-init:1.2.0.1-B2
mosipid/keycloak-init:1.2.0.1-B3
mosipid/keys-generator:1.2.0.1-B3
mosipid/masterdata-loader:1.2.0.1-B4
mosipid/mock-abis:1.2.0.1-B2
mosipid/mock-mv:1.2.0.1-B2
mosipid/mock-relying-party-service:0.9.1
mosipid/mock-relying-party-service:0.9.2
mosipid/mock-relying-party-ui:0.9.1
mosipid/mock-relying-party-ui:0.9.2
mosipid/oidc-ui:1.4.0
mosipid/partner-management-service:1.2.0.1-B3
mosipid/partner-onboarder:1.2.0.1-B4
mosipid/pmp-ui:1.2.0.1-B1
mosipid/policy-management-service:1.2.0.1-B3
mosipid/postgres-init:1.2.0.1-B4
mosipid/pre-registration-application-service:1.2.0.1-B1
mosipid/pre-registration-batchjob:1.2.0.1-B1
mosipid/pre-registration-booking-service:1.2.0.1-B1
mosipid/pre-registration-captcha-service:1.2.0.1-B1
mosipid/pre-registration-datasync-service:1.2.0.1-B1
mosipid/pre-registration-ui:1.2.0.1-B1
mosipid/print:1.2.0.1-B1
mosipid/registration-client:1.2.0.1-B1
mosipid/registration-processor-common-camel-bridge:1.2.0.1-B1
mosipid/registration-processor-dmz-packet-server:1.2.0.1-B1
mosipid/registration-processor-notification-service:1.2.0.1-B1
mosipid/registration-processor-registration-status-service:1.2.0.1-B1
mosipid/registration-processor-registration-transaction-service:1.2.0.1-B1
mosipid/registration-processor-reprocessor:1.2.0.1-B1
mosipid/registration-processor-stage-group-1:1.2.0.1-B1
mosipid/registration-processor-stage-group-2:1.2.0.1-B1
mosipid/registration-processor-stage-group-3:1.2.0.1-B2
mosipid/registration-processor-stage-group-4:1.2.0.1-B1
mosipid/registration-processor-stage-group-5:1.2.0.1-B1
mosipid/registration-processor-stage-group-6:1.2.0.1-B1
mosipid/registration-processor-workflow-manager-service:1.2.0.1-B1
mosipid/signup-service:1.0.0
mosipid/signup-ui:1.0.0
mosipid/softhsm:v2
mosipid/websub-service:1.2.0.1-B1
mosipint/digital-card-service:release-1.2.0.1-DP
mosipint/kernel-masterdata-service:develop-DP
mosipint/registration-processor-stage-group-7:develop-DP
mosipint/resident-service:develop-DP
mosipint/resident-ui:develop-DP
mosipqa/artifactory-server:0.9.0-INJI
mosipqa/artifactory-server:1.4.1-ES
mosipqa/authentication-demo-service:develop
mosipqa/automationtests:develop
mosipqa/dsl-orchestrator:develop
mosipqa/dsl-packetcreator:develop
mosipqa/inji-certify:0.9.x
mosipqa/inji-web:develop
mosipqa/kernel-auditmanager-service:1.2.0.1
mosipqa/keycloak-init:develop
mosipqa/mock-identity-system:0.9.0
mosipqa/mock-relying-party-service:0.9.x
mosipqa/mock-relying-party-ui:0.9.x
mosipqa/mock-smtp:0.0.2
mosipqa/mosip-artemis-keycloak:develop
mosipqa/mosip-file-server:develop
mosipqa/postgres-init:develop
mosipqa/softhsm:v2
Vivo Y73 with Android 12 BLE 5.0
SS Galaxy A03 core with Android 11 BLE 4.2
iPhone 11 with i-OS 15 BLE 5.0
iPhone 8 with i-OS 16 BLE 5.0
iPhone 7 with i-OS 15.6 BLE 4.2
Redmi 7A Android 10 BLE 4.2
Redmi note 10 lite Android 10 BLE 5.0
redmi K20 pro Android 11 BLE 5.0
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.
Release Name: Inji Wallet 0.13.1 Patch release
Release Version: 0.13.1
Release Type: Developer
Release Date: 10th Sep, 2024
We are excited to announce the release of Inji Wallet Version 0.13.1! This patch release aims on critical fixes and improvements to ensure smoother integration of libraries and enhanced performance. Key updates include the bundling of dependencies with Android Archive (AAR) and JAR files, which simplifies the integration process and resolves issues related to library dependencies for the below mentioned libraries:
tuvali
inji-vci-client
pixelpass
secure-keystore
Library Updates:
Updated libraries to bundle dependencies with Android Archive (AAR) and JAR formats. This ensures that all required dependencies are included within the package, reducing the need for external dependency management and minimizing conflicts during app integration.
These changes enhance compatibility with various Android development environments and improve the overall stability of the wallet.
Repositories
Tags Released
tuvali
secure-keystore
pixelpass
inji-vci-client
Inji Wallet
The following table outlines the tested and certified compatibility of Inji Wallet 0.13.1 with other modules.
Module
Version
Mimoto
inji-config
None
Redmi devices are not supported in this release. To know more, refer here.
Mentioned below is the list of other known issues.
Jira issue
Issue description
In the INJI 0.12x version, issues with downloading their UIN cards.
INJIMOBILE- After clicking the + icon, the screen flickers before landing on the 'Add New Card' screen
Search box close button is not working unless invoked on a specific point
INJIMOB- Android - History timings could be more precise
IOS- Mobile app session should get expired, if the app is opened for a longer time and user tries to login again with the PIN to generate VC by using UIN/VID.
INJI - error message of QR code login without internet attempt should be revised
INJIMOB- In the face verification page the capture button overlaps with text
INJIMOB- During face authentication, the camera view is not opening in all IOS device
INJIMOB - IOS - "Share QR Code" is not working on iPhone 8.
INJIMOB - Backup is not triggering automatically when VC is removed.
INJI - logo of inji mobile stretched while booting the app
IOS -Specific devices the User not able to see the iCloud ID in iCloud setting section of backup and restore page.
INJI- Error message is not proper when invalid QR is scanned after changing language to other than English.
INJI - Backup & restore Name Is Different In Settings And in Backup & restore Page
INJI - Help Icon Language not Changing when we select other language that english
Backup and Restore heading Alignment is not proper in Backup& restore page
IOS - Associated app ID is missing in the Backup and restore page.
INJI- Sometimes VC activate the button and back button responses is very slow
INJI - Iderpo UINs are failing in VC verification
INJI - Backup doesn't append the new data, but replaces the data
Upon changing the finger authentication in the device, application does not display the error pop up for biometrics change
Release Name: Inji 0.11.0-Inji
Support: Developer Release
Release Date: 29th March, 2024
We are excited to announce the release of Inji Version 0.11.0 . This release is compatible with v0.11.0 Mimoto release. As part of 0.11.0, Inji introduces below mentioned key features:
VC download using KBI
Data backup and restore
Improved UI / UX
In the recent past, Inji Wallet app had undergone GenderMag analysis which addresses gender / inclusivity bias in software. In this release, we have incorporated GenderMag features for UI / UX in inclusivity space.
To know more about the GenderMag UI/UX changes in the application, please refer here.
Please find below the details for the Inji Version 0.11.0 release:
Inji Wallet has proven capability to integrate with any credential issuer supporting OpenID protocol and issues Verifiable Credentials (VCs) based on OpenID4VCI standards. To demonstrate the implementation of VC download using KBI (Knowledge Based Identification), Inji Wallet when integrated with eSignet 1.4.0, can connect with any issuer preferring KBI-based identification.
To know more about, KBI, refer here.
Inji Wallet currently offers data backup and restore functionality using Google Drive for Android and iCloud for iOS to safely store residents' Verifiable Credentials(VCs) on resident's preferred cloud platform. This ensures security and accessibility. Resident can also easily restore backed up information as required, and thereby enabling seamless user experience whether the resident uses Android or iOS.
The GenderMag Method is a process and also a set of materials helpful in investigating gender biases during resident's problem-solving experiences with software. Gendermag adheres to Human Computer Interaction (HCI) principles and thereby factor in gender differences interaction with software. As part of GenderMag walkthrough, we have identified inclusivity bugs with respect to UI / UX in Inji Wallet. Version 0.11.0 includes UI / UX changes for P1 items.
Repositories
Tags Released
Inji
mimoto
tuvali
mosip-config
Secure-Keystore
mosip-onboarder
Redmi devices are not supported in this release. To know more, refer here.
Mentioned below is the list of other known issues.
Android- Occasionally, unable to activate the restored VC
Inji-Unable to download when user attempted to restore VCs in a new device
INJI- Unable to download the card with a new UIN
IOS - Upon sharing sunbird VC twice and then upon sharing Mosip VC, app crashes
Android - During face authentication, app crashes on a specific device
INJI - Backup doesn't append the new data, but replaces the data
Android- Specific device, Redmi 7A- During face authentication, app crashes
Redmi 6A device is not compatible with Inji's Tuwali version
Upon changing the finger authentication in the device, application does not display the error pop up for biometrics change
Android - All downloaded VC's are deleted in specific device
Inji- Even upon Wallet failure, the verifier receives success message on the specific devices
Android - Couldn't share VCs between Two specific android devices
Android - Unable to share VC for specific combination
Android - VC transfer fails intermittently for specific device
Inji- The Inji application is not stable. Occasionally, unable to activate the VC
Verifier app crashes upon face authentication
Inji - Unable to save received VC error. Displays as Identity proofs are tampered
Unable able to retrieve VID / UIN from the AID which is raised through pre-registration process
Android - Couldn't share VC between two specific android devices as device crashes
Ios - Redmi 6A doesn't connect with any IOS devices
Android - Redmi 6A idoesn't connect with any android devices
Error message for Invalid OTP is not correctly displayed during VC activation
Critical
Inji - App crashes during click of OTP re-send button of download through AID
Critical
Android - Received VC's are deleted
Critical
Android - App crashes during the first launch
Critical
Inji- Occasionally, user is unable to share immediately
Major
Inji-During activation, VC in ID details page displays the green color toaster message on home screen
Major
Inji- MOSIP logo changes according to the issuer
Major
Inji - Deleted VC's HMAC data is not deleted
Major
Inji-Paragraph border is displayed in color, orange for purple theme selection
Major
Loading time for VC is longer than expected time
Major
Inji- VC sharing is failing intermittently using selfie with share feature
Major
App closes upon re-send code during VC activation through kebab popup
Release Name: Inji 0.12.0
Support: Developer Release
Release Date: 31st May, 2024
We are delighted to announce the release of Inji Wallet Version 0.12.0 . This release is compatible with v0.12.0 Mimoto release. As part of 0.12.0, Inji Wallet introduces below mentioned key features:
1. Features added to the Download Functionality:
Credential Type Selection
VC Verification
QR Code Generation for VC
2. Library:
QR Code Generation: PixelPass
3. UI/UX Enhancements:
Card View UI Changes
VC Share Optimization
Activity Log Enhancements
GenderMag Fixes
4. Data Backup Enhancements
Inji Wallet app addresses gender / inclusivity bias in software through GenderMag analysis. In this release, we have incorporated GenderMag fixes for UI / UX in inclusivity space.
To know more about the GenderMag UI/UI changes in the Inji Wallet application, please refer here.
Please find below the details for the Inji Version 0.12.0 release:
Inji Wallet now allows users to select the type of credential they need, giving them the option to choose from a list of Credential Types issued by the ID provider. This enables users to download Verifiable Credentials that match their selection.
Inji Wallet provides the functionality to verify Verifiable Credentials using the Digital Bazaar library. The issuer's signature is verified based on the proof type provided by the issuer. Currently, we support the RSA signature type, and we will soon add support for the Ed25519 proof type.
To prevent failures during download caused by verification of Verifiable Credentials with any other signature type, this step needs to be bypassed. Learn more about the steps here.
PixelPass, part of the Inji Credentialing stack, generates QR codes for Verifiable Credentials within the Inji Wallet. It's specifically designed for smaller data sets when the ID provider doesn't send a QR code along with the Verifiable Credential. Users can view and use this QR code for verification purposes by the relying party or service provider.
To know more about QR code verification, read about Inji Verify here.
QR Code Generation: PixelPass
To read more about PixelPass library refer here.
Inji Wallet version 0.12.0 introduces enhanced UI to deliver a seamless user experience with an intuitive design. The UI modifications included in this release are:
Card View UI Changes:
Users can now view the card in two ways:
A mini view on the Home Page with a quick access menu.
A detailed view.
Additionally, the Settings menu has been moved to the NavBar for easier access.
VC Share Optimization:
With the quick access menu in the mini view of the card:
Users can quickly initiate a Share or Share with Selfie action from the card to be shared.
Activity Log enhancements:
The audit logs have been enhanced to elevate the user experience. Now, they include the card type, along with the card number and the action performed, for better readability.
GenderMag P2 items:
Enhanced text to clarify the next steps and reasons for permission requests.
Improved user experience by providing clear notifications for success or failure, including a success screen or error banner with the reason for failure during VC sharing and face verification.
As part of the 0.12.0 release, the following enhancements have been made to the Data Backup feature:
Cloud as the Primary Source:
The backup file stored in the cloud will be the primary source of truth.
Once the backup file is downloaded and restored, it is automatically removed from the local app storage to ensure that the latest backup file is always restored.
iCloud Section Visibility:
The iCloud Section is now visible in the Backup & Restore settings screen, allowing users to easily manage their backup.
User Notification:
When the user initiates a Backup or Restore process, a banner will be displayed to inform users about the ongoing process.
Repositories
Tags Released
Inji
mimoto
mosip-config
Redmi devices are not supported in this release. To know more, refer here.
Mentioned below is the list of other known issues.
IOS -Specific devices the User not able to see the iCloud ID in iCloud setting section of backup and restore page.
INJI- Error message is not proper when invalid QR is scanned after changing language to other than English.
INJI - Backup & restore Name Is Different In Settings And in Backup & restore Page
INJI - Help Icon Language not Changing when we select other language that english
Backup and Restore heading Alignment is not proper in Backup& restore page
IOS - Associated app ID is missing in the Backup and restore page.
Inji- Date format is not proper in the e-signet Vc
INJI- Sometimes VC activate the button and back button responses is very slow
INJI - VC getting created without image while generating the UIN with lower and higher iso files.
Android - Intermediately while doing the face authentication the app is getting crashed
INJI - Iderpo UINs are failing in VC verification
Inji - Screen header and back button are overlapping
INJI - onboarding of new issuer is affecting the existing issuers
Inji- In specific devices, the Pin and Unpin feature is not working.
Android- Occasionally, unable to activate the restored VC
IOS - Upon sharing sunbird VC twice and then upon sharing Mosip VC, app crashes
Android - During face authentication, app crashes on a specific device
INJI - Backup doesn't append the new data, but replaces the data
Upon changing the finger authentication in the device, application does not display the error pop up for biometrics change
Below are the list of fixes as part of 0.12.0 release:
Blocker
inji - we are observing a download error message
Critical
Inji-Downloading error is observed when we were trying to restore VCs in a new device.
Critical
INJI- after deleting the backed up data it is not reflecting in the app
Critical
INJI - we are able to restore when there is no data to restore
Critical
IOS - app is not responsive in few senarios
Critical
INJI - once we delete a restored VC, we are not able to delete or pin other restore VC
Critical
IOS - device specific data is backuped if the Icloud is shared in multiple device
Critical
IOS - in specific device we are not able to restore VC
Critical
IOS- While deleting a single VC all downloaded VCs are getting deleted
Critical
INJI- The Backup button and restore button both are clickable at the same time
Critical
INJI - face auth is not working in room brightness on all devices
Critical
Getting tampered error pop up without tampering any vc in Vivo Y73.-- update: all devices
Critical
Inji- The Inji application is not stable sometimes we are not able to activate the VC
Major
INJIUI :- share button text is not translating to another language for ios
Major
Backup and restore screen the back button's response is slow.
Major
INJI- sunbird Vc is not rendering properly for a few second in sharing card page and received card page
Major
VC Select screen appears in a flash when the user clicks on Share from NavBar after navigating to Home page from the ID Transfer successful screen.
Major
android - receive card header is fully in caps
Major
INJI - few elements are not changing when the app converted to rtl
Major
Inji- We are missing the face validating popup and the Face match successfully popup.
Major
"Id details" section of downloaded card through e-signet don't have green tick mark in status.
Minor
Inji-In the intro sliders, the heading on the backup data page mentions "Data Backup."
Minor
INJI - The date format for downloaded and received are different for the same VC.
Minor
Inji- In download id screen enter the random 10 digits number it was showing UIN/VID/AID is invalid.
Minor
IOS- After downloading the sunbird Vc Unwanted space in between tick icon and valid
Minor
INJI-There was a glitch on previous connected screen for a second.
Release Name: Inji Wallet 0.14.0
Release Type: Developer Release
Release Date: 25th Nov, 2024
We are excited to announce the release of Inji Wallet Version 0.14.0! This update introduces major enhancements and new features, particularly in credential issuance. Here are the key highlights of this release:
PixelPass Enhancements: Support for CBOR encoding/decoding is available, making PixelPass more versatile and efficient in handling data.
Integration with Inji Certify: We've integrated eSignet for authentication and Certify for streamlined credential issuance, providing a seamless experience.
Compliance with Draft 13 of the OpenID4VCI Spec: Inji Wallet now fully supports the latest Draft 13 changes of the OpenID4VCI specification, ensuring compatibility with the evolving standards in the industry.
Java upgrade in mimoto: A significant tech upgrade for mimoto to move from java11 to java21.
Theme Upgrade:
A Gradient Look and Feel: Introducing a sleek gradient-based design as the new default theme for Inji Wallet. This theme offers a modern and visually appealing user experience, enhancing usability and aesthetic appeal.
PixelPass enhancements - Support CBOR encoding/decoding
Given JSON data, it does the CBOR encode/decode.
Given a JSON and a Mapper(similar to claim 169) are given, it maps the JSON with Mapper and then does the CBOR encode/decode.
Integrate eSignet for Auth and Certify for credential issuance
Authorisation partner: eSignet
KBI plugin: eSignet
Credential Issuance: Certify
Draft 13 changes of OpenID4VCI spec - Compatibility of the credential issuance as per the latest draft of OpenID4VCI specification.
Repositories
Tags Released
Inji-wallet
Inji-vci-client-ios-swift
The following table outlines the tested and certified compatibility of Inji Wallet 0.14.0 with other modules.
Module
Version
Mimoto
Inji-config
eSignet
Inji Verify
tuvali
tuvali-ios-swift
secure-Keystore
pixelpass
pixelpass-ios-swift
Inji-vci-client
Below is the list of known issues. To read in detail and view all the issues related to Inji Verify please click here.
Note: Redmi devices are not supported in this release.
Inji Wallet- After clicking the + icon, the screen flickers before landing on the 'Add New Card' screen
The search box close button is not working unless invoked on a specific point
Inji Wallet- Android - History timings could be more precise
IOS- The Wallet app session should expire if the app is opened for a longer time and the user tries to log in again with the PIN to generate VC by using UIN/VID.
Inji Wallet- The error message of QR code login without an internet attempt should be revised
Inji Wallet- On the face verification page the capture button overlaps with the text
Inji Wallet- During face authentication, the camera view is not opening in all IOS device
Inji Wallet - IOS - "Share QR Code" is not working on iPhone 8.
Inji Wallet - Backup is not triggering automatically when VC is removed.
Inji Wallet- the logo of Inji Wallet stretched while booting the app
IOS -For specific devices, the User cannot see the iCloud ID in the iCloud setting section of the backup and restore page.
Inji Wallet - An error message is not proper when an invalid QR is scanned after changing the language to something other than English.
Inji Wallet- Backup & restore Name Is Different In Settings And Backup & restore Page
Backup and Restore heading Alignment is not proper on the Backup& restore page
Inji Wallet- Sometimes VC activate the button and the back button responses are very slow
Inji Wallet- ID Repo UINs are failing in VC verification
Inji Wallet- Backup doesn't append the new data but replaces the data
Upon changing the finger authentication in the device, the application does not display the error pop-up for biometrics change
Below is the list of fixes as part of the 0.14.0 release:
Jira issue
Issue description
Inji Wallet: When the camera access is disabled, the user clicks on the close icon error screen it redirects to the sharing screen
Inji Wallet - Unable to go back from the detailed view page
Inji Wallet- VC verification is passing for missing attribute VC
Inji Wallet- During face authentication, the camera view is wider than the face.
Inji Wallet - IOS - The "Share QR Code" feature saves both the QR Code and a text file to files.
Inji Wallet- Users are unable to upload the VC QR code shared via email and WhatsApp, or stored locally
Inji Wallet- In Android when the user clicks the + icon from the home page issuer page is not loaded
Inji Wallet - Unable to see the issuer of the credentials
Inji Wallet- Sunbird issuer is not loading and is redirecting to the 'Add New Card' screen. Trying to click any other issuer is also not working
Inji Wallet- The Intermittent share with selfie option is not getting for the National Identity department
Activation successful banner is not showing up
Inji Wallet- We are unable to download the VC Stay Protected insurance credential
Inji Wallet- When the Certify well-known is replaced with fall back well-known url in the Inji configuration The user is not redirected to the default well-known issuer
Inji Wallet- The user is not getting any error if the fallback is not working
Inji Wallet-Mock identity is not loading and is redirecting to the 'Add New Card' screen. Trying to click any other issuer is also not working
Activated option in quick access menu for VCs which doesn't have biometrics
Inji Wallet- In the mock VC, there is no profile photo, but the share option is still visible
When display properties are removed at mosip certify the user is blocked with a white screen and not able to use the app.
Update mimoto local properties file to run mimoto locally without docker-compose
Background colour not showing up in VC as per configuration in well-known
Release Name: Inji 0.11.0
Upgrade From: Inji 0.10.0
Support: Support Release
Release Date: 23rd February, 2024
We are excited to announce the first independent release of Mimoto, officially named version 0.11.0. This release is built upon Inji 0.10.0 and primarily focuses on the following:
Onboarding a new VC Issuer
Mimoto-Issuer onfiguration changes
Please find below the details for the 0.11.0 release:
Mimoto-Issuer configuration changes: Changes to authentication and well-known configuration details will be included in the mimoto-issuers configuration. To know more, refer here.
Repositories
Tags Released
mimoto
mosip-config
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, the 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, verification scope required comprehensive automation testing for all the MOSIP APIs. An automation Test Rig is created for the same.
The Inji Wallet
testing scope revolves around the following flows:
Biometric unlock
Passcode unlock
VC download via MOSIP
VC download via eSignet
Retrieving UIN via AID
Pinning a VC
Normal VC sharing with VID
Deleting VC
Face Auth on Resident's phone with VID
Multi language support
Credential registry
Backup and restore
Wallet binding
QR code Login
Logout
Persona based approach has been adopted to perform the IV&V(Independent Verification and Validation) by simulating the 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.
For regression check, MOSIP Test Rig
, an automation testing suite is indigenously designed and developed for supporting persona based testing. MOSIP Test Rig covers the end-to-end test execution and reporting. The end-to-end functional test scenarios are written starting from pre-registration, to creation of packet in registration center, processing the packet through the registration processor, generating UIN and authenticating identity using IDA through various permutation and combinations of cases being covered. MOSIP Test Rig will be an open source artifact which can also be enhanced and used by countries to validate the SI deliveries before going live. Persona classes include both negative and positive personas. Negative persona classes include users like Bribed Registration Office, Malicious Insider etc. The needs of positive persona classes must be met, whereas the needs of negative persona classes must be effectively restricted by the software.
Verification is performed on various configurations as mentioned below.
Default configuration - with 3 Languages
Virtual countries
1 language configuration
2 language configuration
3 language configuration
Below are the test metrics for Inji Wallet by performing functional testing using mockMDS
and mockABIS
. 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 inline 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 languages and configurations. The testing cycle included simulation of multiple identity schema and respective UI schema configurations.
Total
Passed
Failed
Skipped
1823
1610
169
44
Test Rate: 97.60% with Pass Rate: 88.31%
Here is the detailed breakdown of metrics:
Total Test cases: 950
Passed: 810
Failed: 114
Skipped (N/A): 26
Total Test cases: 873
Passed: 800
Failed: 55
Skipped: 18
Below section provides details on API test metrics by executing MOSIP functional automation Framework. All external API test executions were performed at module level isolation. Each endpoint is tested with the test data and expectations of each test data are mapped to assert the test case.
Total
Passed
Failed
Skipped
1436
1353
68
13
Test Rate: 99.09% with Pass Rate: 94.22%
Here is the detailed breakdown of metrics:
Total
Passed
Failed
Skipped
157
143
14
0
Total
Passed
Failed
Skipped
1279
1210
54
13
Below section provides details on UI Automation by executing MOSIP functional automation Framework.
Total
Passed
Failed
Skipped
128
112
16
0
Test Rate: 100% with Pass Rate: 87.50%
Here is the detailed breakdown of metrics
Total
Passed
Failed
Skipped
72
64
8
0
Total
Passed
Failed
Skipped
56
48
8
0
Functional and test rig code base branch which is used for the above metrics is:
Hash Tag: sha256 : f010aee8b1e7f25cfb2284b20779cb5b8b6bd2efdd8a22b1e3c6d3a20194411a
Below are the test metrics by performing VC Sharing functionality on various device combinations.
Total
Passed
Failed
Skipped
213
155
61
0
Test Rate: 100% with Pass Rate: 72.8%
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
Link for the detailed test report
Release Name: Inji 0.10.0
Upgrade From: Inji 0.9.0
Support: Developer Release
Release Date: 19th December, 2023
We are pleased to announce the release of Inji Version 0.10.0. This release builds upon Inji 0.9.1, introducing key features and improvements.
OpenID Support for Verifiable Credentials: Inji 0.10.0 introduces support for OpenID, facilitating the issuance of verifiable credentials.
Enhanced Security for Personally Identifiable Information (PII) Data: A significant focus has been placed on reinforcing security measures related to Personally Identifiable Information (PII) data.
Facial Recognition for Transaction Authorization: This version introduces advanced facial recognition capabilities to elevate the security of transaction authorization processes.
Improved UI/UX: User Interface (UI) and User Experience (UX) have undergone refinement to provide users with an intuitive and aesthetically pleasing interaction.
Application ID (AID): Inji 0.10.0 now includes an Application ID, contributing to streamlined identification and tracking.
Below is the detailed summary of the release.
A redesigned interface promises improved usability and a more intuitive experience.
Navigation buttons have been updated to prominently display primary functionalities.
Secondary functionalities, such as viewing received Verifiable Credentials (VC) and displaying QR codes, have been relocated under the settings menu for a streamlined experience.
The introduction of new and detailed error messages, along with app warnings, aims to enhance transparency and overall usability.
Securely stored encryption of private keys using the Android hardware keystore for heightened security.
Implemented hash algorithms for verifying the integrity of downloaded and received Verifiable Credentials (VCs).
Enhanced password security with the implementation of password hashing algorithms.
App now proactively responds to security breaches by initiating a self-reset or eliminating tampered Verifiable Credentials (VCs).
Inji now seamlessly integrates with OpenID, expanding support for Verifiable Credentials (VC).
The app is now equipped to onboard Identity Providers (IdP), offering users a choice when interacting with issuers.
Introduces new screens allowing users to select issuers before downloading Verifiable Credentials (VC).
eSignet and MOSIP have been successfully onboarded as Identity Providers within Inji.
Inji now employs advanced facial recognition libraries for secure and seamless authorization of Verifiable Credential (VC) transfers.
A unique application ID is now associated with each unique installation of Inji. It is made accessible to the users.
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, the 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, verification scope required comprehensive automation testing for all the MOSIP APIs. An automation Test Rig is created for the same.
The Inji Wallet
testing scope revolves around the following flows:
Biometric unlock
Passcode unlock
VC download via MOSIP
VC download via eSignet
Retrieving UIN/VID via AID
Pinning a VC
Normal VC sharing with VID
Deleting VC
Face Auth on Resident's phone with VID
Multi language support
Wallet binding
QR code Login
Logout
Persona based approach has been adopted to perform the IV&V(Independent Verification and Validation) by simulating the 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.
For regression check, MOSIP Test Rig
, an automation testing suite is indigenously designed and developed for supporting persona based testing. MOSIP Test Rig covers the end-to-end test execution and reporting. The end-to-end functional test scenarios are written starting from pre-registration, to creation of packet in registration center, processing the packet through the registration processor, generating UIN and authenticating identity using IDA through various permutation and combinations of cases being covered. MOSIP Test Rig will be an open source artifact which can also be enhanced and used by countries to validate the SI deliveries before going live. Persona classes include both negative and positive personas. Negative persona classes include users like Bribed Registration Office, Malicious Insider etc. The needs of positive persona classes must be met, whereas the needs of negative persona classes must be effectively restricted by the software.
Below are the test metrics for Inji Wallet by performing functional testing using mockMDS
and mockABIS
. 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 inline 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 languages and configurations. The testing cycle included simulation of multiple identity schema and respective UI schema configurations.
Test Rate: 95% with Pass Rate : 82%
Here is the detailed breakdown of metrics:
Total Test cases: 602
Passed: 476
Failed: 99
Skipped: 27
Total Test cases: 485
Passed: 387
Failed: 78
Skipped: 20
Below section provides details on API test metrics by executing MOSIP functional automation Framework. All external API test executions were performed at module level isolation. Each endpoint is tested with the test data and expectations of each test data are mapped to assert the test case.
Test Rate: 100% with Pass Rate: 99.52%
Here is the detailed breakdown of metrics:
Note:
Functional and test rig code base branch which is used for the above metrics is:
Commit Id is: 103e0606
Hash Tag: afedb56a2977844286bc4cbfedb8263507efa823a3d7d5a7b3cbd601ac22d120
Below are the test metrics by performing VC Sharing functionality on various device combinations.
Test Rate: 100% with Pass Rate : 100%
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
Mimoto can be deployed in local using Docker Compose setup. This service streamlines deployment and management, offering a seamless and efficient way to handle backend operations.
Below sections details the docker-compose setup to run mimoto which act as BFF for Inji Wallet and backend for Inji web. This docker compose setup is intended only for local use and not for production deployment.
The 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.
"loader_path" this has mimoto mount volume from where all the runtime dependencies are loaded to classpath.
"docker-compose.yml" file contains the mimoto setup.
Copy the downloaded jar under loader_path directory and rename it to kernel-auth-adapter.jar
Add ID providers as issuers in mimoto-issuers-config.json
Start esignet services and update esignet host references in mimoto-default.properties and mimoto-issuers-config.json
Update client_id and client_alias in mimoto-issuers-config.json file.
Update p12 file password mosip.oidc.p12.password in mimoto-default.properties file.
To start the docker-compose file, run the command docker-compose up
The mimoto APIs can be accessed as below:
http://localhost:8099/residentmobileapp/allProperties
http://localhost:8099/residentmobileapp/issuers
http://localhost:8099/residentmobileapp/issuers/Sunbird
http://localhost:8099/residentmobileapp/issuers/Sunbird/credentialTypes
For local env use ngrok.
token_endpoint in mimoto-issuers-config.json
mosipbox.public.url, mosip.api.public.url in mimoto-default.properties
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, the 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, verification scope required comprehensive automation testing for all the MOSIP APIs. An automation Test Rig is created for the same.
The Inji Wallet
testing scope revolves around the following flows:
Biometric unlock
Passcode unlock
VC download via MOSIP
VC download via eSignet
Retrieving UIN/VID via AID
Pinning a VC
Normal VC sharing with VID
Deleting VC
Face Auth on Resident's phone with VID
Multi language support
Wallet binding
QR code Login
Logout
Persona based approach has been adopted to perform the IV&V(Independent Verification and Validation) by simulating the 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.
For regression check, MOSIP Test Rig
, an automation testing suite is indigenously designed and developed for supporting persona based testing. MOSIP Test Rig covers the end-to-end test execution and reporting. The end-to-end functional test scenarios are written starting from pre-registration, to creation of packet in registration center, processing the packet through the registration processor, generating UIN and authenticating identity using IDA through various permutation and combinations of cases being covered. MOSIP Test Rig will be an open source artifact which can also be enhanced and used by countries to validate the SI deliveries before going live. Persona classes include both negative and positive personas. Negative persona classes include users like Bribed Registration Office, Malicious Insider etc. The needs of positive persona classes must be met, whereas the needs of negative persona classes must be effectively restricted by the software.
Verification is performed on various configurations as mentioned below:
Default configuration - with 3 languages
Virtual countries
1 Lang configuration
2 Lang configuration
3 Lang configuration
Below are the test metrics for Inji Wallet by performing functional testing using mockMDS
and mockABIS
. 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 inline 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 languages and configurations. The testing cycle included simulation of multiple identity schema and respective UI schema configurations.
Test Rate: 96% with Pass Rate: 86%
Here is the detailed breakdown of metrics:
Total Test cases: 733
Passed: 625
Failed: 76
Skipped: 32
Total Test cases: 661
Passed: 541
Failed: 100
Skipped: 20
Below section provides details on API test metrics by executing MOSIP functional automation Framework. All external API test executions were performed at module level isolation. Each endpoint is tested with the test data and expectations of each test data are mapped to assert the test case.
Test Rate: 100% with Pass Rate: 98.34%
Here is the detailed breakdown of metrics:
Note:
Functional and test rig code base branch which is used for the above metrics is:
Commit Sha: 6641489c9ea2129daaf6989c7e6d73bae528a4c0
Below section provides details on UI test metrics by executing MOSIP UI Automation Framework. Test executions were performed at module level isolation. Each end point is tested with the test data and expectations of each test data are mapped to assert the test case.
Here is the detailed breakdown of metrics:
Below are the test metrics by performing VC Sharing functionality on various device combinations.
Test Rate: 100% with Pass Rate: 100%
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
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.
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, Verification scope required comprehensive automation testing for all the MOSIP APIs. An automation Test Rig is created for the same.
The Inji testing scope revolves around the following flows:
Biometric unlock
Passcode unlock
VC download via MOSIP
VC download via esignet
VC download via Sunbird
Retriving UIN/ via AID
Pinning a VC
Normal VC sharing with VID
Deleting VC
Face Auth on Resident's phone with VID
Multi language support
Credential registry
Backup and restore
Wallet binding
QR code Login
Logout
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.
For regression check, “MOSIP Test Rig” - an automation testing suite - which is indigenously designed and developed for supporting persona based testing. MOSIP Test Rig covers the end to end test execution and reporting. The end to end functional test scenarios are written starting from pre-registration, to creation of packet in registration center, processing the packet through the registration processor, generating UIN and authenticating identity using IDA through various permutation and combinations of cases being covered. MOSIP Test Rig will be an open source artifact which can also be enhanced and used by countries to validate the SI deliveries before going live. Persona classes include both negative and positive personas. Negative persona classes include users like Bribed Registration Office, Malicious Insider etc. The needs of positive persona classes must be met, whereas the needs of negative persona classes must be effectively restricted by the software.
Verification is performed on various configurations as mentioned below
Default configuration - with 3 Lang
Virtual countries
1 Lang configuration
2 Lang configuration
Lang configuration
On Android Device:
On iOS Device:
Below are the test metrics by performing functional testing using mock MDS and mock ABIS. 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 languages and configurations. The testing cycle included simulation of multiple identity schema and respective UI schema configurations.
Here is the detailed breakdown of metrics for each module:
Below section provides details on API test metrics by executing MOSIP functional automation Framework. All external API test executions were performed at module level isolation. Each end point is tested with the test data and expectations of each test data are mapped to assert the test case.
Here is the detailed breakdown of metrics
Below section provides details on Ui Automation by executing MOSIP functional automation Framework.
Here is the detailed breakdown of metrics
Functional and test rig code base branch which is used for the above metrics is:
Hash Tag:
SHA: sha256:c2a71c11f19a6585e6cfd3ae8ab70130babb2077e27714f5fc225b986e7c14d0
Below are the test metrics by performing VC Sharing functionality on various device combinations
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
Release Name: Inji vDP1
Upgrade From: Inji 0.9.1 (Patch)
Support: Developer Preview Release1
Release Date: 28th September, 2023
The developer preview version of Inji Wallet is the release on top of Inji 0.9.1. Key highlights of the release are:
Enhanced UI
Additional functional flows in Inji
Internal enhancements
Bug fixes
Below is the detailed summary of the release.
New UI for Inji Wallet:
This redesign promises an enriched user experience.
Introduction sliders have been introduced.
Helpful FAQ screens are provided.
VC pinning is now available.
Currently, the pinning feature supports a single VC.
Easy VC removal from Inji Wallet.
Improved audit log filtering based on VC.
Branding the App as Inji Wallet
:
We've rebranded the application, transitioning from Resident App
to the more streamlined and recognisable Inji Wallet
.
Ability to Choose Language During App Setup:
Inji Wallet app users can configure the application in six distinct languages:
English
Filipino
Arabic
Hindi
Kannada
Tamil
Warning When Device Storage is Beyond the Threshold:
Inji Wallet now offers customisable storage limits:
For VC downloads, the threshold is set to 5MB. When the device's remaining storage space falls below this limit, Inji Wallet displays a warning message. However, users can still continue to verify and share VCs.
For Inji Wallet audit logs, the threshold is set to 1MB. Once the device reaches this limit, Inji users will be restricted to viewing VCs, unable to perform additional actions.
Traceability with Unique ID for Customer Support:
We've implemented a unique identification called as an Application ID for customer support interactions. Each support request is now assigned a traceable and distinct ID, allowing our support teams to efficiently track, manage, and resolve customer issues.
Improved Bluetooth State and Permission Handling:
We have refined the management of Bluetooth states and permissions.
Removed Google Nearby
Implementation:
Encrypted VC’s Metadata:
We now calculate and securely store an encrypted HASH (HMAC SHA256) of the VC's metadata key in the database, bolstering data security.
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, the 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, verification scope required comprehensive automation testing for all the MOSIP APIs. An automation Test Rig is created for the same.
The Inji Wallet
testing scope revolves around the following flows:
Biometric Unlock
Passcode Unlock
VC download with VID
Renaming VC / Edit tag for VID
Normal VC sharing with VID
Online and Offine mode sharing
Face Auth on Resident's phone with VID
Multi language support
Wallet binding
QR code Login
Persona based approach has been adopted to perform the IV&V(Independent Verification and Validation) by simulating the 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.
For regression check, MOSIP Test Rig
, an automation testing suite is indigenously designed and developed for supporting persona based testing. MOSIP Test Rig covers the end-to-end test execution and reporting. The end-to-end functional test scenarios are written starting from pre-registration, to creation of packet in registration center, processing the packet through the registration processor, generating UIN and authenticating identity using IDA through various permutation and combinations of cases being covered. MOSIP Test Rig will be an open source artifact which can also be enhanced and used by countries to validate the SI deliveries before going live. Persona classes include both negative and positive personas. Negative persona classes include users like Bribed Registration Office, Malicious Insider etc. The needs of positive persona classes must be met, whereas the needs of negative persona classes must be effectively restricted by the software.
Below are the test metrics for Inji Wallet by performing functional testing using mockMDS
and mockABIS
. 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 inline 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 languages and configurations. The testing cycle included simulation of multiple identity schema and respective UI schema configurations.
Test Rate: 100% with Pass Rate : 88%
Here is the detailed breakdown of metrics:
Total Test cases: 185
Passed: 177
Failed: 8
Skipped: 0
Total Test cases: 174
Passed: 142
Failed: 32
Skipped: 0
Below section provides details on API test metrics by executing MOSIP functional automation Framework. The external API test executions were performed at module level isolation. Each end point is tested with the test data and expectations of each test data are mapped to assert the test case.
Test Rate: 100% with Pass Rate : 97%
End-to-end flows are a set of stateful test cases that expects the results across multiple modules. The test does not cover the intermediary stages, rather concentrates on the end result for a given data. The test covers both negative scenarios and positive scenarios with real world scenarios. Below are the end-to-end scenarios test metrics by executing MOSIP Automation Framework.
Test Rate: 100% with Pass Rate: 75%
Below are the test metrics by performing VC Sharing functionality on various device combinations.
Test Rate: 100% with Pass Rate : 83%
Below are the detailed test metrics by performing manual/ automation testing. The project metrics are derived from Defect density, Test coverage, Test execution coverage, test tracking and efficiency.
The various metrics that assist in test tracking and efficiency are as follows:
Passed Test Cases Coverage: It measures the percentage of passed test cases. (Number of passed tests / Total number of tests executed) x 100
Failed Test Case Coverage: It measures the percentage of all the failed test cases. (Number of failed tests / Total number of test cases executed) x 100
The 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, the 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, verification scope required comprehensive automation testing for all the MOSIP APIs. An automation Test Rig is created for the same.
In this release, the testing scope has been focused around the hotfixes for Inji Wallet along with the addition of the below new features:
Moving away from Google Nearby API definitions
Optimization of Save VC flow
Persona based approach has been adopted to perform the IV&V(Independent Verification and Validation) by simulating the 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.
For regression check, “MOSIP Test Rig”- an automation testing suite - which is indigenously designed and developed for supporting persona based testing. MOSIP Test Rig covers the end to end test execution and reporting. The end to end functional test scenarios are written starting from pre-registration, to creation of packet in registration center, processing the packet through the registration processor, generating UIN and authenticating identity using IDA through various permutation and combinations of cases being covered. MOSIP Test Rig will be an open source artifact which can also be enhanced and used by countries to validate the SI deliveries before going live. Persona classes include both negative and positive personas. Negative persona classes include users like Bribed Registration Office, Malicious Insider etc. The needs of positive persona classes must be met, whereas the needs of negative persona classes must be effectively restricted by the software.
Verification is performed on various configurations as mentioned below:
Default configuration (with 6 languages)
Below are the test metrics by performing functional testing using mockMDS and mockABIS. 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 languages and configurations. The testing cycle included simulation of multiple identity schema and respective UI schema configurations.
Test Rate: 95% with Pass Rate : 89%
Here is the detailed breakdown of metrics for each module:
Total Test cases: 206
Passed: 185
Failed: 17
Skipped: 4
Total Test cases: 190
Passed: 152
Failed: 23
Skipped: 15
Below section provides details on API test metrics by executing MOSIP functional automation Framework. All external API test executions were performed at module level isolation. Each end point is tested with the test data and expectations of each test data are mapped to assert the test case.
Test Rate: 100% with Pass Rate : 96%
Below are the test metrics by performing VC Sharing functionality on various device combinations:
Test Rate: 100% with Pass Rate : 100%
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
Release Name: Inji vDP2
Upgrade From: Inji 0.10.0
Support: Developer Preview Release2
Release Date: 22nd January, 2024
The Developer Preview Version 2 release is an additional release on top of Inji 0.10.0. This release primarily emphasizes:
UI enhancements
Internal enhancements
Security fixes
Bug fixes
Below is the detailed summary of the release.
As a part of the VC sharing feature or listing of VCs for QR login, the Pinned VC will now appear on top of the VC list.
User can now provide one time consent for a selected VC while sharing the claims during QR code login.
Additionally, a search bar has been added to the Add new card
screen to improve user experience by allowing users to search for issuers based on the title.
Furthermore, any rendering issues in the user interface have been resolved.
Secure KeyStore and Tuvali have been integrated as independent NPM modules within the INJI framework. For further information, please refer to the provided documentation.
Additionally, all image assets have been converted from png
to svg
format. This transition ensures the presence of a single asset set, and the color of the icons will now be dynamically rendered based on the application's theme.
The critical vulnerabilities identified by OWASP dependency check have been addressed:
The expo-app-loading package has been replaced with expo-splash-screen for the purpose of app loading.
In order to enhance security for devices without hardware backed keystore, the crypto-js
package has been substituted with node-forge for encryption, decryption, and HMAC generation.
Redmi devices are not supported for this release. To know more, refer to .
The user will now be redirected to the MOSIP page successfully from the About INJI
screen. Earlier the link was crashing the app. #
The user will be able to login into eSignet portal via QR code, using the VC activated on Home screen via. ellipsis menu. #
App will prompt and remove tampered VC. #
The user will be asked for language preference only at new installation. #
Previously used UIN/VID will not be suggested in the AID field for VC download. #
The user will be able to see the detailed view of Received
VC. #
The user will be redirected to an intermittent downloading screen, when download is triggered from OpenID supported issuer. #
Link for the .
Create loader_path folder under the docker-compose directory and download the kernel auth adapter(kernel-auth-adapter-1.2.0.1.jar) from .
Create certs folder in the same directory and create OIDC client. Add key in oidckeystore.p12 and copy this file under certs folder. Refer to create client
Replace http://localhost:8099 by public domain at following places
Link for the .
Refer to know more about how you can explore 'Inji Wallet' in our 'sandbox collab environment'.
Github link for the xls file is .
We've transitioned to using for Bluetooth Low Energy (BLE) communication, enhancing the connectivity experience.
Bug fix: Reduced the app size for Android #
Bug fix: Resolved connectivity issue when sharing VC #
Bug fix: Fixed QR/ Esignet login using INJI app #,
Bug fix: Resolved BLE issues #,
To know more about Inji Wallet, watch the !
Link for the .
Link for the .
Efforts have been made to improve the security of data in the default file located in the mmkv
folder under the task.
To know more about Inji, watch the !
Repositories
Tags Released
mimoto
inji
tuvali
mosip-config
secure-keystore
mosip-onboarder
Total
Passed
Failed
Skipped
1087
863
177
47
Total
Passed
Failed
Skipped
1268
1262
6
0
Total
Passed
Failed
Skipped
154
152
2
0
Total
Passed
Failed
Skipped
1114
1110
4
0
Total
Passed
Failed
Skipped
40
40
0
0
Total
Passed
Failed
Skipped
1394
1166
176
52
Total
Passed
Failed
Skipped
1268
1247
17
4
Total
Passed
Failed
Skipped
154
152
2
0
Total
Passed
Failed
Skipped
1114
1095
15
4
Total
Passed
Failed
Skipped
102
61
41
0
Total
Passed
Failed
Skipped
52
36
16
0
Total
Passed
Failed
Skipped
50
25
25
0
Total
Passed
Failed
Skipped
152
152
0
0
Total
Passed
Failed
Skipped (N/A)
2118
1975
103
40
Test Rate: 98% With Pass Rate : 95%
Test cases
On Android Device
Total
1112
Passed
1005
Failed
81
Skipped (N/A)
26
On iOS Device
Total
1006
Passed
970
Failed
22
Skipped (N/A)
14
Total
Passed
Failed
Skipped
1436
1426
6
4
Test Rate: 99.72% With Pass Rate: 99.30%
Test cases
Mobile ID
Total
157
Passed
157
Failed
0
Skipped
0
eSignet
Total
1279
Passed
1269
Failed
6
Skipped
4
Total
Passed
Failed
Skipped
162
146
16
0
Test Rate: 100% With Pass Rate: 90.12%
Test cases
Android
Total
82
Passed
75
Failed
7
Skipped
0
iOS
Total
80
Passed
71
Failed
9
Skipped
0
Total
Passed
Failed
Skipped
213
155
61
0
Test Rate: 100% With Pass Rate: 72.8%
Repositories
Tags Released
Inji
Mimoto
Total
Passed
Failed
Skipped
359
319
40
0
Total
Passed
Failed
Skipped
37
36
1
0
Total
Passed
Failed
Skipped
84
63
21
0
Total
Passed
Failed
Skipped
192
160
32
0
Total
Passed
Failed
Skipped
396
337
40
19
Total
Passed
Failed
Skipped
154
149
5
0
Total
Passed
Failed
Skipped
192
192
0
0
Issue ID
Description
Unable to get error message when download retry count is updated to 10.
iOS - app data erased when we logout in offline.
We are not able to scan the e-signet QR code In iOS device.
App resets on re-launch after VC activation in iOS.
Logout not working in iOS version of Inji.
iOS - language preference is again asked when we logged out of the app.
UIN of previously downloaded VC is wrongly pre-filled in AID screen.
VC sharing is failing intermittently on Android.
Pinned VC's audit logs are missing.
Issue ID
Description
Android - app crashing while saving VC from eSignet, if the hardware keystore is rejected by user.
Android- The Inji app is crashing intermediately.
Issue ID
Description
Android - specific verifier is not connecting with wallet.
Cross-platform - App couldn't recognize if the Bluetooth is turned off while in connection state.
Android - We are able to receive VC even if we turned off Bluetooth in specific devices.
Handle timeout during VC share via BLE.
Issue ID
Description
The app couldn't recognize resident face when there are changes.
Issue ID
Description
iOS- once we share VC through share with selfie, we are not getting successful screen in the wallet.
iOS - Loading Screen is missing after Face Auth.
Button name in "Status" page is not matching as per the requirement provided.
The navigation button to go back from the ID details page is missing, not matching the wireframe provided.
While logging out for the first time the language selection and tour guide show up.
There is no popup to cancel the download card.
The back button is not working on few places of the app.
While sharing the VC, if we click on scan icon, application displays the camera.
Issue ID
Description
UI - text search field in Add new card screen does not match wireframe.
Not getting "setting up" message under loading screen (intermittent screen).
'+' icon used for downloading VC is occupying three dots ellipses of last VC.
The face authentication button is not as per the theme color.
A page from wireframe is missing in the application.
On 'Received Card' screen expanded view of VC is not working.
The successful QR code login audit is not matching the wireframe.
There are few elements still in color, orange in the purple theme.
The app is not aligned properly with the smaller display phone.
Share button is not aligned properly in iOS and Android.
"It is necessary" text in consent screen is getting overlapped with page slider in smaller devices.
Try again button is not aligned properly upon change language to Tamil (when no internet connection).
Intermittent: Getting double toaster message on home screen.
Capture button text is not getting displayed completely.
In the connecting page user is getting some orange color box.
The error pop-up is not user friendly and not matching the UI.
The Download pop-up should stay longer.
Time stamp should be removed in OTP screen once it is expired.
Repositories
Tags Released
Inji
config
Countries also have the option to customize Inji as per their requirements. Refer to the documents below for more information on the same.
The following customizations are available in Inji:
Workflow in Inji Wallet is achieved by finite-state machine components. State machines are written using a library called xstate. All the state machines are available in the machines folder of the Inji Wallet codebase. There are few machines under the screens folder but these are too specific to those features.
Here is a list of state machines and their responsibilities. The developers can choose to use the existing state machine components and customize the workflow as per their needs.
This is the root state machine for the application. On initialisation, it starts other state machines from:
store.ts
auth.ts
vcMetaMachine.ts
settings.ts
activityLog.ts
requestMachine.ts
scanMachine.ts
backup.ts
backupRestore.ts
This state machine takes care of actions related to storing and retrieving data on the mobile phone. It exposes the wrapper to all the other state machines to work with data stored on the device.
It also performs the custom encryption and decryption required for saving and retrieving data from the underlying store.
As of now, the store state machine uses following two libraries which abstracts how the data is stored between iOS and Android:
react-native-mmkv-storage - stores all the meta information and references of the encrypted VC.
react-native-fs - stores the encrypted VC as a separate file,
This state machine helps to set up authentication for the application. It allows users to choose between biometric and passcode-based authentication on the first launch. It also updates the app state as authorized or unauthorized based on user action on first launch.
On first launch, once the user selects language preference, and goes through intro sliders, user has been asked to choose the unlock method.
After selecting the unlock method as passcode or biometric, the user is navigated to Home screen Once user is on home screen, app state is considered as authorized. Once a user logs out from settings, the state is considered as unauthorized.
This state machine is spawned for every VC downloaded, and tracks its lifecycle. This contains all the activities/state related to VC like:
load VC
activate VC
activate/delete/pin/unpin VC
verifies the credentials
This state machine takes care of the all the meta information related to all VCs.
This state machine list of issuers in the user interface, as well as downloads and caches the issuer's configuration. It also performs the following actions:
download credential
verify the verifiable credential
store the verifiable credential
This state machine performs all action related to backing up of the verifiable credentials on google drive or iCloud.
This state machine performs all action related to restoring and verifying the backed up verifiable credentials from google drive or iCloud.
This state machine helps to show contents and interactions on the settings screen of the application. This facilitates options like language switch, enable/disable biometric unlock etc.
This state machine helps to view the audit log of the different activities on the application and shows it on a separate screen. Some of the activities that are shown are VC download, VC receive, VC sent events etc.
This state machine is instantiated when the user launches the verification section which displays the QR code. This QR is generated with content from a low-level offline VC-sharing component. The content of the QR code is scanned by a wallet Inji Wallet application to establish connection with verifier and share the VC credential. Once the VC is received on the Verifier side, the state machine allows seeing the received VC details as well for Verification.
This state machine is instantiated when the user launches the scanner section which opens up the camera to scan the QR code presented by the Verifier. The scanned data is fed into the underlying offline VC sharing component to allow the discovery of the Verifier device and establish a connection to it. Once the connection is established, the user is allowed to select the downloaded VCs that can be shared with Verifier. The state machine also allows selfie/face verification before sharing VC.
This state machine facilitates flow for Login with QR code
through Open ID connect from various portals. This is launched when the user opens up the scanner and scans a QR code from a website that supports login with Inji Wallet. Once the scan is performed, the user can review the required claims and select voluntary claims to be submitted. Once the submission is done successfully, the portal will be able to redirect automatically and logs the user in.
This is a utility state machine which is used to facilitate PIN/OTP login wherever required in the application.
This is a state machine which facilitates the interactions to face scanning. It is used to support face authentication in Login with a QR code, sharing with selfies flow.
This state machine facilitates toggling biometric unlock on/off settings screen. This also allows setting up and using biometric unlock for the application.
Inji Web, akin to the Inji Wallet, is a user-friendly web portal designed to facilitate the process of securely downloading, storing, managing and sharing Verifiable Credentials through a web interface. This easy-to-use platform enables users to access and store their credentials, ensuring confident presentation to service providers for verification and service access, with ease and reliability. Rooted by the principles of inclusivity, Inji Web endeavors to empower individuals to access benefits or services even without smartphones.
With its simple and intuitive interface, Inji Web offers features similar to the mobile wallet, catering to a variety of use cases. Whether you are a resident needing VCs for identity verification, a student seeking academic credentials, a professional verifying employment, or an organization enhancing business operations, Inji Web provides easy access to your credentials tailored to your specific needs.
By facilitating the issuance, verification and sharing of credentials in a secure and efficient manner, Inji Web plays a pivotal role in fostering trust amongst the service providers.
Inji Web application is built using the React framework and utilizes Mimoto as the BFF (Backend for Frontend). The digital verifiable credentials produced by the application adhere to the Verifiable Credentials (VC) Data Model.
Users can simply visit the Inji web portal, where they can select an issuer from the list of trusted options and choose the desired credential for download
To proceed, users are required to authenticate themselves by providing relevant information such as National ID, Registration Number, Name, Date of Birth, etc., enabling them to securely manage, store, and share the credential
Upon successful validation, the Verifiable credential is promptly downloaded as a PDF, along with a QR code issued by the Issuer
Once downloaded, users have the flexibility to share the Verifiable credential with relying parties either as a physical copy or by facilitating QR code scanning or uploading the PDF on the verifier site
As we progress, additional features are planned to be seamlessly integrated into Inji Web
Inji ensures the integrity of digital signatures provided by issuers for each ID before Verifiable Credentials are downloaded as PDFs within the system
Furthermore, Inji Web is designed to be compatible with the OpenID protocol, offering the flexibility to onboard various Identity Providers (IdP). This empowers users with multiple options for Verifiable Credential (VC) issuers
Backend systems
Inji Web interacts with:
Mimoto APIs for managing issuers details, facilitate VC download and generate PDF
eSignet APIs for authentication
To learn more about the Features provided by Inji Web, click here
For information on the Roadmap for Inji Web, click here.
Under locales
folder, localization of a particular language JSON file has to be added.
Language JSON has to be imported in i18n.ts
and load the resources to i18next as follows. import fil from './locales/fil.json';
const resources = { en, fil, ar, hi, kn, ta };
To ensure the language needs to be included in the const SUPPORTED_LANGUAGES
.
To use with react, must include the key with the 't' function
Inji Wallet has the capability to support multiple languages.
i18next
is an internationalization framework. It provides the standard i18n features such as plurals, context, interpolation, and format. It provides a complete solution to localize products from the web to mobile and desktop.
react-i18next
is a set of components, hooks, and plugins that sit on top of i18next, and is specifically designed for React.
expo-localization
allows you to localize the app, customizing the experience for specific regions, and languages. It also provides access to the locale data on the native device.
The configurable properties for Inji Wallet can be found at inji-default.properties. This property file is maintained as one for each deployment environment. On this repository, each environment configuration is placed in a corresponding branch specific to that environment.
Refer to inji-default.properties of Collab environment.
These values will be used by Inji Wallet via Mimoto. Mimoto loads all the configurations and exposes an API which is used by the Inji Wallet application to fetch and store the configurations in the local storage.
API used to fetch these configurations: https://api.collab.mosip.net/v1/mimoto/allProperties
The implementers can choose to use the existing configurations or add new configurations to them.
The properties used by Inji Wallet are:
mosip.inji.faceSdkModelUrl(https://${mosip.api.public.host}/inji)
: This is the path of the file server from where the face SDK model can be downloaded.
mosip.inji.modelDownloadMaxRetry(10)
: The maximum times the application will try to fetch the model.
mosip.inji.audience(ida-binding)
: This is used to generate the JWT token which will be passed during online login.
mosip.inji.issuer(residentapp)
: This is used to generate the JWT token which will be passed during online login.
mosip.inji.warningDomainName(https://${mosip.api.public.host})
: This is the mimoto domain used to access all Apis.
mosip.inji.aboutInjiUrl(https://docs.inji.io/inji-wallet/inji-mobile)
: This is the url for Inji Wallet Mobile documentation used in About Inji Wallet page.
mosip.inji.minStorageRequiredForAuditEntry(2)
: This is threshold(minimum storage space required) in MB for storing audit entries.
mosip.inji.minStorageRequired(2)
: This is threshold(minimum storage space required) in MB for storing downloaded / received vc.
Currently, Inji Wallet supports two themes:
default gradient
purple
We can customize the application by adding a new file under components/ui/themes
and import that file in components/ui/styleUtils.ts
and assign that to Theme
variable in it. Default Gradient theme is referred as DefaultTheme.
To change app logo on homescreen
Profile logo is part of downloaded verifiable credential. If credential doesn't face/photo attribute, default profile icon is being used.
To change the profile logo, In ProfileIcon.tsx
, refer
Card background is driven by wellknown exposed by issuing authoriy. If background details are not exposed, default background is being used. To change card background on home screen if not provided by issuer:
To change background on card details screen if not provided by issuer
To change the top header icons:
In HomeScreenLayout.tsx
, refer
To change the text, colour and logo for Tabs:
In main.ts
, there are 4 tab screens variables
image
can be changed by icon
attribute, text
and styles
can be changed by options
attribute in MainLayout.tsx
while rendering Navigator
Card content text color is driven by wellknown exposed by issuing authoriy. If text color is not exposed, default color is being used. To change default Label text color if not provided by issuer:
To change default Label value color if not provided by issuer:
To change the colour of +
icon colour:
In HomeScreen.tsx
, refer DownloadFABIcon
component
To change the colours of Label in Settings:
To change the background and label colour for version section:
To change colour on add new card page:
The VC can be dynamically rendered with all the fields, and if the display properties provided in the .well-known, Inji Wallet downloads the .well-known
and applies the below properties on the VC template to modify the VC render.
Text colour
Background colour
Logo change
Verifiable Credentials (VCs) are digital equivalents of physical documents such as passports or licenses. They are digitally signed, ensuring they are tamper-resistant and can be instantly verified. Issued by trusted entities, VCs can be stored in digital wallet apps like Inji Wallet or downloaded as a PDF file by individuals using Inji Web, a smart web-based solution.
Below are the key features provided by Inji Web:
With Inji Web, users can effortlessly select an issuer from a trusted list, verify their information, and download their Verifiable Credential in a convenient PDF format. This streamlined process ensures quick access to trusted credentials in just a few clicks.
Inji Web also offers secure storage for Verifiable Credentials, providing users with the flexibility to access and present their credentials anytime, anywhere. This ensures that users are always prepared to share their credentials, whether they’re at home or on the go.
Sharing credentials is made simple with Inji Web. The PDF version of the Verifiable Credential includes a QR code that can be shared with service providers either by presenting a printed copy, uploading the PDF to a verifier's website, or sharing it digitally through an online mechanism. This allows for quick and easy verification in response to any verifier’s presentation request, offering maximum convenience for users.
Manage (coming soon)
Users can view the downloaded credentials and access their activity logs for additional auditing purposes.
Inji Wallet currently provides support for following credential providers:
Download VC using OpenID for VC Issuance Flow
National ID
Insurance
To set up a new provider that can issue VC, it can be accomplished by making a few configuration changes.
Steps:
The configuration details can be found in the mimoto-issuers-config.json
property file. This file is maintained separately for each deployment environment. In this repository, each environment's configuration is stored in a dedicated branch specific to that environment.
Refer to mimoto-issuers-config.json of Collab environment.
These values will be used by Inji Wallet via Mimoto. Mimoto exposes APIs which is used by the Inji Wallet application to fetch, store the issuers and their configurations in the local storage.
API used to fetch issuers: https://api.collab.mosip.net/v1/mimoto/issuers
In mimoto-issuers-config.json
, new providers can be added as per the well-known
schema defined by OpenID4VCI standards.
After adding the provider in configuration, it will be displayed on the UI on Add new card
screen.
If new provider supports OpenID4VCI protocol, it is recommended to use issuerMachine.ts
for workflow to download VC.
At present, Inji Wallet supports verification of VCs which has RSA proof type. If VC is issued with any other proof type, VC verification is bypassed and it is marked as verified.
Token endpoint should also use same issuer id. Refer https://github.com/mosip/inji-config/blob/collab/mimoto-issuers-config.json#L140
Once the above steps are completed, mimoto should be onboarded as an OIDC client for every issuer. Please check the steps in the below sections.
If you are looking to try out wallet and certify building locally, then you can use collab env eSignet as authorization server. Here are the details:
We have configured few UINs/Individual Ids to use. These UINs can be used while configuring the data for credential. (Few Demo UINs you can use):
Male (Adult)
2154189532 , 5614273165
Female (Adult)
2089250384 , 5860356276
Minor (aged btw 5-18yrs)
3963293078
Infant (aged below 5 yrs)
5134067562
Use wallet-demo
as client id in mimoto-issuers-config.json
Use wallet-demo-client
as client alias in mimoto-issuers-config.json
oidckeystore.p12 file is attached here password to unlock this is xy4gh6swa2i
authorization server to use in well-known
is https://esignet-mock.collab.mosip.net
After configuring issuers and data as mentioned above, we will be able to successfully authenticate through esigent and download credential in wallet.
Step 1:
Please find a zip file attached to this document called certgen.zip which will help the user in creating the p12 file as well as the public-key.jwk file.
Step 2:
The Userguide.md file explains the working of the script.
Step 3:
Create a client ID using the Esignet API which is mentioned below:
Sample Request Body:
Sample Response :
Clients can get renewed by demand, but that mean some manual changes are required. It is always recommended to create a client once per environment as it has no expiry. Also note that one public key and p12 file pair can be used only once . ( Unless removed from DB )
The install.sh script in mimoto as well as the helm charts inside mimoto repo were changed to allow for the storage and mounting of the oidckeystore.p12 file
Step 4:
The logo URL should be uploaded to file server.
For Onboarding any new issuer, Step 1 to 4 has to be followed and p12 has to be generated.
Step 5:
Once p12 file is generated, existing keystore file has to be exported from mimoto pod and newly created p12 file has to be imported and remounted in the Mimoto pod.
Step 6:
Once mimoto is added as an OIDC client, the new issuer should be added as a partner to mimoto.
Create a partner - following is the process of adding a new partner by the name of “esignet--partner “ onto mimoto. Refer here to create a partner and onboard the partner in MOSIP Ecosystem.
We already have a p12 file on the mimoto pod (as explained in above section), we are not replacing or creating a second p12 file, We are only adding another key to the key-store already present.
Add this newly created partner into existing keystore - download the existing p12 file from the mimoto pod using this command from the environment's terminal:
Add the esignet--partner's key as alias “esignet--partner“ onto the same p12 file using a tool like keystore-explorer. Use the password used while generating p12 file
The below image shows how to browse and select the client-id’s oidckeystore as the second alias. in the decryption password field should have the password of the p12 file. Note: we have used esignet-sunbird-partner
as client id for reference in the attachment
The below image shows how to add an alias for the new key pair, here the value is esignet-sunbird-partner.
To take a backup of the original keystore.p12 use the following command
Delete the existing mimotooidc secret using the following command
To create a new secret containing both the keypair.
Create the required secrets in the cluster such as mimoto.oidc.mock.partner.clientid and use the client ID from the response of create oidc-client request.
Make sure to add the the mimoto.oidc.mock.partner.clientid inside the config-server deployment yaml file
Restart the Mimoto pod to take all the changes.
XCode for iOS development
To perform offline sharing using BLE, we recommend below:
Devices with Bluetooth v4.2 and above
Android v23 and above for Android
The below sections describe the steps for building the android application in Mac and Windows OS.
Configure Node & npm (recommended to use v16.19.0)
Configure Yarn
Configure Gradle & Java
Configure Expo, refer here.
Configure Android SDK, refer here.
Configure environment variables in your ~/.zshrc /
or ~/.bashrc
(depending upon your shell)
Generate debug keystore for building debug build.
Export keystore
Install Git
Use the below link to download git
After installation, run Git as admin.
Install SDKMAN
Use the below command in Git terminal
If you encounter an error while installing sdkman, please install zip on your system using your favourite package manager.
Install zip
SDKMan
requires the installation of the zip utility, which is not included in the default installation of Windows Git Bash.
To address this, please visit the website.
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
.
Finally, rerun the SDKMan
installation script.
Install gradle
Use the command below in Git terminal.
To check the installed gradle version.
gradle -V
Install Java JDK, refer here.
Install expo
Install Android SDK, refer here.
Install Node, refer here.
Install nvm
or
update the nvm version
Install adb
Configure ANDROID_HOME and JAVA_HOME in system environment variables
Clone Inji repository.
Create an android/local.properties
file with the following data:
Alternatively, you can open the Android folder in the android studio. It will create local.properties
file with sdk.dir = <location-of-the-android-sdk>
.
Note:
Default path for MacOS:
/Users/<username>/Library/Android/sdk
Default path for Linux:
/home/<username>/Android/Sdk
Default path for Windows:
C:\Users\<username>\AppData\Local\Android\sdk
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 purple
or orange
to apply gradient theme
Update mimoto url as https://api.collab.mosip.net here
Update esignet host as https://esignet.collab.mosip.net here
To deploy mimoto in local refer here
Go to the root folder of the project in the terminal.
Install all the dependencies using npm install
.
Build and run the application on the device:
Run npm run android:mosip
to build and install the application on the device.
Run npm run android:mosip --reset-cache
to build and install the application if any change is made in the .env file.
If you encounter the below issue on Windows,
Run npm i expo-modules-autolinking@~1.1.0
and rebuild the app
Path for debug apk in Inji directory android/app/build/outputs/apk/mosip/debug
Creating A Google Cloud Project Refer to this documentation on setting up a Google Cloud Project - https://developers.google.com/workspace/guides/create-project
Enabling Google Drive APIs Go to - https://console.cloud.google.com/apis/library
Search for Google drive API
and Select Google Drive API from the list.
Then enable the API.
Create Google Consent Screen
Go to - https://console.cloud.google.com/apis/credentials/consent
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.
Create Oauth Client ID
Go to - https://console.cloud.google.com/apis/credentials
Click on CREATE CREDENTIALS
and choose OAuth client ID
Choose Appliation type as Android
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
inAdvanced 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
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="<copied-client-id>"
The Internal testing version of the build can be uploaded to PlayConsole
for testing. PlayConsole allows the creation of internal testers group.
Publishing build manually to PlayConsole
A Google play console developer account is a must to publish builds in PlayConsole.
Set the backend URL and choose a theme (orange | purple) inside the .env
file.
Build the Apk or App bundle.
Login to PlayConsole and create a new release inside Internal testers.
Upload the Apk or App bundle to PlayConsole.
Upload in PlayConsole
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.
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.
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
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.
To deploy the Android build to PlayConsole, select Android Custom Build
workflow from github actions.
Choose the branch, backend url, theme and describe about build details.
Click the Run
workflow button.
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.
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.
The below section describes the steps build the iOS application.
Follow the Steps to configure Node & npm, Expo and generate debug keystore
Configure XCode, refer here.
Enable iCloud and create Containers, refer https://developer.apple.com/help/account/manage-identifiers/create-an-icloud-container/
Install all the dependencies
Run Metro bundler in the background
Run Inji directly to a connected device Command to run on simulator
Command to run real device
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.
Publishing build manually to TestFlight
An Apple developer account is a must to publish builds in TestFlight.
Set the backend URL and choose a theme (orange | purple) inside the .env
file.
Archive the build using xcode
.
Upload the archive to Testflight.
First choose Distribute App
.
Upload in TestFlight
Login to TestFlight and check for the build upload status. Once the build is uploaded successfully, add Groups
to provide access to testers.
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.
To deploy the iOS build to testflight, select Inji iOS build
workflow from github actions.
Choose the branch, backend URL, theme, testers group from TestFlight to get the build and describe about build details.
Click the Run
workflow button.
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.
Here is a comprehensive summary of the features offered by Inji Web.
Inji Web's user-friendly interface simplifies the process of downloading your VCs as PDF files in four simple steps. Here’s how it works:
Access the Inji web portal: Users can access the Inji Web Portal which is compatible with popular browsers such as Chrome, Firefox, Safari and Edge to mention a few
Select Issuer and Credential: Users can easily choose an issuer from the provided list and select the credential type offered by the issuer
Verification Process: Verification ensures that only authorized individuals can access and download the requested VCs. This adds an extra layer of security, preventing unauthorized access and ensuring that credentials are obtained only by the rightful owner
Download Credential: Users can securely download and store their digital VCs in PDF format
Inji Web provides users with a secure and reliable way to store Verifiable Credentials using Durian, a highly secure data storage solution. The downloaded credential is safely stored within the platform, ensuring they have access to it whenever needed via a QR Code. This secure storage feature guarantees that credentials are protected from unauthorized access while remaining accessible for future use.
The stored credentials are available anytime, enabling users to retrieve them quickly without having to repeat the download process. Whether for personal use or to meet credential presentation requests, Inji Web ensures your VCs are always securely stored and readily available.
Inji Web makes it easy for users to share their Verifiable Credentials with service providers or organizations. Each downloaded credential includes a QR code embedded within the PDF, offering multiple ways to share it. Users can present the QR code in person by printing the PDF or upload the file directly to a verifier's website for remote verification.
For added convenience, Inji Web supports online sharing methods where users can respond to a verifier’s presentation request, allowing seamless sharing of the VC. This flexible sharing feature empowers users to share their credentials securely and effortlessly, adapting to different verification environments.
This section offers an overview of the architecture and technologies utilized in Inji Web, ensuring compatibility, security, and efficiency in the management of Verifiable Credentials.
Inji Wallet (Web) End User Guide is structured as below:
Interface Overview
Downloading VCs as PDF
Download National ID VC as PDF
Download Insurance VC as PDF
Preference
Change Language
Inji Wallet (Web) is akin to Inji Wallet with a web interface which is fully responsive and accessible over Desktop, Tablet and Mobile browsers. Interface Overview provides you with a high level interface view (Desktop View) of the portal and labels the interface elements/items to let you quickly find an item referred to through this guide.
Main Menu
Language
Workspace
Search
Issuers
You can download your National ID, here we will see how to do it when we use eSignet for Authentication; using OTP.
Q. What details I need to provide to download my credential?
A. The credential issuer would have provided details such as UIN/VID in case of MOSIP National ID, You need to enter these information to be able to download Insurance VC.
To download a National ID VC using eSignet as authentication layer (OTP method)
Launch the Inji Wallet (Web) in your web browser, The home page presents you with the list of Issuers. You can also use the 'Search' box to search for and quickly find the Issuer (Credential Issuer) you are looking for.
Locate and click an 'Issuer' on the Workspace, Or
Search for an issuer by its name in Search box and click to proceed, Note: On selecting an Issuer from 'list of Issuers' it takes you to next page where you select a 'Credential Type' (National Id here) to download it as PDF.
On 'List of Credential Types' screen, select the 'Credential Type', It opens 'Share Validity Screen' as popup.
On 'Share Validity' popup you can choose to decide the number of times a credential can be used, choose from drop down (Once, Twice, Unlimited or Custom ). Click ok and proceed, It takes you to next page for authentication (eSignet).
On eSignet authentication page enter UIN/VID and click on 'Get OTP', a next screen will appear asking you to enter OTP.
Enter the OTP you received and click Verify.
A download progress screen appears.
PDF will be generated and stored in the Downloads folder of the system.
You can view the PDF of the downloaded VC (National ID) from download folder.
You can download your Insurance VC, here we will see how to do it when we use eSignet for Authentication; using OTP.
Q - What details do I need to provide to download my credential?
A - The credential issuer must have provided details such as Policy Number, Name and DOB for an Insurance card. This information has to be fed to the authentication system to enable download.
To download an Insurance ID VC using eSignet for authentication (KBI method), follow the step below:
Launch the Inji Web application in your web browser. The application home page presents you with the list of Issuers. You can also use the 'Search' box to quickly find an Issuer (Insurance provider).
Click-select a particular 'Issuer' (Insurance provider) which issued you the Insurance (Insurance VC Issuer), you will land to its Credential Types selection page.
On the Credentials Types page, choose a credential type from the List of Credentials section, 'Share Validity' popup will appear.
On 'Share Validity' screen you can choose to decide the number of times a credential can be used, choose from tyhe dropdown (Once, Twice, Unlimited or Custom). Click Ok and proceed, It takes you to next page for authentication (eSignet).
On eSignet authentication page enter Policy Number, Name and DOB (KBI Method) and click on 'Login'. Note: All the fields are mandatory.
Credential is downloaded in the background and PDF will be generated and stored in the Downloads folder of the system (A download progress screen is also seen when the credential is being downloaded).
The generated pdf is stored in the Downloads folder of the system. You can view the PDF of the downloaded VC (Insurance) from download folder.
You can choose your preferred language using 'language Selection' options available on the Main-Menu. Inji Web now supports 4 International Language (English, French and Arabic) and 3 Indian Languages (Tamil, Hindi and Kannada).
Inji Web is currently compatible and certified with the following browsers:
This document outlines the workflow for key functionalities of Inji Web.
The image below illustrates the workflow for the VC download process and explains the various components involved in this flow.
Inji Web: A web application featuring an intuitive, user-friendly interface for easy VC downloads by the user
Mimoto: The BFF (Backend for Frontend) for Inji Web, which retrieves default configurations and provides all necessary APIs to facilitate downloads. Mimoto receives requests from Inji, performs validations, and forwards them to respective services.
eSignet: Inji Web showcases the VC download process using the OpenID4VCI method with eSignet. In this workflow, eSignet provides the authentication, authorization and credential issuance end points to connect to the credential provider
Durian: A secure data storage solution integrated with Inji Web, used to store Verifiable Credentials securely. Durian ensures that the credentials are safely stored and readily accessible for users whenever needed, providing strong protection against unauthorized access.
Accessing Inji Web:
i. Users navigate to the Inji Web portal from their web browser
ii. The portal features a user-friendly interface accessible to all
Choose an Issuer and credential type:
i. Users can select an Issuer from the list of trusted issuers
ii. Users can choose a credential type from the available options provided by the issuers
Authentication:
i. In this reference implementation, the Insurance use case is demonstrated using Veridonia Insurance Credentials
ii. Users are required to provide their Policy Number, Date of Birth, and Name for verification
iii. The provided information is then verified against the issuer's records
Verifiable Credentials Storage:
i. After successful verification, the Verifiable Credential is securely stored in Durian, the platform’s secure storage solution.
ii. This ensures that users have reliable and convenient access to their credentials whenever needed, while maintaining strong protection against unauthorized access.
QR Code Generation:
i. During the download process, after securely storing the Verifiable Credential, Inji Web generates a QR code that is embedded within the PDF of the Verifiable Credential.
ii. Based on the set configuration as per the issuer, the QR Code will either contain a Verifiable Presentation request or an embedded Verifiable Credential.
iii. The QR code facilitates easy sharing and verification of the credential by scanning it or uploading the PDF file to the verifier's system.
Credentials Download:
i. Upon successful authentication, the Verifiable Credential is downloaded in PDF format.
ii. The downloaded PDF, containing the QR code, is saved in the “Downloads” folder on the user’s device.
The image below illustrates the workflow for the VC Share process and explains the various components involved in this flow.
_Reference Implementation: Sharing of Insurance VC (Veridonia Insurance)
Inji Web: A web application featuring an intuitive, user-friendly interface for easy VC downloads by the user
Inji Verify: Inji Verify is a powerful verification platform designed to authenticate and validate Verifiable Credentials (VCs). It allows users or organizations to scan QR codes or upload credential files for secure and efficient verification. Built with flexibility and compliance with OpenID standards, Inji Verify ensures seamless integration with trusted credential providers for smooth and reliable credential validation.
Mimoto: The BFF (Backend for Frontend) for Inji Web, which retrieves default configurations and provides all necessary APIs to facilitate downloads. Mimoto receives requests from Inji, performs validations, and forwards them to respective services.
Data Share: A secure data storage solution integrated with Inji Web, used to store Verifiable Credentials securely. Data Share ensures that the credentials are safely stored and readily accessible for users whenever needed, providing strong protection against unauthorized access.
Downloading the Verifiable Credential:
i. The user accesses Inji Web to download the Verifiable Credential in PDF format, which contains an embedded QR code.
ii. The QR code is used for sharing and allows verifiers to easily verify the credential by scanning or uploading it.
Launching Inji Verify:
i. Once the user is ready to share their Verifiable Credential, they launch the Inji Verify platform.
ii. Inji Verify is where verifiers can either scan the QR code from a printed or digital PDF or upload the PDF containing the QR code.
Authorization and Verification Request:
i. After the user uploads the QR code to Inji Verify, the platform sends a request to Inji Web for authorization to access the user's credential data.
ii. Inji Web verifies the legitimacy of the verifier and proceeds to authorize the request.
Retrieving Verifiable Credential:
i. Once authorized, Inji Verify communicates with the Data Share component to retrieve the stored Verifiable Credential.
ii. Data Share securely provides the Verifiable Credential to Inji Verify.
Verification and Display:
i. Inji Verify checks the authenticity of the Verifiable Credential and confirms its validity.
ii. The user or verifier is then shown the verified Verifiable Credential, confirming that the sharing process was successful.
Inji Web is an intuitive, user-friendly portal designed to helps users to access Verifiable Credentials.
The architecture diagram below illustrates the structure and components of Inji Web, offering a detailed explanation of how the platform operates and how its various elements interact to deliver its features and functionality.
Let's briefly explore the key components of the architecture that constitute Inji Web:
Inji Web: A React-based, user-friendly web portal that allows users to easily download Verifiable Credentials.
Backend for Frontend (BFF): Mimoto acts as the BFF layer for Inji Web, managing both authentication and credential requests. It processes authentication through eSignet for secure user authorization and token issuance, while handling credential issuance requests via Certify.
Authentication Layer: eSignet handles the authentication process, authorizing users, issuing access tokens, and preparing credentials by retrieving necessary data from the credential issuer.
Credential Issuer: Any credential issuer that supports the OpenID4VCI protocol can be listed as a trusted issuer. These issuers provide the user data required for creating and downloading Verifiable Credentials.
Durian: Durian provides persistent storage for Verifiable Credentials, allowing them to be securely stored and accessed later.
Let's explore how eSignet integrates with Inji Web and provides authentication solutions for the download workflow as follows:
The User navigates to the Home page of the Inji web application
and selects an issuer and credential type
Next, the authentication page is displayed which is the interface provided by eSignet.
The user enters the required information, such as Policy Number, Name, and Date of Birth. Subsequently, the system gets redirected back to Mimoto to add a client_id and generate a key pair, initiating the request to download the credential
Once Mimoto provides the response with the client_id and key, the credential endpoint of the issuer is invoked to get the credentials
Once the access token is received via the token endpoint from eSignet, Mimoto invokes this endpoint to obtain the Verifiable Credential.
Note: The endpoint attribute is present in the issuer's well-known configuration.
Name: Inji 0.11.1
Date: 19th Jan, 2025
Name: Inji Web 0.11.0
Date: 29th Jan, 2025
Name: Inji Web 0.10.0
Date: 16th October, 2024
Name: Inji Web 0.9.0
Date: 29th June, 2024
Name: Inji Web 0.8.1 (Patch)
Date: 22nd May, 2024
Name: Inji 0.8.0
Date: 26th April, 2024
Persona based approach has been adopted to perform the IV&V, by simulating test scenarios that resemble a real-time implementation.
A Persona is a fictional character/user profile created to represent a user type that might use a product/or a service in a similar way. Persona based testing is a software testing technique that puts software testers in the customer's shoes, assesses their needs from the software and thereby determines use cases/scenarios that the customers will execute. The persona needs may be addressed through any of the following.
Functionality
Deployability
Configurability
Customizability
The verification methods may differ based on how the need was addressed.
Verification is performed on various configurations as mentioned below.
Default configuration - with 6 Lang
English
French
Arabic
Hindi
Tamil
Kannada
Below are the test metrics by performing Automation UI 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.
Below are the test metrics by performing UI Automation:
Test Rate: 100%, With Pass Rate: 100%
Functional and test rig code base branch which is used for the above metrics is:
Hash: 9bf9e9f60744c372670fd9816e65cf81987b0d7e
Below are the detailed test metrics by performing 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:]{.mark}
[Passed Test Cases Coverage: It measures the percentage of passed test cases. (Number of passed tests / Total number of tests executed) x 100]
[Failed Test Case Coverage: It measures the percentage of all the failed test cases. (Number of failed tests / Total number of test cases executed) x 100]
The backend services section provides an in-depth overview of the backend components and functionalities of Inji Web. It offers insights into data management, authentication processes, and communication between the frontend and backend systems.
Release Name: Inji Web 0.11.1(Patch)
Release Type: Developer
Release Date: 19th Feb, 2025
This patch release enhances UI automation for multi-language support in Inji Web by updating automated test cases. Text assertions have been modified to align with the latest translations, ensuring accuracy and consistency across languages.
Updated automated test cases to reflect the correct translated text.
Ensures consistency across different language settings in UI.
As part of the 0.11.1 release, the following issue has been addressed:
The following table outlines the tested and certified compatibility of Inji Web 0.11.1 with other modules.
Mimoto serves as a Backend for Frontend (BFF) for Inji Web, handling retrieval of default configurations and downloading VCs. It offers essential APIs to Inji Web, facilitates validations, and forwards requests to relevant services.
In mimoto-issuers-config.json
, new providers can be added as per the well-known schema.
Fetch Issuers:
Fetch Issuer's Configuration:
Download PDF:
Fetch Issuer Credentials:
This API fetches the list of Credential Types offered by the issuer, sourced from the well-known configuration of the issuer. Users can filter credentials based on search parameter.
https://api.collab.mosip.net/v1/mimoto/issuers/{issuer-id}/.well-known
Method Type: GET
Parameter:
issuerid: ID of the issuer in string type.
Response
Response code 200
18.2v
React enables building user interfaces from individual units called components.
4.9.5
A strongly typed programming language that builds on JavaScript and uses type inference to give great tooling without additional code.
3.4.3
A utility-first CSS framework that streamlines web development by providing a set of pre-designed utility classes for rapid styling without writing custom CSS, promoting consistency and scalabilitystrong>.
14.2.1
The React Testing Library
is a very lightweight solution for testing React components
29.7.0
Jest is a well-known JavaScript testing framework and is extensively used to test React applications
20.4 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.
npm is the package manager for the Node JavaScript platform. It puts modules in place so that node can find them, and manages dependency conflicts intelligently
depends on Inji-web version
Helm helps in managing 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.
For more detailed information on each step and the underlying systems, click .
For more detailed information on each step and the underlying systems, click .
For more detailed information on each step and the underlying systems, click .
Reference Implementation: Download of Insurance VC (Veridonia Insurance) with as identification partner
eSignet provides a user-friendly and efficient method for individuals to authenticate themselves and a access online services. Serving as a dependable identity provider for relying party applications, it grants access to services without requiring additional login credentials. eSignet also provides a secure means of verifying an individual's identity against trusted identity providers, such as national identity databases, driver's license systems, passport systems, or other trusted sources. The level of assurance here is determined by the authentication factor employed. To know more about eSignet, click .
Git hub link for the xls file is .
The list of known issues can be found .
To support credential issuance from any issuer compatible with the OpenID4VCI protocol, Mimoto must be onboarded as an OIDC client. Refer for more details on how to onboard Mimoto (BFF) as an OIDC client.
Detailed API documentation for Mimoto is accessible .
Configuration details to set up a new provider that can issue VC, can be found in the mimoto-issuers-config.json
property file. Refer to of Collab environment.
1.
Google Chrome
103.0.5060.114 and above
2.
Mozilla Firefox
100.0 and above
3.
Microsoft Edge
104.0.1293.47 and above
4.
Mac Safari
14.1 and above
Total
Passed
Failed
Skipped/Ignored
19
19
0
0
Jira issue
Issue description
Multi Language test-cases are failing
Repositories
Tags Released
Inji-web
Module
Version
eSignet
Inji Verify
Inji Certify
mimoto
Inji-config
durian(data share)
This section offers an overview of the architecture and technologies utilized within Inji Wallet, ensuring compatibility, security, and efficiency in the management of Verifiable Credentials.
The 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 the readiness of software for use in multiple countries. MOSIP is an "API First" product platform.
Testing scope has been focused on the below features:
Inji Home page
Issuer and Credential selection
Authenticating with user credentials
PDF Generation and Auto download
Success/Failure notification after downloading the VC PDF
Retrieve Issuers and Credential list
Downloading VC
Multi languages support
Error Handling
Theme update
PDF View
Issuers support
Responsive view of the web
Access violations
QR Code
Durian data storage integration
PDF and CBOR
OpenID4VP Implementation
Latest draft changes support for OpenID4VCI
FAQ Support
UI UX Design updates
Swagger update
Secure Time Bound Storage
Persona based approach has been adopted to perform the IV&V, by simulating test scenarios that resemble a real-time implementation.
A Persona is a fictional character/user profile created to represent a user type that might use a product/or a service in a similar way. Persona based testing is a software testing technique that puts software testers in the customer's shoes, assesses their needs from the software and thereby determines use cases/scenarios that the customers will execute. The persona needs may be addressed through any of the following.
Functionality
Deployability
Configurability
Customizability
The verification methods may differ based on how the need was addressed.
Verification is performed on various configurations as mentioned below.
Default configuration - with 6 Lang
English
French
Arabic
Hindi
Tamil
Kannada
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.
456
426
30
0
Test Rate: 100%, With Pass Rate: 93%
Here is the detailed breakdown of metrics for each module:
Test cases
456
426
30
0
Below are the test metrics by performing UI Automation and API Test rig.
180
153
0
27
Test Rate: 83%, With Pass Rate: 99%
Test Rate: 83%, With Pass Rate: 99%
Here is the detailed breakdown of metrics for each module:
Test cases
19
19
0
0
Test cases
161
134
0
27
Note: Ignored 27 OTP related test cases which are descoped and not applicable
Functional and test rig code base branch which is used for the above metrics is:
Hash:0a7d1b58f5c8b73ba4c0c3520da888f6ce64311a473ac456048cbce124d41197
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
Git hub link for the xls file:
<TBD>
Release Name: Inji Web 0.11.0
Support: Developer
Release Date: 29th Jan, 2025
This release introduces several enhancements, new features, aimed at improving the functionality, security, and user experience of the platform. Key objectives include secure time-bound storage, and UI updates to align with new branding standards.
Secure Time-Bound Storage: Introduced functionality to set validity periods for credentials before download, ensuring secure and controlled access to stored data.
VC Verification During Download:
RSA VC Verification: For verifying RSA-based Verifiable Credentials before download within the Inji Web Wallet.
EdDSA VC Verification: Integrated VC Verifier SDK to enable seamless verification of EdDSA-based Verifiable Credentials during downloads.
Mimoto Enhancements and Additions
Trusted Verifiers API - Introduced the Trusted Verifiers API to enhance the verification process and enable secure interaction with trusted verifiers.
Main Branch Renamed - The “Main branch” in the Mimoto repository has been renamed to “Master Branch” for consistency and improved repository management.
mDoc VC Format Support - Added support for the mDoc Verifiable Credential (VC) format, allowing seamless integration and verification of mdoc credentials.
Compatibility and Availability
These enhancements are currently available for testing and building using the Inji Mobile Wallet.
Support for Inji Web will be introduced in upcoming releases.
Fully compatible with Inji Mobile Wallet v0.15.0 onwards, which is part of the ongoing release pipeline.
Security Fixes
All critical security issues addressed and resolved.
Sonar issues fixed, with the Sonar report.
UI Enhancements
Inji Web Wallet Home Page:
Incorporated new branding changes for a modern and enhanced user experience.
Ensured a fully responsive design for seamless access across devices.
Implemented a comprehensive FAQ section for an improved and readily available answers to frequently asked questions.
Below is the list of fixes as part of the 0.11.0 release:
Inji Web: Could not open help and About Inji pages in mobile phone
Inji Web: zerotimes and maximum limit(1000000000) are not properly handled while downloading the VC
Inji Web: Overlapping observed for credentials when opened in mobile phone
Inji Web: For Hindi full stop observed like "।" and also "." in FAQ page
Inji Web: In some languages in the last FAQ Online Sharing translating to selected lang but not the Embedded VC
Inji Web: Intermediately We are not able to download the Sunbird VC in Inji Web
Inji Web: Error description is not proper when the record is not available in durian
Inji Web: Cientid is different and redirect URI are from different domains
Security testing: Inji web - DEBUG mode is set in mosip-config
Security testing: Inji web UI landing page is not fully visible, the footer blocks the view of partners
Security testing: Inji web - blank page error response during URL tampering
snyk dependency analysis: Inji web (develop)
Security hotspot on Inji Web: develop branch
Inji - QR code generated in Inji Web and in Inji Mobile are not matching
Inji Web: Getting invalid credentials error message for valid data, when we leave authentication page idle for sometime
Inji Web: QR code is not working on VC card
Below is the list of known issues. To read in detail click here.
Inji - QR code generated in Inji Web and in Inji Mobile are not matching.
Inji Web: In Arabic lang, consent option strings and buttons are overlapping in tablet portrait mode
Inji Web: In Arabic lang, lang selection option is not properly aligned in in tablet portrait mode
Inji Web: Scroll down on share visibility page working as back button
Inji Web: On share visibility if click on outside page dropdowns are selected in tablet
Inji Web: Credentials search bar is not properly aligned in tablet view
Inji Web: For Hindi full stop observed like "।" and also "." in FAQ page
Inji Web: In some languages in the last FAQ Online Sharing translating to selected lang but not the Embedded VC.
Inji Web: Field values in json decoded from CBOR and the values in VC PDF are different
The following table outlines the tested and certified compatibility of Inji Web 0.11.0 with other modules.
eSignet
Inji Verify
Inji Certify
Inji-web
mimoto
Inji-config
vc-verifier
durian(data share)
Release Name: Inji Web 0.10.0
Support: Developer
Release Date: 16th October, 2024
We are pleased to announce the release of Inji Web Version 0.10.0! This release introduces exciting new features, including the effortless sharing of Verifiable Credentials via a QR code embedded directly within the credential PDF, making sharing smoother than ever! This feature empowers users to quickly share their credentials with service providers, ensuring a seamless and secure verification process in online mode.
Online Sharing Feature: Introducing seamless online sharing of Verifiable Credentials through integration with Data Share and Inji Verify modules, ensuring quick and secure sharing between users and verifiers.
Compliance with OpenID4VCI Draft 13: Full support for the Draft 13 changes of the OpenID4VCI specification, aligning Inji Web with the latest standards for Verifiable Credentials.
Integration with Certify & eSignet: Streamlined credential issuance through Inji Certify and eSignet authentication, enabling smoother, secure interactions with trusted credential issuers.
Below are the key features as part of this release:
Online Sharing: Verifiable Credentials can now be easily shared online using the QR Code on the credential PDF. This feature is dependent on integrations with the Data Share and Inji Verify modules, ensuring a secure and convenient mechanism for sharing credentials.
Draft 13 Changes for OpenID4VCI: Inji Web now adheres to the latest Draft 13 of the OpenID4VCI spec, making it fully compatible with the most recent standards in credential issuance and verification.
Integration with Certify and eSignet:
Authentication: eSignet is integrated for user authentication, providing a robust and secure method to authenticate and authorize users in compliance with OpenID4VCI.
Credential Issuance: Inji Certify is responsible for issuing credentials by the new standards, ensuring a smooth issuance process after successful authentication.
Repositories
Tags Released
inji-web
mimoto
inji-config
durian(data share)
mosip-openid-bridge
khazana
bio-utils
The following table outlines the tested and certified compatibility of Inji Web 0.10.0 with other modules.
Module
Version
eSignet
Inji Verify
Inji Certify
Below is the list of known issues. To read in detail click here.
Jira ID
Description
Inji Verify: Getting "No MultiFormat Readers were able to detect the QR code." error when the VC PDF from the inji web application is uploaded.
Inji-web: Getting invalid credentials error message for valid data, when we leave the authentication page idle for sometime
Injiweb: If the browser zoom-in increases then the some of options are not visible
INJIWEB: After navigating to the Issuer type page, the close/back button is missing in the eSignet page
Injiweb: credential strings are not properly displayed for different dimensions under mosip issuer
Inji-web: If the filed values are not provided during policy creation, in downloaded VC getting expressions directly
Inji-web: Observed access violation when "IBM Equal Access Accessibility Checker" executed on inji-web portal
Inji-web: The QR code is not working on the VC card
Inji-web: Not getting proper error message when the website is down
Features
Workflow
End User Guide
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 the readiness of software for use in multiple countries. Since MOSIP is an “API First” product platform, Verification scope required comprehensive automation testing for all the MOSIP APIs. An automation Test Rig is created for the same.
The Inji testing scope revolves around the following flows:
Biometric unlock
Passcodes unlock
VC download via MOSIP
VC download via eSignet
VC download via Sunbird
Retrieving UIN/ via AID
Pinning a VC
Normal VC sharing with VID
Deleting VC
Face Auth on Resident's phone with VID
Multi language support
Credential registry
Backup and restore
Wallet binding
QR code Login
Logout
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
Deploy ability
Configurability
Customizability
The verification methods may differ based on how the need was addressed.
For regression check, “MOSIP Test Rig” - an automation testing suite - which is indigenously designed and developed for supporting persona-based testing. MOSIP Test Rig covers the end-to-end test execution and reporting. The end-to-end functional test scenarios are written starting from pre-registration to creation of packet in registration center, processing the packet through the registration processor, generating UIN and authenticating identity using IDA through various permutation and combinations of cases being covered. MOSIP Test Rig will be an open-source artifact which can also be enhanced and used by countries to validate the SI deliveries before going live. Persona classes include both negative and positive personas. Negative persona classes include users like Bribed Registration Office, Malicious Insider etc. The needs of positive persona classes must be met, whereas the needs of negative persona classes must be effectively restricted by the software.
Verification is performed on various configurations as mentioned below
Default configuration - with 3 Lang
Virtual countries
1 Lang configuration
2 Lang configuration
3 Lang configuration
On Android Device:
On iOS Device:
Below are the test metrics by performing functional testing using mock MDS and mock ABIS. 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 languages and configurations. The testing cycle included simulation of multiple identity schema and respective UI schema configurations.
Here is the detailed breakdown of metrics for each module:
Below section provides details on API test metrics by executing MOSIP functional automation Framework. All external API test executions were performed at module level isolation. Each end point is tested with the test data and expectations of each test data are mapped to assert the test case.
Here is the detailed breakdown of metrics
Below section provides details on Ui Automation by executing MOSIP functional automation Framework.
Here is the detailed breakdown of metrics
Functional and test rig code base branch which is used for the above metrics is:
Hash Tag:
SHA: sha256: b477f64889c7340a1d1ca6b17601473c30d206de8de9c8a69e8879be38e1dbb5
Below are the test metrics by performing VC Sharing functionality on various device combinations
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
Git hub link for the xls file is .
Total
Passed
Failed
Skipped (N/A)
2303
2034
226
43
Test Rate: 98% With Pass Rate: 90%
Test cases
On Android Device
Total
1236
Passed
1085
Failed
124
Skipped (N/A)
27
On iOS Device
Total
1067
Passed
949
Failed
102
Skipped (N/A)
16
Total
Passed
Failed
Skipped
1335
1275
32
28
Test Rate: 97.9% With Pass Rate: 97.5%
Test cases
Mobile ID
Total
63
Passed
61
Failed
2
Skipped
0
eSignet
Total
1272
Passed
1214
Failed
30
Skipped
28
Total
Passed
Failed
Skipped
120
107
13
0
Test Rate: 100% With Pass Rate: 89.16%
Test cases
Android
Total
63
Passed
54
Failed
9
Skipped
0
iOS
Total
57
Passed
53
Failed
4
Skipped
0
Total
Passed
Failed
Skipped
192
192
0
0
Test Rate: 100% With Pass Rate: 100%
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 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 environment. Let's begin this journey of seamless setup and exploration!
Before you start with setting up Inji Mobile, ensure you have the following in place.
Inji Wallet APK File:
If you are using an Android smartphone, click here to get the Inji Mobile apk
file for installation.
Transfer the apk
file onto the smartphone on which it is to be installed.
Inji Wallet Test Flight Access:
If you are using an iOS device, click here get access to the Inji Wallet app on test flight.
Ensure you have get the test flight application from your app store.
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.
Fill out the form here and we will generate the demo credentials, which you can use subsequently on the Inji Mobile app to download and share Verifiable Credentials (VCs).
Note: Please use 111111 as the OTP, for any OTP based feature in Collab environment.
For sample Insurance Credentials, please provide the below details in the eSignet authentication page:
Policy id: 7070
Name: aswin
DOB: 19/02/2025
To effectively set up the Inji Mobile app and manage Verifiable Credentials (VCs), follow these detailed steps:
Step 1: Install the Inji Mobile App
For a step-by-step guide on how to install the Inji Mobile application, click here.
You can visit this section for more detailed instructions in the guide.
Step 2: Install the Inji Mobile App - To be used as Verifier App
Follow the same installation process mentioned above in step 1.
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
Download your credential (VC) onto the app by using your demo UIN.
To learn how to download VCs using the Unique Identification Number (UIN) or Virtual ID (VID) feature, click here. 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 for step-wise download.
You can view the QR Code for insurance credentials in the detailed view.
Step 5: Start Sharing the Credentials
Quick Share
To understand the process of sharing credentials from the Resident app to the Verifier app, click here.
Navigate to the section titled Sharing Credentials
for detailed instructions.
Share with Face Verification
Discover how to share credentials with the added security of face verification by clicking here.
Refer to the section titled Face Authentication Flow
for a step-by-step guide.
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.
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.'
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.
Watch this informative video titled Inji Wallet Product Demo to Download and Share VC for a visual walkthrough of the features.
Click here 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.
If you require any assistance or encounter any issues during the testing and integration process, kindly reach out to us through the support mechanism provided below.
Navigate to Community.
Provide a detailed description about the support you require or provide detailed information about the issue you have encountered, including steps to reproduce, error messages, logs and any other relevant details.
Thank you. Wishing you a pleasant experience!
This API provides data with search capability to populate the list of supported issuers in Inji Web, which is then displayed under the List of Issuers
This API provides the complete configuration details for the specific issuers passed in the path variable
The following section aims to outline the necessary configuration files required for seamless operation and customization of Inji Web and Mimoto:
inji-config repo contains all the necessary configurations for the Inji Stack.
Below property files define the configurations for default properties which are consumed by Inji Web.
inji-default.properties - Default Configuration for Inji Web App is provided here
credential-template.html - PDF Template for Inji Web Credential Download is available here
Mimoto acts as a BFF layer for both Web and the Wallet. Below mentioned property files define the configurations of default properties which are consumed by Mimoto.
mimoto-default.properties - Contains default Configuration for Mimoto
mimoto-issuers-config.json - Issuers related configuration are provided here.
This API is responsible for generating PDFs for the received VC content. It fetches display properties from the well-known configuration of the issuer and incorporates them into the predefined template of the PDF file.
This api is used to generate otp for wallet binding. This api is used as a proxy to call Identity Provider - Send Binding OTP Endpoint api internally.
This api is used to bind the credential with wallet. This api is used as a proxy to call Identity Provider - Wallet binding Endpoint api internally.
The request time
The link transaction endpoint is invoked from Wallet-app.
Validates the link-code and its expiry and generates the linkTransactionId. This linkTransactionId is linked to transactionId returned from /oauth-details endpoint.
Returns the auth-factors, clientName, logoUrl, User claims, authorize scopes along with linkTransactionId.
Note: Wallet-app will hereafter address the transaction with this linkTransactionId for the /authenticate and /consent endpoints.
Once end user provides the user identifier (UIN/VID) and all the required auth challenge to the Wallet-app, this endpoint will be invoked from wallet-app.
Supported auth-challenge depends on the integrated authentication server.
On Authentication Success: Only linkTransactionId is returned in the below response without any errors.
On Authentication Failure: Error list will be set with the errors returned from the integrated authentication server.
yyyy-MM-dd'T'HH:mm:ss.SSS'Z'
Once the authentication is successful and user consent is obtained, this endpoint will be invoked by the wallet app to send the accepted consent and permitted scopes.
yyyy-MM-dd'T'HH:mm:ss.SSS'Z'
Once the access token is received via the token endpoint, Wallet should invoke this endpoint to get the verifiable credential.
Format of the Credential to be issued.
JSON object containing proof of possession of the key material the issued Credential shall be bound to.
JSON object containing (and isolating) the detailed description of the credential type. * This object MUST be processed using full JSON-LD processing. If it consists of the following sub claims: * @context: REQUIRED. JSON array
Once the access token is received via the token endpoint, Wallet should invoke this endpoint to get the verifiable credential.
Format of the Credential to be issued.
JSON object containing proof of possession of the key material the issued Credential shall be bound to.
JSON object containing (and isolating) the detailed description of the credential type. * This object MUST be processed using full JSON-LD processing. If it consists of the following sub claims: * @context: REQUIRED. JSON array
This API provides data with search capability to populate the list of supported issuers in Inji Web, which is then displayed under the List of Issuers
This API provides the complete configuration details for the specific issuers passed in the path variable