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:
Mimoto is a BFF(Backend for Frontend) for Inji Wallet. It's being used to get default configuration, download verifiable credentials (VC) and activate VC. It provides all necessary APIs to the Inji Wallet and acts as a proxy for resident services. Mimoto gets the request from Inji Wallet, performs all the validations and forwards it to respective services. Additionally, it subscribes to the web-sub event to be able to download the VC once it's ready.
Detailed API documentation of Mimoto is available here.
To get a list of issuers, this API is called. For retrieving the credential types and display properties, .well-known
location is referred for every issuer from the mimoto-issuers-config.json
Inji Wallet allows the users to download VC by redirecting the user to eSignet UI. Multiple APIs are being called to complete the process in the backend.
Inji Wallet initiates authenticate API by redirecting users to eSignet UI. On eSignet UI, user is given option to enter the unique ID, the user is asked to enter an OTP on the next screen. In the backend, token API is called to get a token. Refer here for more details.
After getting a token response, Inji Wallet initiates a download request. Refer here
Credentials have to be activated in order to use them for online login. When a user selects Activate option, an OTP is sent to the user and credentials are activated.
To send an OTP to a user, the below API is called.
After successful OTP validation, a keypair is generated in the phone and the public key is synced with server. The mimoto receives a certificate and create thumbprint which it stores in the keystore securely. This is called as the activation process.
The configurable properties for mimoto can be found at mimoto-default.properties. This property file is maintained as one for each deployment environment. On this repository, each environment configuration is placed in a corresponding branch specific to that environment.
Refer to mimoto-default.properties of Collab environment.
The implementers can choose to use the existing configurations or add new configurations to them.
The user is currently on the +
button on the Home screen, which will open Add new card
screen, where all the issuers are displayed Below issuers list API gives out all the issuers list
To get complete configuration of the specific issuer, below api is called.
The eSignet service is utilized by Inji Wallet for online login and downloading the VC. Users have the ability to log in to any service provider portal that is integrated with eSignet.
The user is required to open the portal integrated with eSignet and utilize the app scanner to scan the QR code.
After successfully scanning the QR code, Inji Wallet will access the API below and transmit the link code.
After successfully completing the offline face authentication and selecting the required and optional information, the two specified APIs are invoked.
The user is currently on the Add new card
screen and chooses the option to Download via eSignet
.
Inji Wallet utilizes the react-native-app-auth
library to authorize and redirect the user to the eSignet user interface. The configuration for redirection is retrieved as part of the issuer's configuration.
Once the user is on the eSignet user interface, they input the necessary information such as a unique ID and OTP (One-time Password). After entering the OTP, the user is redirected back to Inji Wallet in order to generate a key pair and initiate the request to download the credential.
For credential request, refer credential_endpoint attribute in issuer's configuration response.
This 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.