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:
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 mimoto-issuers-config.json of Collab environment.
These values will be used by Inji Wallet via Mimoto. Mimoto exposes APIs which is used by the Inji Wallet application to fetch, store the issuers and their configurations in the local storage.
API used to fetch issuers: https://api.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 OpenID4VCI 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.
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.
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.
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
- 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.
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.