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...
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.
These credentials can then be shared with relying parties via Bluetooth, using the BLE protocol.
For added security, users have the option to authenticate their credentials through offline face verification during transactions.
Inji Mobile also integrates with eSignet, enabling users to log in to service provider portals by simply scanning a QR code.
Users maintain full control over what information is shared, through the consent mechanism that comes along.
Inji Mobile is compatible with the OpenID protocol, offering a wide range of Identity Providers (IdP) for users to select from when downloading their verifiable credentials.
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.
The app leverages Mimoto APIs for generating, downloading and activating Verifiable Credentials (VCs).
Additionally, it utilizes eSignet APIs to enable seamless online login for users.
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.
For any queries or contributions, please engage with us here.
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.
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.
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.
The chosen language will be reflected within the app interface. Subsequently, a five-page tutorial for the Inji Wallet will be presented, followed by the option to secure the app.
This can be achieved through a PIN or the device's Biometrics (such as fingerprint or facial recognition). Once the setting is done, users 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 Veridonia Insurance Company 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.
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 section intends to provide an overview of the technologies, tools and frameworks utilized to build Inji Wallet:
Tool / Technology | Version | Description | License |
---|
This section intends to provide an overview of the technologies, tools and frameworks utilized to build native libraries:
Tool / Technology | Version | Description | License |
---|
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.
To know more about QR code verification, read about Inji Verify .
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 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.
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
Face Match
Secure Keystore
BLE Verifier
PixelPass
VCI-client
Telemetry (coming soon)
The transfer of downloaded Verifiable Credential from the Wallet to Verifier is facilitated by a React Native library named Tuvali.
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.
It also helps to sign with aliases, created as part of key pair generation.
As the description says, this module is only for Android devices which support hardware keystore.
This library is available as Kotlin artefact in maven as well as npm module for react native application. Inji Wallet is integrated with the kotlin artefact of secure-keystore.
In order to reduce the key size during credential download request, Inji Wallet is using RSA-2048 instead of RSA-4096 bits keys.
Note:
This feature is exclusive to the Android operating system.
It is only compatible with devices that have a hardware keystore.
Note:
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:
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 meta data and the access token received for authorization and provides VC as the response back to the consumer application for storage.
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 GenderMag Methodology aims to analyze and mitigate gender biases in users’ problem-solving interactions with software. It underscores the importance of accounting for gender differences in human-computer interaction (HCI) during the software design process.
Process
We identified two personas based on their familiarity with technology and their ability to embrace technological progress. The personas are:
Abi, who is either Abigail or Abishek, is 45 years old. She works as a homemaker, is literate, but not very tech- savvy. Her internet connectivity is moderate, and she does not have a personal phone.
Tim, who is either Timothy or Timara, a 24-year-old financial consultant, is literate, tech-savvy, and boasts excellent internet connectivity. Additionally, he owns the latest phone.
Examine the feature, systematically walk through the process, assess their information handling, and pinpoint any problems.
During the walkthrough, we pinpointed inclusivity concerns in the Inji Wallet app’s user interface and experience. Subsequently, we took steps to mitigate these issues, aiming to eliminate digital entry barriers.
As part of Phase1, below P1 items are fixed in the v0.11.0-Inji Wallet release:
Sl No | Problem statement | Solution | Jira number |
---|
As part of Phase2, below P1, P2 items are fixed in the v0.12.0 release of Inji Wallet:
Sl No | Problem Statement | Solution | Jira number |
---|
This document delineates the workflow for essential functionalities of Inji Wallet.
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 .
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.
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 .
enables offline VC transfer between mobile devices via Bluetooth Low Energy (BLE). The below table represents the supported roles for Android and iOS devices.
Wallet | Verifier | VC transfer support |
---|
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.
To check the NPM module, click .
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.
The library is designed for the purpose of creating and storing key-pairs in the hardware keystore of Android devices. The library also supports encryption, decryption, and HMAC calculation functionalities.
To check all the APIs supported by this module, refer .
To understand about the library and the API documentation, refer .
To check the NPM module, click .
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 .
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.
Refer to the PixelPass repository .
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
Refer to the VCI-Client repository .
To understand about the installation and the API documentation, refer .
To check the NPM module, click .
Maven snapshots are available
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 .
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.
Android | Android | Yes |
iOS | Android | Yes |
Android | iOS | No |
iOS | iOS | No |
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.
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.
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.
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 |
|
|
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.
| 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 |
| For problem statement 1:
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”. |
|
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.
|
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.
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
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
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
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.
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
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.
Here is the detailed breakdown of metrics for each module:
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.
The 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: 58e77d26fc1b98884c11638bba70c128d27994e3
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 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
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. |
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
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.
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 .
To get a list of issuers, API is called. For retrieving the credential types and display properties, .well-known
location is referred for every issuer from the
Inji Wallet allows the users to download VC by redirecting the user to eSignet UI. Multiple APIs are being called to complete the process in the backend.
Inji Wallet initiates authenticate API by redirecting users to eSignet UI. On eSignet UI, user is given option to enter the unique ID, the user is asked to enter an OTP on the next screen. In the backend, token API is called to get a token. Refer for more details.
After getting a token response, Inji Wallet initiates a download request. Refer
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 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 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:
Name: Inji Wallet 0.14.0
Date: Coming Soon
Type: Developer
Release Notes
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
Release Name: Inji Wallet 0.14.0
Release Type: Developer
Release Date: Coming Soon
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.
PixelPass enhancements - Support CBOR encoding/decoding
Given JSON data, it does the CBOR encode/decode.
Given a JSON and a Mapper(similar to ) 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.
The following table outlines the tested and certified compatibility of Inji Wallet 0.14.0 with other modules.
Note: Redmi devices are not supported in this release.
QA Report
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.
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.
Screen name: Retrieve your UIN/VID on clicking link
Name | Type | Description | Sample |
---|---|---|---|
Name | Type | Description | Sample |
---|---|---|---|
The configurable properties for mimoto can be found at . This property file is maintained as one for each deployment environment. On repository, each environment configuration is placed in a corresponding branch specific to that environment.
Refer to of Collab environment.
Below is the list of known issues. To read in detail and view all the issues related to Inji Verify please click .
Jira issue | Issue description |
---|
Below is the of fixes as part of the 0.14.0 release:
To ensure fraud prevention in compliance with , the faceAuth verification should include passive liveness checks, such as picture-in-picture.
Name
Description
ConfigOptions
configOptions
device name used during advertisement
deviceName is the parameter
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
""
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
""
Total | Passed | Failed | Skipped (N/A) |
2461 | 2203 | 214 | 44 |
Test Rate: 98.21% With Pass Rate: 91.14% |
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 |
Total | Passed | Failed | Skipped |
141 | 134 | 4 | 3 |
Test Rate: 97.97% With Pass Rate: 97.10% |
Total | Passed | Failed | Skipped |
108 | 106 | 2 | 0 |
Test Rate: 100% With Pass Rate: 98.14% |
Test cases |
Android | Total | 60 |
Passed | 58 |
Failed | 2 |
Skipped | 0 |
iOS | Total | 48 |
Passed | 48 |
Failed | 0 |
Skipped | 0 |
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 |
Repositories | Tags Released |
Inji-wallet | v0.14.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 |
Response | Status |
true | Matched |
false | Not Matched |
false | Error |
Welcome to the Inji Wallet Setup 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 Wallet, ensure you have the following in place.
Inji Wallet APK File:
If you are using 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.
Inji Wallet Test Flight Access:
If you are using an iOS device, fill out the form here to get access to the Inji Wallet app on test flight.
Ensure you have downloaded the test flight application from your app store
You will receive an email on the email ID (associated to the Apple ID) provided in the form.
Follow the instructions in the email and access Inji Wallet from the iOS device on which it has to be installed.
UIN Credentials:
Issuance of UIN (Unique identification number) as a demo credential will allow you to explore Inji Wallet’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 Wallet 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 Number: 170-620-124
Name: Abhishek G
DoB: 07/07/1995
To effectively set up the Inji Wallet app and manage Verifiable Credentials (VCs), follow these detailed steps:
Step 1: Install the Inji Wallet Resident App
For a step-by-step guide on how to install the Inji Wallet application, click here.
You can visit this section for more detailed instructions in the guide.
Step 2: Install the Inji Wallet App - To be used as Verifier App
Follow the same installation process mentioned above in step 1.
Setup another instance of the Inji Wallet 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!
Welcome to the Inji Wallet Sandbox: Here, you can try out all the features of our app in a risk-free environment. Experiment with different settings, test your use cases, and get hands-on experience with Inji Wallet’s functionalities.
Refer Inji Wallet Setup Guide to know more about how you can explore 'Inji Wallet' in our 'sandbox collab environment'.
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.
Module | Version |
Mimoto | v0.14.0 |
Inji-config | v0.3.0 |
eSignet | v1.4.1 |
Inji Verify | v0.10.0 |
tuvali |
tuvali-ios-swift |
secure-Keystore |
pixelpass |
pixelpass-ios-swift |
Inji-vci-client |
Inji-vci-client-ios-swift |
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 |
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 |
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 |
vcImage | The image that is given in the VC |
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 here.
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
Github link for the xls file is here.
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.
Redmi devices are not supported in this release. To know more, refer here.
Mentioned below is the list of other known issues.
Below are the list of fixes as part of 0.12.0 release:
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.
Redmi devices are not supported in this release. To know more, refer here.
Mentioned below is the list of other known issues.
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.
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.
Test Rate: 99.09% with Pass Rate: 94.22%
Here is the detailed breakdown of metrics:
Below section provides details on UI Automation by executing MOSIP functional automation Framework.
Test Rate: 100% with Pass Rate: 87.50%
Here is the detailed breakdown of metrics
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.
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.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:
The following table outlines the tested and certified compatibility of Inji Wallet 0.13.0 with other modules.
Redmi devices are not supported in this release. To know more, refer here.
Mentioned below is the list of other known issues.
The 0.13.0 release includes the following bug fixes:
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
Link for the detailed test report.
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:
We've transitioned to using Tuvali for Bluetooth Low Energy (BLE) communication, enhancing the connectivity experience.
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.
Bug fix: Reduced the app size for Android #INJI-103
Bug fix: Resolved connectivity issue when sharing VC #INJI-207
To know more about Inji Wallet, watch the video!
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.
Efforts have been made to improve the security of data in the default file located in the mmkv
folder under the INJI-467 task.
To know more about Inji, watch the video!
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.
Test Rate: 98% With Pass Rate: 89.74%
Here is the detailed breakdown of metrics for each module:
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.
Test Rate: 90.6% With Pass Rate: 9.4%
Here is the detailed breakdown of metrics:
The below section provides details on Ui Automation by executing the MOSIP functional automation Framework.
Test Rate: 100% With Pass Rate: 96.72%
Here is the detailed breakdown of metrics:
Functional and test rig code base branch which is used for the above metrics is:
SHA: sha256: b477f64889c7340a1d1ca6b17601473c30d206de8de9c8a69e8879be38e1dbb5
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.
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
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.
Redmi devices are not supported for this release. To know more, refer to known issues in Redmi device.
The user will now be redirected to the MOSIP page successfully from the About INJI
screen. Earlier the link was crashing the app. #INJI 225
The user will be able to login into eSignet portal via QR code, using the VC activated on Home screen via. ellipsis menu. #INJI 253
App will prompt and remove tampered VC. #INJI 397
The user will be asked for language preference only at new installation. #INJI 362
Previously used UIN/VID will not be suggested in the AID field for VC download. #INJI 332
The user will be able to see the detailed view of Received
VC. #INJI 329
The user will be redirected to an intermittent downloading screen, when download is triggered from OpenID supported issuer. #INJI 458
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
Link for the detailed test report.
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
Link for the detailed test report.
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.
The following table outlines the tested and certified compatibility of Inji Wallet 0.13.1 with other modules.
None
Redmi devices are not supported in this release. To know more, refer here.
Mentioned below is the list of other known issues.
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.
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:
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.
Create loader_path folder under the docker-compose directory and download the kernel auth adapter(kernel-auth-adapter-1.2.0.1.jar) from .
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
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
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
Inji Wallet currently provides support for following credential providers:
Download VC using OpenID for VC Issuance Flow (eSignet)
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 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.mosip.io/v1/mimoto/residentmobileapp/issuers
API used to fetch issuer's configuration: https://api.mosip.io/v1/mimoto/residentmobileapp/issuers/${issuerId}
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 protocol, it is recommended to use issuerMachine.ts
and EsignetMosipVCItemMachine.ts
for workflow to download VC.
If it doesn't support OpenID4VCI
protocol, new state machine needs to be added. Please refer to issuerMachine.ts
and EsignetMosipVCItemMachine.ts
.
At present, Inji Wallet supports verification of VCs which has RSA proof type. If VC is issued with any other proof type, verification will fail and VC will not be downloaded. To bypass this VC verification, we need to use issuer id as "Sunbird".
Refer https://github.com/mosip/mosip-config/blob/collab1/mimoto-issuers-config.json#L71 as reference. Here, credential_issuer should be "Sunbird" and then add all the configuration.
Token endpoint should also use same issuer id. Refer https://github.com/mosip/mosip-config/blob/collab1/mimoto-issuers-config.json#L143
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.
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. certgen.zip
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. Please find the below section detailing the steps.
Following is the process of adding a new partner by the name of “esignet--partner “ onto mimoto.
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.
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. The password here is “mosip123“
The below image shows how to browse and select the esignet-sunbird-partner’s oidckeystore as the second alias. in the decryption password field should have the password of the p12 file, in this case “mosip123“
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.
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 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.
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 expo
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: orange and purple.
The default theme of the app is orange.
To change the theme of the application, go to .env
file and change the value of APPLICATION_THEME
to orange
or purple
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.
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.
The configurable properties for Inji Wallet can be found at . This property file is maintained as one for each deployment environment. On repository, each environment configuration is placed in a corresponding branch specific to that environment.
Refer to of Collab environment.
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.mosip.io/v1/mimoto/residentmobileapp/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.vcDownloadMaxRetry(10)
: The maximum times the application will try to download the requested VC.
mosip.inji.vcDownloadPoolInterval(6000)
: The waiting interval between each retry.
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 domain used to access all Apis.
mosip.inji.aboutInjiUrl(https://docs.mosip.io/inji)
: This is the url for Inji Wallet documentation used in About Inji Wallet page.
mosip.inji.minStorageRequiredForAuditEntry(1)
: This is threshold(minimum storage space required) in MB for storing audit entries.
mosip.inji.minStorageRequired(5)
: This is threshold(minimum storage space required) in MB for storing downloaded / received vc.
Currently, Inji Wallet supports two themes:
orange
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. Orange theme is referred as DefaultTheme.
To change the MOSIP logo:
To change the profile logo which is available as a demo while loading the vc details:
To change the CloseCard
details background:
To change the OpenCard
card details background:
To change the top header icons:
In HomeScreenLayout.tsx
, refer
To change the text, colour and logo for Tabs:
In main.ts
, there are 3 tab screens variables
text
can be changed by name
attribute logo
can be changed by icon
attribute colour
can be changed by color
attribute in MainLayout.tsx
while rendering Navigator
To change the colour of the Details Label Text:
To change the colour of Details Value Text:
To change the colour of +
icon colour:
In HomeScreen.tsx
, refer DownloadFABIcon
component
To change the colour of the Loading Transition:
To change the colour of the Error message:
To change the colour of noUinText:
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:
Text colour
Background colour
Logo change
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
. const { t } = useTranslation('common');
To use with react, must include the key with the 't' function <Text>{t('editLabel')}</Text>
Inji Wallet has the capability to support multiple languages.
i18next
is an internationalization framework. It provides the standard i18n features such as , , , and . It provides a complete solution to localize products from the web to mobile and desktop.
react-i18next
is a set of components, hooks, and plugins that sit on top of i18next, and is specifically designed for React.
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.
Workflow in Inji Wallet is achieved by finite-state machine components. State machines are written using a library called . 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
vc.ts
settings.ts
activityLog.ts
requestMachine.ts
scanMachine.ts
revoke.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:
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 takes care of the VC received in Inji Wallet as a Wallet or Verifier. When Inji Wallet is being used as a Wallet, all the user-downloaded VCs are displayed on the Home screen.
It also keeps track of sharing VC over BLE. When Inji Wallet is being used as a Verifier, all received VCs are displayed under the Received Card option in Settings.
This state machine takes care of VC downloaded via UIN/VID. This contains all the activities/state related to VC like:
downloading VC
sending the event to the store machine to store the VC
activate VC
uses the events from vc.ts
verifies the credentials once received
After a request is made to download a new VC, an event will be sent to this state machine. It will internally check if VC is "ISSUED" successfully, then initiate VC download. It also takes care of retrying in case there is any issue during the download.
Any new feature for a VC is to be added to this state machine.
This state machine takes care of VC downloaded via eSignet. This contains all the activities/state related to VC like:
downloading VC
sending the event to the store machine to store the VC
activate VC
uses the events from vc.ts
This state machine manages the entire OpenID4VCI flow. The issuer state machine calls the endpoints /issuers
and /issuers/<issuer_name>
to display the list of issuers in the user interface, as well as downloads and caches the issuer's configuration. It also performs the following actions:
OIDC authorization using react-native-app-auth
library
generating key-pairs for OpenID4VCI flow
download credential
verify the verifiable credential
store the verifiable credential
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.
Note: This feature is currently disabled in Inji Wallet but underlying support for code is available.
A unique ID can be revoked using Inji Wallet. For example, if the resident has used a VID to generate VCs and no longer wishes to use the VID, then it can be disabled. This state machine will communicate with the backend service to disable the 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.
format: data:image/ base64 encoded image eg: data:image/jpeg
format: data:image/ base64 encoded image eg: data:image/jpeg
Jira issue | Issue description |
---|---|
Jira issue | Severity | Issue description |
---|---|---|
Jira issue | Issue description |
---|---|
Jira issue | Severity | Issue description |
---|---|---|
Module | Version |
---|---|
Jira Issue | Issue Description | Severity |
---|---|---|
Total | Passed | Failed | Skipped(N/A) |
---|---|---|---|
Total Test Cases | Passed | Failed | Skipped(N/A) |
---|---|---|---|
Total Test Cases | Passed | Failed | Skipped(N/A) |
---|---|---|---|
Total Test Cases | Passed | Failed | Skipped(N/A) |
---|---|---|---|
Total Test Cases | Passed | Failed | Skipped(N/A) |
---|---|---|---|
Total Test Cases | Passed | Failed | Skipped(N/A) |
---|---|---|---|
Tested with Components |
---|
Tested with MOSIP Components |
---|
Devices Used For Testing |
---|
Replace http://localhost:8099 by public domain at following places
for iOS development
Configure Expo, refer .
Configure Android SDK, refer .
To address this, please visit the .
Install Java JDK, refer .
Install Android SDK, refer .
Install Node, refer .
Update mimoto url as https://api.collab.mosip.net
Update esignet host as https://esignet.collab.mosip.net
To deploy mimoto in local refer
Follow the to configure Node & npm, Expo and generate debug keystore
Configure XCode, refer .
The VC can be dynamically rendered with all the fields, and if the display properties provided in the, Inji Wallet downloads the .well-known
and applies the below properties on the VC template to modify the VC render.
- stores all the meta information and references of the encrypted VC.
- stores the encrypted VC as a separate file,
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 . 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 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.
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%
Repositories
Tags Released
tuvali
secure-keystore
pixelpass
inji-vci-client
Inji Wallet
Module
Version
Mimoto
inji-config
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
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
mosip-config
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
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.
Repositories
Tags Released
Inji
mimoto
tuvali
mosip-config
Secure-Keystore
mosip-onboarder
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
Repositories
Tags Released
mimoto
mosip-config
Total
Passed
Failed
Skipped
1823
1610
169
44
Total
Passed
Failed
Skipped
1436
1353
68
13
Total
Passed
Failed
Skipped
157
143
14
0
Total
Passed
Failed
Skipped
1279
1210
54
13
Total
Passed
Failed
Skipped
128
112
16
0
Total
Passed
Failed
Skipped
72
64
8
0
Total
Passed
Failed
Skipped
56
48
8
0
Total
Passed
Failed
Skipped
213
155
61
0
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
Mimoto
eSignet
Inji Verify
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
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
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
Repositories
Tags Released
Inji
Mimoto
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
1236
1085
124
27
1236
1085
124
27
64
58
6
0
64
58
6
0
61
59
2
0
61
59
2
0
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
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
Repositories
Tags Released
mimoto
inji
tuvali
mosip-config
secure-keystore
mosip-onboarder
Total
Passed
Failed
Skipped
396
337
40
19
Total
Passed
Failed
Skipped
154
149
5
0
Total
Passed
Failed
Skipped
192
192
0
0
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
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
OK
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.
The individual id. UIN or VID.
Otp channels using which user will be notified, for example - EMAIL, PHONE
OK
The masked email of user
the masked mobile of user.
This API provides the complete configuration details for the specific issuers passed in the path variable
OK
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
Auth factor type to be binded for the provided key.
Format of the auth factor type supported in the wallet app. Right now Inji supports only jwt.
The individual id. UIN or VID.
The public key of the wallet app.
Defines the type of auth challenge. It should be same as authfactor.type (oauth-details response).
Actual challenge as string. A jwt in case of inji.
Format of the challenge provided.
OK
Server certificate after successful binding. This certificate will be stored in wallet app.
the wallet binding id in encrypted format. The wallet app will associate the requested credential with this id.
expiry date time of the binding.
the certificate thumbprint.
the certificate key id.
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'
Transaction id echoed starting from /authorize call.
List of permitted scopes by end-user.
List of accepted essential and voluntary claims by end-user.
OK
This is the same transactionId sent in the link-transaction response.
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'
This is the same transactionId sent in the link-transaction response.
User identifier (UIN/VID).
Authentication Challenge.
Defines the type of auth challenge. It should be same as authfactor.type (oauth-details response).
Actual challenge as string.
Format of the challenge provided.
OK
This is the same transactionId sent in the oauth-details response.
List of Errors in case of request validation / processing failure in Idp server.
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.
Link code as received by the wallet-app from the QR code scanning.
OK
Unique link-transaction-id.
Registered name of the OIDC client.
Registered OIDC client Logo URL.
List of requested scopes to be permitted by the end user.
List of client request mandatory claim names.
List of client request optional claim names.
Auth factors defines the authentication screens displayed in IDP frontend. More than one authFactor may be resolved or combination of auth factors. Precedence of authFactors is based on its order
Name of the authentication method
Applicable for biometric based authentication, number of bio segments to be captured for authentication.
Applicable for biometric based authentication. Can be more specific about which bio segments should be captured.
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.
The proof object MUST contain a proof_type claim of type JSON string denoting the concrete proof type.
When proof_type is jwt, a proof object MUST include a jwt claim
When proof_type is cwt, a proof object MUST include a cwt claim
JSON object containing (and isolating) the detailed description of the credential type. * This object MUST be processed using full JSON-LD processing. * It consists of the following sub claims: * @context: REQUIRED. JSON array * types: REQUIRED. JSON array. This claim contains the type values the Wallet shall request * in the subsequent Credential Request.
OK
JSON string denoting the format of the issued Credential.
Contains issued Credential. MUST be present when acceptance_token is not returned. MAY be a JSON string or a JSON object, depending on the Credential format.