Overview

UI specs of Pre-Registration module are used to configure the form fields in the Demographic Details and Document Upload functionality. UI specs are saved as a JSON file with a list of fields. Each field has a set of attributes/ properties that can be configured which affects the look and feel along with the functionality of the field. Below is the list of all the properties available for each field in the UI specs:

Overview

Pre-registration module enables a resident to:

• enter demographic data and upload supporting documents,

• book an appointment for one or many users for registration by choosing a suitable registration center and a convenient time slot,

• receive appointment notifications,

• reschedule and cancel appointments.

Once the resident completes the above process, their data is downloaded at the respective registration centers prior to their appointment, thus, saving enrollment time. The module supports multiple languages.

MOSIP provides backend APIs for this module along with a reference implementation of pre-registration portal.

Pre-registration process

Create an application

• User provides consent

• User provides demographic information

• User uploads supporting documents (Proof of Address, Birth certificate, etc.)

• A pre-registration request ID known as AID is generated and provided to the user.

Note: The AID was formerly called PRID in the pre-registration context.

Book an appointment

• User selects a registration center based on postal code, geo-location, etc.

• The available slots are displayed

• An option to cancel and re-book the appointment is made available

Receiving acknowledgement notifications

• An acknowledgement is sent via email/SMS

• The user can print the acknowledgement containing AID and QR code.

• This QR code can be scanned at the in-person registration centers.

Download of pre-registration data at registration centers

• User provides the AID/ QR code at the registration center.

• The registration form gets pre-filled with the pre-registration data.

Pre-registration module

The relationship of the pre-registration module with other services is explained here. NOTE: The numbers do not signify sequence of operations or control flow

1. Fetch ID Schema details with the help of Syncdata service.

2. Fetch a new OTP for the user on the login page.

3. Log all events.

4. Pre-Registration interacts with Keycloak via kernel-auth-adapater. The Pre-Reg module communicates with endpoints of other MOSIP modules. However, to access these endpoints, a token is required. This token is obtained from Keycloak.

5. Database used by pre-reg.

6. Generate a new AID for the application.

7. Send OTP in the email/SMS to the user.

8. Registration Processor uses reverse sync to mark the pre-reg application as consumed.

9. Registration clients use Datasync service to get the pre-reg application details for a given registration center, booking date and AID.

10. Request data from MasterData service to get data for dropdowns, locations, consent forms etc..

Services

Pre-registration module consists of the following services:

• Application

• Booking

• Batchjob

• Datasync

• Captcha

For more details, refer to Pre-registration repo.

Pre-registration portal

MOSIP provides a reference implementation of the pre-registration portal that may be customized as per country needs. The sample implementation is available at reference implementation repository. For getting started with the pre-registration, refer to the Pre-registration user guide

Build and deploy

To access the build and read through the deployment instructions, refer to Pre-registration repo.

Configurations

For details related to Pre-registration configurations, refer to Pre-registration configuration.

Developer Guide

To know more about the developer setup, read Pre-registration Developers Guide.

API

Refer API Documentation.

Source code

Github repo.

Overview

This guide helps in understanding the pre-registration sample UI implementation. The pre-registration portal can be used in self-service as well as in assisted mode.

Self-service mode- In this mode, residents can pre-register themselves by accessing the pre-registration portal. They can login with their email address or phone number and fill up the demographic form, upload relevant documents to book an appointment for themselves and their family/friends. Finally, they would receive an acknowledgement along with a pre-registration ID that can be used at the registration center.

Assisted mode- When used in an assisted mode, the operator could be handling the portal and helping other residents in filling up the details and creating an application on their behalf. The languages that the operator and the resident understands, may or may not be the same. If we consider a country with linguistic diversity, the possibilities increase. In such cases, the operator might log in with a language that they are familiar with, and also select a language (data capture language) familiar to the resident for filling up the demographic form and other details.

Pre-registration process

The key steps in this process are:

• Login/create a user account

• Create an application

• Book an appointment

• Receive appointment acknowledgement

To create an application, the resident/operator can follow the steps below:

Login/create a user account

1. Open the browser and visit the pre-registration portal.

2. Select the language of your preference from the dropdown.

3. Enter your valid email address or phone number in the text box.

4. Select the Captcha field.

5. Click Send OTP to receive a One Time Password (OTP) on your provided email address or mobile number.

6. Enter the OTP and click Verify.

Note: If you have not received the One-Time Password (OTP), please click on Send to request another OTP. Enter the newly received OTP to proceed. Once your OTP has been successfully verified, you will be able to create, view, or update your pre-registration application.

Create an application

Step 1: Select the language for providing data

1. Once the OTP is verified, you will see a pop up for selecting the languages for data entry.

2. Select the languages and click Submit.

Note:

• This choice will be available only if the ID issuer has configured the usage of optional languages.

• Countries will have multiple languages some of which will be mandatory while others could be optional(regional languages). MOSIP provides a configuration using which a country can mandate the capture of demographic data in required number of languages (combination of mandatory and optional).

Step 2: Provide consent

1. On the Demographic details page, read the Terms and Conditions and select the check box to agree. This agreement is to provide consent for the storage and processing of your personal information.

2. Click Accept and proceed.

Note: User consent is mandatory for creating/updating applications. The contents on this page will be displayed in all data capture languages selected.

Step 3: Enter Demographic details

1. Enter your demographic details, which includes Name, Age/DOB, Gender, Residential Status, Address, Mobile Number, Email Id, etc.

2. You can also change or verify your demographic details in the other selected language.

3. After you have filled and verified your demographic details, click Continue.

Note: The mandatory fields/labels have a * mark. Field and button labels, error and information messages will be displayed in the user preferred language selected in the login screen. The fields displayed on this screen are configurable based on the ID schema defined by the country.

UI specs of Pre-registration module are used to configure the form fields in the Demographic Details and Document Upload functionality pages. These specs are saved as a JSON file with a list of fields.

Step 4: Upload documents

1. Select the document (e.g. Passport, Reference Identity Number, etc.) from the document drop-down list.

2. Click Browse to locate the scanned document on your machine.

3. Select the file that you want to upload.

4. When the file is uploaded successfully, the document will appear on the right side. Verify that you have uploaded the correct document.

5. Repeat the steps above to upload document(s) for each applicable document category.

6. When adding an applicant, if a newly added applicant’s Proof of Address (POA) document is same as that of the existing user’s POA, which has been already uploaded, click Same As option and select the name of the applicant.

7. Click Continue to preview your application.

Step 5: Preview data

1. To change the demographic details (Name, Age, etc.), click modify at the top-right corner adjacent to the Demographic details section.

2. To modify the uploaded documents, click modify at the bottom-right corner adjacent to the Documents Uploaded section and make changes.

3. To add a new applicant, click Add Applicant. On clicking the Add Applicant option, you will be navigated to the Demographic details page to provide Consent and proceed with providing the required demographic data and upload of documents.

4. Click Continue.

Add new application

On Your Applications page, click Create New Application to generate a new application.

Viewing applications

Once the application is created, there could be multiple statuses depending on the data filled by the user/resident or the actions performed by them. The user can view all the pre-registration applications created by them in the Dashboard. The different statuses with a brief explanation are mentioned below:

• The applications are sorted and displayed by the order of creation of application. The last application created appears first in the list.

• If the user visits the registration center and consumes the appointment, then the application will be removed from the list.

• If the appointment date has passed, the status changes to "Expired" and is retained on the dashboard for further rebooking/modification as required.

Book an appointment

Choose a registration center

• The recommended registration centers are automatically displayed based on your demographic details (Postal Code)

• On the Book Appointment page, you can find a registration center through the three options as follows:

  • Click Nearby centers to view the registration centers based on your geographical location.

  • Use the search box to find the registration center based on your search criteria.

  • Click Recommended Centers to view registration centers based on your demographic details. (Postal Code)

• Click Continue.

Note: The default display of registration centers will be based on the Postal Code of the user. To modify this setting, please update the location hierarchy in the pre-registration-default.properties file using the property: preregistration.recommended.centers.locCode.

Select an appointment time-slot

• Select your preferred date from the list of available calendar days and the number of available bookings.

• The list of available time slots for your selected date is categorized between Morning and Afternoon.

• Select your preferred time slot from the list.

• Select the particular applicant name to book an appointment (click + to add the applicant). Note: On clicking the Add Applicant option, you will be navigated to the Demographic Details page to provide Consent and proceed with providing the required demographic data/documents.

• Verify the time slot(s) as selected against the applicant name(s).

• Click Continue.

• On the confirmation pop-up, click Confirm.

• Click OK.

Receive appointment acknowledgement

• After successful completion of the Pre-registration application, you will receive an acknowledgment on the registered phone number (SMS) or email address as per details provided in the demographic form.

• The acknowledgement contains the following information: name, pre-registration ID, age/DOB, mobile number, email id and registration center details, appointment date, appointment time)

• A QR code containing the pre-registration ID is generated. This QR code can be scanned at the registration center to fetch the details to be used during the registration process.

• You can print, download, email or SMS your acknowledgment.

  • To print your acknowledgement, click Print.

  • To download your acknowledgement, click Download PDF.

• To add the additional recipient(s) to receive the acknowledgment of your application, follow these steps:

  • Click Send Email/SMS.

  • Enter the mobile number and/or enter the email ID.

  • Click Send to receive the acknowledgement on your provided e-mail address or mobile number.

Re-book appointment

1. On Your Applications page, select the check box for the applicable applicant.

2. Click Book/Modify Appointment to re-book an appointment (on the top right corner)..

3. The user can select any appointment date available and the appointment slot available

4. A user cannot re-book the appointment if the appointment booking is less than 48 hours (configurable) from the time of booking

Discard application

1. On Your Applications page, click on delete icon against pre-registration application of an applicant, a pop-up window appears on the screen.

2. Select the Discard entire application option in the pop-up window.

3. Click SUBMIT to discard your application.

Cancel appointment

1. On Your Applications page, click on delete icon against pre-registration application of an applicant, a pop-up window appears on the screen.

2. Select Cancel appointment and save the details option in the pop-up window.

3. Click SUBMIT to cancel an appointment.

Following a successful appointment cancellation, the system unlocks the time slot of the registration center to ensure that someone else can book it.

Overview

Identity Lifecycle Management refers to the process of issuing and managing user identities in a given system. An individual can visit a registration centre to get a new ID or update their ID details. A registration officer would typically capture the individual’s demographic (name, date of birth, gender, etc.) and biometric (face, iris, and fingerprint image) details.

The lifecycle of an identity involves multiple events, categorized into different stages, each managed within specific system modules. The following sections outline these key lifecycle events, detailing their roles and functions categorized under relevant modules. Head below to explore the various applications and services that support Identity Lifecycle Management.

Overview

The documentation here will guide you through the pre-requisites required for Pre-registration developer setup.

Software setup

Below are the list of tools required in Pre-registration

1. JDK 11

2. Any IDE (Eclipse, IntelliJ IDEA)

3. Apache Maven (zip folder)

4. pgAdmin

5. Postman

6. Git

7. lombok.jar (file)

8. MOSIP Pre-registration specific JARs: The version will depend on which Pre Registration branch you have cloned. If it is "release-1.2.0.1" then you can download 1.2.0.1.B1 or 1.2.0.1.B2 version of below jars whichever is available.

   • kernel-auth-adapter

   • kernel-transliteration-icu4j

   • kernel-ref-idobjectvalidator

   • kernel-virusscanner-clamav

9. settings.xml

10. Notepad++ (optional)

Follow the steps below to setup Pre-registration on your local system

1. Fork the MOSIP Pre-registration repository from Github MOSIP repository to your GitHub account.

2. Clone the forked repository into your local machine.

   • git clone https://github.com/${urgithubaccname}/pre-registration.git

   • git remote add upstream https://github.com/mosip/pre-registration.git

   • git remote set-url --push upstream no_push

   • git remote -v

   • git checkout -b my-release-1.2.0.1

   • git fetch upstream

   • git rebase upstream/release-1.2.0.1

3. Inside settings.xml change local repository directory to your directory name where .m2 folder is located. E.g.: <localRepository>C:/Users/username/.m2/repository</localRepository>

4. Add settings.xml inside .m2 folder (Maven Folder). E.g.: C:\Users\username\.m2

5. Import the project in Eclipse IDE and it starts updating Maven projects configuration, refreshing workspaces, project starts building (downloading sources, javadoc).

6. Add downloaded lombok.jar to project, click on downloaded JAR and install specifying Eclipse IDE(eclipse.exe) location.

1. Configure the JDK (Standard VM) with your Eclipse by traversing through Preferences → Java → Installed JREs.

1. Add MOSIP Pre-registration specific JARs from Maven central:

   • Adding JARs to Build Path: Right click on service -> Build Path -> Configure Build Path -> click on Classpath -> Add External JARs -> Add required JARs -> Apply and close.

1. Add auth-adapter, transliteration, ref-idobjectvalidator, virusscanner, lombok JARs to pre-registration-application-service, pre-registration-datasync-service classpath.

2. Add auth-adapter, lombok JARs to pre-registration-core, pre-registration-batchjob, pre-registration-captcha-service, pre-registration-booking-service classpath.

3. Run mvn clean install -Dgpg.skip=true command to build locally and to execute test cases.

4. Update Maven dependencies: Maven syncs the Eclipse project settings with that of the pom. It downloads dependencies required for the project.

5. Build and run the Project.

6. To run the pre-registration-application-service locally without config server, update values in application.properties and bootstrap.properties:

• spring.cloud.config.uri=https://localhost:8080

• spring.cloud.config.label=develop

• spring.cloud.config.name=pre-registration

• spring.application.name=pre-registration-application-service

• spring.profiles.active=default Point below urls to a valid env which has MOSIP setup:

• mosip.base.url=https://yourenvurl

• auth-token-generator.rest.issuerUrl:https://iam.yourenvurl/auth/realms/mosip

• javax.persistence.jdbc.password: XXXXXX

• javax.persistence.jdbc.url=jdbc:postgresql://yourenvurl:5432/mosip_prereg

• mosip.batch.token.authmanager.password: XXXXXX

• mosip.iam.adapter.appid=prereg

• mosip.iam.adapter.clientsecret=XXXXXX

• auth.server.admin.issuer.uri=https://iam.yourenvurl/auth/realms/

Developer setup for MOSIP Pre-registration UI

1. Fork the Pre-registration UI repo to your GitHub account.

2. Clone the forked repository into your local machine.

• git clone https://github.com/${urgithubaccname}/pre-registration-ui.git

• git remote add upstream https://github.com/mosip/pre-registration-ui.git

• git remote set-url --push upstream no_push

• git remote -v

• git checkout -b my-release-1.2.0.1

• git fetch upstream

• git rebase upstream/release-1.2.0.1

1. Install all dependencies with npm install.

2. Install Angular JS npm install -g @angular/cli.

3. Start the Angular JS server ng serve.

4. Open http://localhost:4200 to access the application.

5. You will face CORS issue since API Services are hosted on https://{env}.

Using the Angular CLI proxy solution to get around CORS issue

1. Update the API services BASE_URL in config.json:

   • config.json is found inside assets directory.

   • E.g.: C:\MOSIP\pre-registration-ui\pre-registration-ui\src\assets\config.json

   Copy

   {
   "BASE_URL": "https://localhost:4200/proxyapi/",
   "PRE_REG_URL": "preregistration/v1/"
   }

2. Create a new file named proxy.conf.json:

   Location should be in C:\MOSIP\pre-registration-ui\pre-registration-ui\proxy.conf.json project folder.

   Copy

   {
    "/proxyapi": {
     "target": "https://{env}/",
     "secure": true,
     "changeOrigin": true,
     "pathRewrite": {
       "^/proxyapi": ""
         }
       }
     }

3. Start the server by executing ng serve --proxy-config proxy.conf.json --ssl true.

4. Open the browser, load the app with https://localhost:4200.

Pre-registration API

1. For API documentation, refer here.

2. The APIs can be tested with the help of Swagger-UI and Postman.

3. Swagger is an interface description language for describing restful APIs expressed using JSON. You can access Swagger-UI of pre-registration here:

   • Pre-registration Application service : https://{env}/preregistration/v1/application-service/swagger-ui.html

   • Pre-registration Datasync Service : https://{env}/preregistration/v1/sync/datasync-service/swagger-ui.html

   • Pre-registration Captcha service : https://{env}/preregistration/v1/captcha/swagger-ui.html

   • Pre-registration Booking service : https://{env}/preregistration/v1/appointment/booking-service/swagger-ui.html

The Registration Client is a thick Java-based client where the resident's demographic and biometric details are captured along with the supporting documents in online or offline mode. Data is captured in the form of registration packets and is cryptographically secured to ensure that there is no tampering. The captured information is packaged and sent to the server for further processing.

MOSIP provides a reference implementation of a Java-based Registration Client. The code, build files for the Registration Client are available in the Registration Client repo.

Multiple language support

• Registration Client is featured to allow an operator to choose the operation language. Option to select their preferred language is provided on the login screen.

• Data collection during registration client supports more than one language at a time.

• Before starting any registration process, the operator can choose the languages amongst the configured ones.

To know more about setting up the reference registration client, refer to Registration Client Installation Guide.

To know more about the features present in the Registration Client, refer to Registration Client User Guide.

Who operates the Registration Client?

The Registration Client can be operated by an operator who can be either a Supervisor or an Officer. They can login to the client application and perform various activities. The Supervisor and the Officer can perform tasks like Onboarding, Synchronize Data, Upgrade software, Export packet, Upload packets, View Re-registration packets, Correction process, Exception authentication, etc. In addition to this, the Supervisor has exclusive authority to Approve/reject registrations.

To know more about the onboarding process of an operator, refer to Operator onboarding.

Registration Client entity diagram

The relationship of Registration Client with other services is explained here. NOTE: The numbers do not signify sequence of operations or control flow.

1. Registration Client connects to the Upgrade Server to check on upgrades and patch downloads.

2. All the masterdata and configurations are downloaded from SyncData-service.

3. Registration Client always connects to external biometric devices through SBI.

4. Registration Client scans the document proofs from any document scanner.

5. Acknowledgement receipt print request is raised to any connected printers.

6. Packets ready to be uploaded meta-info are synced to Sync Status service. Also, the status of already uploaded packets are synced back to Registration Client.

7. All the synced packets are uploaded to Packet Receiver service one by one.

The image below shows the setup of Registration Client Host machine.

1. Registration Client comprises of JavaFX UI, Registration-services libaries and any third party biometric-SDK.

2. SBI is allowed to run on loopback IP and should listen on any port within 4501-4600 range. More than one SBI can run on the host machine. Registration Client scans the allowed port range to identify the available SBI.

3. Registration Client connects to local Derby database. This is used to store all the data synced.

4. All the completed registration packets are stored under packetstore directory.

5. .mosipkeys directory is used to store sensitive files. db.conf under this directory stores encrypted DB password. This is created on the start of registration client for the first time.

6. TPM - is the hardware security module used to get machine identifier, to secure DB password, prove the client authenticity on auth requests and packets created in the host machine.

Data protection

• The registration packets and synced data are stored in the client machine.

• Most of the synced data are stored in the Derby DB. Derby DB is encrypted with the bootpassword.

• Derby DB boot password is encrypted with machine TPM key and stored under .mosipkeys/db.conf.

• Synced UI-SPEC/script files are saved in plain text under registration client working directory. During sync, SPEC/script file hash is stored in derby and then the files are saved in the current working directory. Everytime the file is accessed by the client performs the hash check.

• Synced pre-registration packets are encrypted with TPM key and stored under configured directory.

• Directory to store the registration packets and related registration acknowledgments is configurable.

• Registration packet is an signed and encrypted ZIP.

• Registration acknowledgment is also signed and encrypted with TPM key.

Background Tasks

The Registration Client runs background tasks to keep data synchronized with the Registration Processor. It continuously updates the server with newly created packets and syncs additional metadata to improve packet recovery in case of a client failure.

Another background task handles packet uploads. If supervisor approval is required ('y'), approved packets are uploaded in batches. If approval is not required ('n'), packets are uploaded during the next scheduled job. With this feature, the registration client has fully capable auto upload.

You can configure these settings in the Scheduled Jobs and Batch Configuration sections.

Configurations

Registration Client can be customized as per a country' requirements. For details related to Registration Client configurations, refer to Registration Client configuration.

UI Specifications for Registration Tasks

• Blueprint of registration forms to be displayed in registration client are created as json called as UI-SPEC.

• Every process ( NEW / LOST / UPDATE UIN / CORRECTION ) has its own UI-SPEC json.

• Kernel-masterdata-service exposes API's to create and publish UI-SPEC.

• Published UI-SPEC json are versioned.

• Only published UI-SPEC are synced into registration-client.

• UI-SPEC json files are tamper proof, client checks the stored file hash everytime it tries to load registration UI.

• UI-SPEC json will fail to load if tampered.

Default UI Specifications loaded with Sandbox installation is available here

Developer Guide

To know more about the developer setup, read Registration Client Developers Guide.

Overview

The registration UI forms are rendered using respective UI specification JSON. This is derived from the ID Schema defined by a country. Here, we would be discussing about the properties used in the UI specification of Registration Client.

In the Registration Client, currently, Registration Tasks(process) forms are configurable using the UI specifications.

Each process has multiple screens and each screen is rendered with one or more fields.

Process/ Task spec JSON template

{
    "id": "<NEW/UPDATE/LOST/BIOMETRIC_CORRECTION process name as passed in the packet>",
    //order in which the process is displayed on the registration client home screen
    "order": 1,
    "flow": "<NEW/UPDATE/LOST/CORRECTION>",
    //Multi-lingual labels displayed based on the logged in language
    "label": {
        "eng": "Registration",
        "ara": "تسجيل",
        "fra": "Inscription"
    },
    //screen details - follows screen spec structure
    "screens": [
        {}
    ],
    //caption displays on-hover content
    "caption": {
        "eng": "Registration",
        "ara": "تسجيل",
        "fra": "Inscription"
    },
    //icon is the symbol that appears before the process label
    "icon": "registration.png",
    "isActive": true,
    //group names that should be by default selected during UDPATE UIN process
    "autoSelectedGroups": [
        ""
    ]
}

Screen spec JSON template

    //Order of the screen in registration page
    "order": 1,
    "name": "<unique identifier for the screen>",
    "label": {
        "ara": "شاشة عينة",
        "fra": "Exemple d'écran",
        "eng": "Sample screen"
    },
    "caption": {
        "ara": "شاشة عينة",
        "fra": "Exemple d'écran",
        "eng": "Sample screen"
    },
    //field details - follows field spec structure
    "fields": [
        {}
    ],
    "layoutTemplate": null,
    //displays field to provide pre-reg application ID, data fetched from pre-reg application will be pre-filled in the current registration form
    "preRegFetchRequired": true,
    //enable below flag to capture additionalInfo request ID , applicable only during correction process
    "additionalInfoRequestIdRequired": false,
    //show or hide screens 
    "active": true
}

Field spec JSON template

{
    "id": "<Unique identifier for the field, must be same as that described in the ID Schema>",
    //inputRequired is used to identify if UI input is needed or not
    "inputRequired": true,
    //type defines the datatype of the field, must be same as that is defined in the ID Schema
    "type": "<string/simpleType/documentType/biometricsType>",
    "controlType": "textbox/fileupload/dropdown/checkbox/button/date/ageDate/html/biometrics",
    //minimum- applicable only for date controlType(defined in days)
    "minimum": 0,
    //maximum- applicable only for date controlType(defined in days)
    "maximum": 365,
    "description": "<Field description>",
    "label": {
        "ara": "حقل العينة",
        "fra": "Exemple de champ",
        "eng": "Sample Field"
    },
    //fieldType is used to identify if it is a dynamic field
    "fieldType": "<default/dynamic>",
    //to validate the format should be in upper or lower case
    "format": "<lowercase/uppercase/none>",
    //list of validators for the field
    "validators": [
        {
            //type of validation engine (currently, only regex is supported)
            "type": "regex",
            //expression for the validation
            "validator": "^([0-9]{10,30})$",
            //list of arguments needed for the validator
            "arguments": [],
            //if null, its applicable for all languages, else validator expression can be provided for each langCode
            "langCode": null,
            /*error code to be used to display specific error message, if null, generic validation error message is displayed
                      There error codes must be configured in registration client i18n files*/
            "errorCode": "UI_100001"
        }
    ],
    //determines sharing and longevity policies applicable as defined in ID Schema
    "fieldCategory": "<pvt/evidence/kyc>",
    "alignmentGroup": "<fields belonging to same alignment group are placed horizontally next to each other>",
    //determines when to display and hide the field(set null if the field has to be displayed always)
    "visible": {
        "engine": "MVEL",
        "expr": "identity.get('ageGroup') == 'INFANT' && (identity.get('introducerRID') == nil || identity.get('introducerRID') == empty)"
    },
    "contactType": null,
    //used to group together the list of fields(only applicable in the Update UIN process)
    "group": "<grouping used in update UIN process>",
    "groupLabel": {
        "eng": "Sample group",
        "ara": "مجموعة العينة",
        "fra": "Groupe d'échantillons"
    },
    /*on change of the field value, configured Action will be triggered on other fields
                  Change action handlers should be implemented in registration client*/
    "changeAction": null,
    //enable or disable auto-transliteration
    "transliterate": false,
    /*provide the templateName(applicable only for html controlType fields)
          These templates should be configured in templates table*/
    "templateName": null,
    "fieldLayout": null,
    "locationHierarchy": null,
    //On any biometric exception, Need to capture exception photo as proof if the below flag is enabled
    "exceptionPhotoRequired": true,
    /*applicable only for BiometricsType field, defines the list of attributes to be captured
          All the supported biometric attributes are listed down for reference*/
    "bioAttributes": [
        "leftEye",
        "rightEye",
        "rightIndex",
        "rightLittle",
        "rightRing",
        "rightMiddle",
        "leftIndex",
        "leftLittle",
        "leftRing",
        "leftMiddle",
        "leftThumb",
        "rightThumb",
        "face"
    ],
    //capture of above mentioned bioAttributes can be conditionally mandated based on age group
    "conditionalBioAttributes": [
        {
            "ageGroup": "INFANT",
            "process": "ALL",
            "validationExpr": "face || (leftEye && rightEye)",
            "bioAttributes": [
                "face",
                "leftEye",
                "rightEye"
            ]
        }
    ],
    //set true/false to mark the field as mandatory or optional
    "required": true,
    //if requiredOn is defined, the evaluation result of requiredOn.expr takes the priority over "required" attribute
    "requiredOn": [
        {
            "engine": "MVEL",
            "expr": "identity.get('ageGroup') == 'INFANT' && (identity.get('introducerRID') == nil || identity.get('introducerRID') == empty)"
        }
    ],
    //used to identify the type of field
    "subType": "<document types / applicant / heirarchy level names>"
}

Sample correction process SPEC: Biometric Correction

{
   "id": "BIOMETRIC_CORRECTION",
   "order": 4,
   "flow": "CORRECTION"
   "label": {
       "eng": "Biometric correction",
       "ara": "التصحيح البيومتري",
       "fra": "Correction biométrique"
   },
   "screens": [
       {
           "order": 1,
           "name": "consentdet",
           "label": {
               "ara": "موافقة",
               "fra": "Consentement",
               "eng": "Consent"
           },
           "caption": {
               "ara": "موافقة",
               "fra": "Consentement",
               "eng": "Consent"
           },
           "fields": [
               {
                   "id": "consentText",
                   "inputRequired": true,
                   "type": "simpleType",
                   "minimum": 0,
                   "maximum": 0,
                   "description": "Consent",
                   "label": {},
                   "controlType": "html",
                   "fieldType": "default",
                   "format": "none",
                   "validators": [],
                   "fieldCategory": "evidence",
                   "alignmentGroup": null,
                   "visible": null,
                   "contactType": null,
                   "group": "consentText",
                   "groupLabel": null,
                   "changeAction": null,
                   "transliterate": false,
                   "templateName": "Registration Consent",
                   "fieldLayout": null,
                   "locationHierarchy": null,
                   "conditionalBioAttributes": null,
                   "required": true,
                   "bioAttributes": null,
                   "requiredOn": [],
                   "subType": "consentText"
               },
               {
                   "id": "consent",
                   "inputRequired": true,
                   "type": "string",
                   "minimum": 0,
                   "maximum": 0,
                   "description": "consent accepted",
                   "label": {
                       "ara": "الاسم الكامل الكامل الكامل",
                       "fra": "J'ai lu et j'accepte les termes et conditions pour partager mes PII",
                       "eng": "I have read and accept terms and conditions to share my PII"
                   },
                   "controlType": "checkbox",
                   "fieldType": "default",
                   "format": "none",
                   "validators": [],
                   "fieldCategory": "evidence",
                   "alignmentGroup": null,
                   "visible": null,
                   "contactType": null,
                   "group": "consent",
                   "groupLabel": null,
                   "changeAction": null,
                   "transliterate": false,
                   "templateName": null,
                   "fieldLayout": null,
                   "locationHierarchy": null,
                   "conditionalBioAttributes": null,
                   "required": true,
                   "bioAttributes": null,
                   "requiredOn": [],
                   "subType": "consent"
               },
               {
                   "id": "preferredLang",
                   "inputRequired": true,
                   "type": "string",
                   "minimum": 0,
                   "maximum": 0,
                   "description": "user preferred Language",
                   "label": {
                       "ara": "لغة الإخطار",
                       "fra": "Langue de notification",
                       "eng": "Notification Langauge"
                   },
                   "controlType": "button",
                   "fieldType": "dynamic",
                   "format": "none",
                   "validators": [],
                   "fieldCategory": "pvt",
                   "alignmentGroup": "group1",
                   "visible": null,
                   "contactType": null,
                   "group": "PreferredLanguage",
                   "groupLabel": null,
                   "changeAction": null,
                   "transliterate": false,
                   "templateName": null,
                   "fieldLayout": null,
                   "locationHierarchy": null,
                   "conditionalBioAttributes": null,
                   "required": true,
                   "bioAttributes": null,
                   "requiredOn": [],
                   "subType": "preferredLang"
               }
           ],
           "layoutTemplate": null,
           "preRegFetchRequired": false,
           "additionalInfoRequestIdRequired": false,
           "active": false
       },
       {
           "order": 2,
           "name": "BiometricDetails",
           "label": {
               "ara": "التفاصيل البيومترية",
               "fra": "Détails biométriques",
               "eng": "Biometric Details"
           },
           "caption": {
               "ara": "التفاصيل البيومترية",
               "fra": "Détails biométriques",
               "eng": "Biometric Details"
           },
           "fields": [
               {
                   "id": "individualBiometrics",
                   "inputRequired": true,
                   "type": "biometricsType",
                   "minimum": 0,
                   "maximum": 0,
                   "description": "",
                   "label": {
                       "ara": "القياسات الحيوية الفردية",
                       "fra": "Applicant Biometrics",
                       "eng": "Applicant Biometrics"
                   },
                   "controlType": "biometrics",
                   "fieldType": "default",
                   "format": "none",
                   "validators": [],
                   "fieldCategory": "pvt",
                   "alignmentGroup": null,
                   "visible": null,
                   "contactType": null,
                   "group": "Biometrics",
                   "groupLabel": null,
                   "changeAction": null,
                   "transliterate": false,
                   "templateName": null,
                   "fieldLayout": null,
                   "locationHierarchy": null,
                   "conditionalBioAttributes": [
                       {
                           "ageGroup": "INFANT",
                           "process": "ALL",
                           "validationExpr": "face",
                           "bioAttributes": [
                               "face"
                           ]
                       }
                   ],
                   "required": true,
                   "bioAttributes": [
                       "leftEye",
                       "rightEye",
                       "rightIndex",
                       "rightLittle",
                       "rightRing",
                       "rightMiddle",
                       "leftIndex",
                       "leftLittle",
                       "leftRing",
                       "leftMiddle",
                       "leftThumb",
                       "rightThumb",
                       "face"
                   ],
                   "requiredOn": [],
                   "subType": "applicant"
               },
               {
                   "id": "proofOfException",
                   "inputRequired": false,
                   "type": "documentType",
                   "minimum": 0,
                   "maximum": 0,
                   "description": "proofOfException",
                   "label": {
                       "ara": "إثبات الاستثناء",
                       "fra": "Exception Proof",
                       "eng": "Exception Proof"
                   },
                   "controlType": "fileupload",
                   "fieldType": "default",
                   "format": "none",
                   "validators": [],
                   "fieldCategory": "evidence",
                   "alignmentGroup": null,
                   "visible": null,
                   "contactType": null,
                   "group": "Documents",
                   "groupLabel": null,
                   "changeAction": null,
                   "transliterate": false,
                   "templateName": null,
                   "fieldLayout": null,
                   "locationHierarchy": null,
                   "conditionalBioAttributes": null,
                   "required": false,
                   "bioAttributes": null,
                   "requiredOn": [],
                   "subType": "POE"
               }
           ],
           "layoutTemplate": null,
           "preRegFetchRequired": false,
           "additionalInfoRequestIdRequired": true,
           "active": false
       }
   ],
   "caption": {
       "eng": "Biometric correction",
       "ara": "التصحيح البيومتري",
       "fra": "Correction biométrique"
   },
   "icon": "UINUpdate.png",
   "isActive": true,
   "autoSelectedGroups": null
}

Overview

The guide here lists down some of the important properties that may be customized for a given installation. Note that the listing here is not exhaustive, but a checklist to review properties that are likely to be different from default. If you would like to see all the properties, then refer to the files listed below.

Configuration files

application-default.properties
registration-default.properties

See Module Configuration for the location of these files.

SBI related configurations

Registration Client reaches SBI on 127.0.0.1 within the below configured port range. As per SBI spec, the allowed port range is from 4501 to 4600.

mosip.registration.mdm.portRangeFrom=4501
mosip.registration.mdm.portRangeTo=4600

Timeouts in milliseconds are set during any http calls to SBI.

mosip.registration.mdm.connection.timeout=10000
mosip.registration.mdm.RCAPTURE.connection.timeout=40000
mosip.registration.mdm.MOSIPDINFO.connection.timeout=5000
mosip.registration.mdm.MOSIPDISC.connection.timeout=5000

Quality score threshold based on modality, Possible values 1 to 100

mosip.registration.leftslap_fingerprint_threshold=40
mosip.registration.rightslap_fingerprint_threshold=40
mosip.registration.thumbs_fingerprint_threshold=40
mosip.registration.iris_threshold=60
mosip.registration.face_threshold=9

Retry attempts, Possible values 1 to 10

mosip.registration.num_of_fingerprint_retries=3
mosip.registration.num_of_iris_retries=3
mosip.registration.num_of_face_retries=3

Quality score threshold based on the modality for operator authentication, Possible values 1 to 100

mosip.fingerprint_authentication.quality_score=30
mosip.iris_authentication.quality_score=30
mosip.face_authentication.quality_score=30

SDK

Registration clients can be integrated with more than one bio-sdks. Possible values for "modality-name" are "finger", "iris" or "face".

• SDK implementation class full name

mosip.biometric.sdk.providers.<modality-name>.<vendor-name>.classname

• SDK API version

mosip.biometric.sdk.providers.<modality-name>.<vendor-name>.version

• SDK implementation class constructor args - comma separated

mosip.biometric.sdk.providers.<modality-name>.<vendor-name>.args

• SDK initialization args, this will be passed as initparams

mosip.biometric.sdk.provider.<modality-name>.<vendor-name>.<key1>=<value1>

• Quality threshold used by SDK to match modality

mosip.biometric.sdk.providers.<modality-name>.<vendor-name>.threshold

Example configurations are shown below for MOCK SDK named as mockvendor:

mosip.biometric.sdk.providers.finger.mockvendor.classname=io.mosip.mock.sdk.impl.SampleSDK
mosip.biometric.sdk.providers.finger.mockvendor.version=0.9
mosip.biometric.sdk.providers.finger.mockvendor.args=
mosip.biometric.sdk.providers.finger.mockvendor.threshold=60
mosip.biometric.sdk.providers.iris.mockvendor.classname=io.mosip.mock.sdk.impl.SampleSDK
mosip.biometric.sdk.providers.iris.mockvendor.version=0.9
mosip.biometric.sdk.providers.iris.mockvendor.args=
mosip.biometric.sdk.providers.iris.mockvendor.threshold=60
mosip.biometric.sdk.providers.face.mockvendor.classname=io.mosip.mock.sdk.impl.SampleSDK
mosip.biometric.sdk.providers.face.mockvendor.version=0.9
mosip.biometric.sdk.providers.face.mockvendor.args=
mosip.biometric.sdk.providers.face.mockvendor.threshold=60

On every successful biometric capture during registration, the Quality of the biometrics is computed by bio-sdk if below config is enabled. Possible values are Y/N.

mosip.registration.quality_check_with_sdk=Y

Batch size

Jobs like RID sync, packet upload, and status sync are carried out in batches, number of registration records to be executed in a batch on every trigger.

mosip.registration.rid_sync_batch_size=5
mosip.registration.packet_upload_batch_size=5
mosip.registration.status_sync_batch_size=5

Operator onboarding bio-attributes

Only the modalities configured will be collected during operator onboarding.

mosip.registration.operator.onboarding.bioattributes=leftLittle,leftRing,leftMiddle,leftIndex,leftThumb,rightLittle,rightRing,rightMiddle,rightIndex,rightThumb,leftEye,rightEye,face

Pre-Registration sync

On every Pre-Registration application fetch in the registration page, clear all the captured data before the Pre-Registration application fetch. Set the field IDs which should not be cleared after the Pre-Registration application fetch. It is a comma-separated list of field ids as per UI-SPEC.

mosip.registration.fields.to.retain.post.prid.fetch=consent,consentText,preferredLang

Storage Location to store the downloaded Pre-Registration Packets in the local system

mosip.registration.registration_pre_reg_packet_location=PreRegPacketStore

Pre-registration applications fetch period, No. of days before the appointment date.

mosip.registration.pre_reg_no_of_days_limit=7

Scheduled Jobs

Comma-separated list of offline job IDs. Offline jobs are jobs that are not part of manual sync.

mosip.registration.jobs.offline=DEL_J00013,RDJ_J00010,ADJ_J00012,PVS_J00015

Comma separated list of untagged job IDs. Untagged jobs, which will be not part of manual sync but only from the scheduler.

mosip.registration.jobs.unTagged=PDS_J00003

Comma separated list of job IDs that need Registration Client restart.

mosip.registration.jobs.restart=RCS_J00005

Registration batch jobs scheduler.

mosip.registration.jobs.scheduler.enable=Y

Default CRON expression for scheduling the Jobs.

mosip.registration.sync_jobs_restart_freq=0 0 */11 ? * *

Document scan

All the identified scanner implementations will be used to list the identified devices. For each device dpi, width and height can be configured. If it is not configured, it defaults to 0.

Values in this config mosip.registration.docscanner.id map support regex.

mosip.registration.docscanner.id={ "id1" : "STUB-SCANNER", "id2" : "S600" }
mosip.registration.docscanner.dpi={ "id1" : 200, "id2" : 300 }
mosip.registration.docscanner.width={ "id1" : 200, "id2" : 350 }
mosip.registration.docscanner.height={ "id1" : 200, "id2" : 400 }

GPS Device Connection

• Enable GPS device for capturing the geo-location. If y, the GPS device will be enabled. If n, the GPS device will be disabled.

mosip.registration.gps_device_enable_flag=N

• Model of the GPS Device

mosip.registration.gps_device_model=GPSBU343Connector

• Timeout for connecting to GPS device

mosip.registration.gps_port_timeout=1000

• GPS Serial Port in Linux machine

mosip.registration.gps_serial_port_linux=/dev/ttyusb0

• GPS Serial Port in Windows machine

mosip.registration.gps_serial_port_windows=

• The Distance Parameter for GPS Verification

mosip.registration.distance.from.machine.to.center=900000

Other configurations

Resetting Password in Registration Client

To reset a password in the Registration Client, click Reset Password from the Actions menu in the top-right corner of the Home page. This redirects the operator to a configurable URL:

mosip.registration.reset_password_url=${mosip.api.internal.url}/keycloak/auth/realms/mosip/account/

Supervisor Packet Approval Configuration

This configuration determines whether supervisor approval is required before the Sync and Upload of registration packets.

• If enabled (Y), the system requires a supervisor to review and approve the registration packets before it is synched and uploaded.

mosip.registration.supervisor_approval_config_flag=Y

• If disabled (N), the registration proceeds auto approving, and packets are automatically uploaded in the next scheduled job.

Additionally, the system will cross-check the resident’s biometrics with locally stored operator biometric templates to verify the registration.

mosip.registration.mds.deduplication.enable.flag=N

Minimum disk space that should be available in the machine to proceed with registration - in MB

mosip.registration.disk_space_size=5

Location to store registration packets in the client machine:

  object.store.base.location=packets

Number of days allowed to start Registration Client without upgrade when software upgrade is available.

mosip.registration.softwareUpdateCheck_configured_frequency=60

Time in Seconds for forced log-out of the operator, if the operator is idle for the specified duration

mosip.registration.idle_time=900

Time in Seconds to display the warning message pop-up to the operator, if the operator is idle for the specified duration

mosip.registration.refreshed_login_time=600

Maximum no. of days for approved packet pending to be synced to a server beyond which Registration Client is frozen for registration

mosip.registration.last_export_registration_config_time=100

Maximum no. of packets pending EOD approval beyond which Registration Client is frozen for registration

mosip.registration.reg_pak_max_cnt_apprv_limit=100

Enable supervisor authentication feature. If y, supervisor approval will be enabled, else, will be disabled

mosip.registration.supervisor_approval_config_flag=Y

No. of days beyond audit creation date to delete audits

mosip.registration.audit_log_deletion_configured_days=10

No. of days beyond the registration date to delete synced and uploaded registration packet:

mosip.registration.reg_deletion_configured_days=1

No. of days beyond the appointment date to delete unconsumed pre-registration application data

mosip.registration.pre_reg_deletion_configured_days=1

The maximum duration to which registration is permitted without sync of master data

mosip.registration.sync_transaction_no_of_days_limit=5

Allowed a number of invalid login attempts:

mosip.registration.invalid_login_count=50

Used to configure the time (in minutes) for locking the account after crossing the configured invalid login count

mosip.registration.invalid_login_time=2

Configuration is used to check if any sync job is missed/failed beyond expected days, this configuration is checked every time the operator clicks on any registration process. We follow the below convention to create this config key.

mosip.registration.job api name as in sync_job_def table.frequency=value in days

#Maximum no. of days without running the Master Sync Job beyond which Registration Client is frozen for registration

mosip.registration.masterSyncJob.frequency=190

#Maximum no. of days without running the Pre-Registration Sync Job beyond which Registration Client is frozen for registration

mosip.registration.preRegistrationDataSyncJob.frequency=190

#Maximum no. of days without running the Packet Sync Status Job beyond which Registration Client is frozen for registration

mosip.registration.packetSyncStatusJob.frequency=190

#Maximum no. of days without running the Key Policy Sync Job beyond which Registration Client is frozen for registration

mosip.registration.keyPolicySyncJob.frequency=190

#Maximum no. of days without running the Registration Deletion Job beyond which Registration Client is frozen for registration

mosip.registration.registrationDeletionJob.frequency=190

#Maximum no. of days without running the Configuration Sync Job beyond which Registration Client is frozen for registration

mosip.registration.synchConfigDataJob.frequency=190

#Maximum no. of days without running the Audit Logs Deletion Job beyond which Registration Client is frozen for registration

mosip.registration.deleteAuditLogsJob.frequency=190

Date formats

Date format to be displayed on acknowledgment slip, default value - dd/MM/yyyy hh:mm a

  mosip.registration.application_date_format

Date format to be displayed on Registration Client dashboard, default format - dd MMM hh:mm a

 mosip.registration.dashboard_date_format

Overview

Registration Client is a thick Java-based client where the resident's demographic and biometric details are captured along with the supporting documents in online or offline mode.

The documentation here will guide you through the prerequisites required for the developer' setup.

Software setup

Below are a list of tools required in Registration Client:

1. JDK 11

2. Any IDE (like Eclipse, IntelliJ IDEA)

3. Apache Maven (zip folder)

4. Git

Follow the steps below to set up Registration Client on your local system:

Code setup

For the code setup, clone the Registration Client repository and follow the guidelines mentioned in the Code Contributions.

Importing and building of a project

1. Open the project folder where pom.xml is present.

2. Open command prompt from the same folder.

3. Run the command mvn clean install -Dgpg.skip=true -DskipTests=true to build the project and wait for the build to complete successfully.

4. After building of a project, open Eclipse and select Import Projects → Maven → Existing Maven Projects → Next → Browse to project directory → Finish.

5. After successful importing of project, update the project by right-click on Project → Maven → Update Project.

Environment setup

1. For the environment setup, you need an external dependency that is available here with different versions. (E.g.: You can download mock-sdk.jar and add to registration-services project Libraries → Classpath → Add External JARs → Select Downloaded JAR → Add → Apply and Close).

2. Registration Client UI is developed using JavaFX and the UI pages are fxml files which can be opened using a tool called Scene Builder. The JavaFX integration with the Eclipse IDE is provided with the e(fx)clipse tool. Go to Help → Install New Software → Work with → Add. Give Name and Location as mentioned in below image.

Once the software is installed, you will be prompted to restart your IDE.

3. Download openjfx-11.0.2_windows-x64_bin-sdk.zip from here, unzip and place it in your local file system. This folder contains list of javafx related jars that are necessary for running Registration Client UI.

4. We can change the application environment in the file registration-services\src\main\resources\props\mosip-application.properties by modifying the property mosip.hostname

Below are the configurations to be done in Eclipse:

1. Open Eclipse and run the project for one time as Java application, so that it creates a Java application which you can see in debug configurations.

2. Open the arguments and pass this --module-path C:\Users\<USER_NAME>\Downloads\openjfx-11.0.2_windows-x64_bin-sdk\javafx-sdk-11.0.2\lib --add-modules=javafx.controls,javafx.fxml,javafx.base,javafx.web,javafx.swing,javafx.graphics --add-exports javafx.graphics/com.sun.javafx.application=ALL-UNNAMED in VM arguments.

3. Click Apply and then debug it (starts running). You can see a popup which shows informative messages of what is happening in background while Registration Client UI is loading and the application will be launched.

Running the Registration Client Downloader Docker image

• Dockerfile is available under registration-client repository.

• The concept here is to run nginx in the docker container from which registration-client.zip is hosted and also registration-client on the field will connect to this nginx to check for new updates or changes.

Note: We refer this nginx server as registration-client download and upgrade server.

While running the registration-client docker container we need to pass below environment variables:

Required

client_version_env : pom version of the registration client build

client_upgrade_server_env : public URL of this nginx server

reg_client_sdk_url_env : URL to download sdk zip. Make sure to have SDK jar and its dependent jars in the zip.

artifactory_url_env : artifactory URL to download below mentioned runtime dependencies

“${artifactory_url}/artifactory/libs-release-local/icu4j/icu4j.jar”

“${artifactory_url}/artifactory/libs-release-local/icu4j/kernel-transliteration-icu4j.jar”

“${artifactory_url}/artifactory/libs-release-local/clamav/clamav.jar”

“${artifactory_url}/artifactory/libs-release-local/clamav/kernel-virusscanner-clamav.jar”

keystore_secret_env : password of the keystore.p12 file

host_name_env : syncdata-service public domain name

signer_timestamp_url_env : URL of timestamp server to timestamp registration-client jar files.

Need to mount a volume to “/home/mosip/build_files” with below files

• logback.xml

• Client.crt : Signer certificate to be added in the registration-client build for jar sign verification.

• keystore.p12 : Store private key used to sign the registation-client and registration-services jar files with “CodeSigning” alias.

• maven.metadata.xml : Holds the current version of registration-client hosted in the upgrade server.

Optional

reg_client_custom_impls_url_env : URL to download scanner custom implementation jars(runtime dependency).

Finally, you can download the registration client zip from below URL. {registratiionclient download server domain name/ip}/registration-client/{client_version}/reg-client.zip}

References

Run (https://github.com/mosip/mosip-infra/blob/develop/deployment/v3/mosip/regclient/create-signing-certs.sh) to generate Client.crt and keystore.p12.

To get the content of maven-metadata.xml and logback.xml check (https://github.com/mosip/mosip-helm/blob/develop/charts/regclient/templates/configmap.yaml)

Overview

This guide helps the operator in setting up the registration client.

Know your machine TPM keys

A Trusted Platform Module (TPM) is a specialized chip on a local machines that stores RSA encryption keys specific to the host system for hardware authentication.The pair is maintained inside the chip and cannot be accessed by software. By leveraging this security feature every individual machine would be uniquely registered and identified by the MOSIP server component with it's TPM public key.

To extract the TPM public key, use the TPM key extractor utility.

Prerequisites

To onboard the machine and the operator, the Admin needs to:

1. Create and activate the registration client machine using Admin portal.

2. Create a user/operator account in Keycloak

3. Assign the operator a role of either the Supervisor or Officer using the Admin portal.

4. Finally, perform the User Zone mapping and User Center mapping in the Admin portal.

System prerequisites:

• CPU - Dual Core Processor - 2GHZ

• RAM - 16 GB

• Local Storage Disk Space - 500 GB

• USB 2.0 ports or equivalent hub.

• Physical machine with TPM 2.0 facility.

• Windows OS [10 v]

Registration client setup

To setup the registration client:

1. Download the reg-client.zip from the hosted server.

2. Unzip the client. You can see the directory structure below.

3. Click run.bat to launch registration client.

Launching the registration client

The client always launches with the pre-loader screen which displays the information about the network status, build status verification, online status, etc.

1. First time launch

• After the pre-loader, the login screen is displayed.

• Any valid operator credentials can be provided to authenticate and start the initial sync.

• On successful intial sync, the operator will be prompted to restart the application.

• After the first launch, the operator can notice .mosipkeys and db folders created under the registration client setup folder.

Note: Deletion of either the .mopsipkeys or the db folder makes the application get into an invalid state and hence will fail to launch. To be able to launch the client again, the operator should make sure that both the folders are removed and then re-launch the client.

1. On the next launch after the initial sync,

• The registration client login page provides the operator an option to select the language for viewing the registration client UI.

• After successful login, the operator either lands into the operator onboard page or the home page.

For more details on operator onboarding, refer to Operator onboarding guide.

For more details on Home page, refer to Registration client home page.

Modes of operation

• Offline- Operator can use the registration client in offline mode to only do the registrations and EOD process. During offline mode, the operator authentication will be based on locally saved password hash. An operator can work in offline mode only if they have logged into to the registration client being online atleast once.

• Online- Machine must be online for the registration client first launch. For any server-client sync or vice-versa, the registration client must be online. In the online mode, the client reaches out to the server for password authentication.

Note: On successful onboard of the operator, biometric templates of the operator are stored locally. Biometric authentication does not reach out to the server everytime, instead it is validated based on the locally stored templates on the registration client machine.

Setting up MOCK SBI (MDS)

In the development environment, Registration client can be tested using mock SBI. Find the instructions to build and run the mock SBI, click here.

Troubleshooting

1. Incorrect username/password

-> Cross-check the machine keys mapping in server ('Machine not found' error in logs)

-> Cross-check machine status

-> 'Invalid Request' error in log - Check your machine time, it shouldnt be less or greater than local timezone datetime (usually accepted lag is +5/-5 minutes)

-> check logs/registration.log for more details

2. Configuration / masterdata Sync failed

-> check if kernel-syncdata-service is up.

This guide contains all the details you may want to know about the operator onboarding.

Creating the first operator in MOSIP

To generate the first operator in MOSIP eco-system, refer to the steps below.

The Admin needs to:

1. Create the role Default in KeyCloak with all the other roles.

2. Create the operator' user account in KeyCloak.

3. Assign the operator user account with the Default role.

4. Perform Zone and Center mapping for the operator using the Admin Portal.

5. Onboard the operator machine using the Admin Portal. Machine' details can be extracted using the TPM utility

The operator will need to:

1. Download the latest registration client and login with the credentials set in KeyCloak. The operator will automatically skip Operator/Supervisor onboarding and reaches the home page of the registration client.

2. Register themselves in MOSIP and get a RID and UIN.

Once the operator is registered:

• The Admin changes the role of the operator to either REGISTRATION_OFFICER or REGISTRATION_SUPERVISOR.

• Deletes the role Default from KeyCloak so that no other user has the role Default.

• This operator can now register and onboard other Supervisors and Officers.

On-boarding an operator

• Admin needs to map the operator' UIN in KeyCloak under Attributes with attribute name as individualId.

• Admin needs to remove the "Default" role mapping for the operator' user account if it exists.

• The operator needs to login (password based) to the Registration Client using Keycloak credentials.

• The operator needs to ensure that the Registration Client machine is online.

• The operator will land into the below page and needs to click on Get Onboarded
• The operator needs to provide their biometrics and click Save.

• All the biometric modalities displayed in the Operator biometrics page must be captured before clicking on Save.

• Captured biometrics quality must be greater than or equal to the threshold displayed in the UI.

  Note- The threshold values are configurable and can be set as per the ID issuer.
• After successful onboarding, the operator is automatically re-directed to the registration client home page.

Note:

• After successful onboarding of the operator, the templates are extracted from the captured biometrics using configured Bio-SDK. The extracted templates are stored in Derby DB. This can be used later for operator' biometric-authentication and also for local de-duplication checks during registration.

• After the first login and successful on-boarding, the registration client would mandate the operator to login with the configured authentication mode decided by the administrator.

• Any number of operators can login to a registration client machine but they need to be mapped to the same center where the machine is onboarded.

• Login operator' user ID is case-insensitive.

Summarizing, on-boarding of an operator is successful only if,

• The operator is active and not block listed.

• The operator and the machine belongs to the same center.

• The operator's User ID is mapped to their UIN.

• The operator's biometric authentication is successful during on-boarding.

• The system is online during on-boarding.

Operator onboarding workflow

1. Operator logs into Registration Client for the first time and is redirected to Onboarding screen. Here, they need to capture all their biometrics and then click SAVE button.

2. Request from Registration Client goes to Registration Processor for operator authentication.

3. Registration Processor passes this request to ID Authentication where it checks whether the user is mapped to a valid UIN and then matches the biometrics sent in the request with the biometrics of the mapped UIN.

4. Success/Failure response sent back to Registration Processor based on the authentication result.

5. Registration Processor sends back this response to Registration Client.

6. After successful authentication, the captured biometrics are sent to configured Bio-SDK to extract templates.

7. Extracted templates are sent back from Bio-SDK.

8. The extracted templates are stored in local Derby DB.

9. These templates stored in local DB can be used later for operator's biometric-authentication and also for local de-duplication checks during registration.

Modes of login

• MOSIP supports single factor and multi factor login including password, iris, fingerprint, and face authentication for registration client. An administrative configuration setting determines the mode of authentication login.

• The registration client can authenticate an operator in offline mode using the locally stored biometrics templates (face/finger/iris) and password hash.

Temporarily lock the operator

The registration client temporarily locks the operator’s account in case they provides an invalid password/fingerprint/iris/face for X times continuously to login (X is configurable). The temporary account lock lasts for X minutes (X is again configurable).

Logout

An Operator can logout of the registration client by:

• Clicking on the Logout button,

• Closing the registration client,

• Being in-active on the registration client for configured amount of time after which they are automatically logged out.

• Upon logout, any unsaved data will be lost.

• Data will not be automatically saved in the database and will not be retained in memory though transaction details which is used for auditing will be captured and stored (except for PII data).

Note- Registration client provides an alerts to the operator ‘X’ minutes before reaching the auto logout time limit. Registration client displays a countdown timer in the alert. The operator can choose to dismiss the alert and continue working. This will also reset the timer to zero.

Overview

This guide describes the various functions provided in the Home page of the reference UI implementation of the registration client.

Menu bar

The Registration Client menu bar displays the following:

• MOSIP logo

• Home button

• Logged in username

• Center name

• Machine name

• Server connection status symbol (shows if the client is online or offline)

• Settings icon

• Breadcrumbs (User Guide/Reset Password/Logout)

Operational tasks

Synchronize Data

Synchronize data is the data required to make the Registration Client(RC) functional. Full sync is performed initially during the launch of the RC for the first time. Post this, the RC syncs only the changes from sever and this is called as the delta sync. Synchronize data is automated and can be triggered manually. This happens automatically while launching the RC and is also manually initiated by the operator.

1. Configuration sync: Sync of properties which drives in deciding the RC UI functionality. For example: Invalid login attempts, idle timeout, thresholds, etc.

2. Masterdata sync : As a part of this sync, supporting information like Dynamic fields data, templates, locations, screen authorization, blocklisted words, etc. are pulled in.

3. UserDetails sync: userID, along with their status is synced. Only the user details belonging to machine mapped center will be synced.

4. Certificate sync: Certificates used to validate the server signatures, device CA certificates, public key (specific to a center and machine, also called as policy key) used to encrypt the registration packet will be synced.

5. Packet sync:

   • All the approved/rejected Registration IDs(RIDs) will be synced to the server.

   • All the synced RID packets will be uploaded to the server.

   • All the uploaded packet status will be synced from server.

Download Pre-Registration Data

An operator can download the pre-registration data of a machine mapped center while being online and store it locally in the registration machine for offline use. Now, when the system is offline and the pre-registration data is already downloaded, the operator can enter the pre-registration ID to auto-populate the registration form. Provided the machine is online, any pre-registration application can be downloaded irrespective of the center booked by the resident.

This pre-registration data is downloaded from pre-registration API as an encrypted packet and stored in the local storage.There is a batch job running in background for deleting the pre-registration packets after configurable number of days.

Note- Date Range of pre-registration data to be downloaded and storage location of pre-registration data in the registration machine is configurable. Also, this is synced as a part of configuration sync.

Update Operator Biometrics

Using this option, the operators can onboard themselves anytime.

For more details, refer Operator Onboarding Guide.

Application upload

• Application upload refers to upload of supervisor reviewed registration packets (approved and rejected). From this page, the operator can export the packets to any location on their machine on clicking Save to Device button.

• Upload of registration packet from this page internally performs two operations in sequence:

  • Sync registration metadata to server

  • On successful sync of metadata, actual registration packets are uploaded to the server.

Client Status: This column displays the status of a registration packet based on the above mentioned operation.

1. APPROVED

2. REJECTED

3. SYNCED

4. EXPORTED

Server Status:

On success,

1. PUSHED

2. PROCESSED

3. ACCEPTED

On failure,

1. REREGISTER

2. REJECTED

3. RESEND

Registration Type

This column displays the type of registration packet (New packet, Lost packet, Update packet, Correction packet)

Center Remap Sync

• When a machine is re-mapped from one center to another center, all the pending activities in the machine related to the former center needs to be completed.

• On successful completion of pending tasks, the former center's details will be deleted from the local Derby DB and a full sync will be initiated to pull in the new center details.

What are the pending tasks related to a center?

• Packet Approvals/rejections

• Packet upload

• Server confirmation on receiving a packet

• Deletion of packets after receiving a confirmation

• Deletion of pre-registration packets

• Deletion of center specific data like the public/policy key

Note- After completing the above tasks, a restart will be prompted to initiate the full sync with new center details.

Check Updates

• Clicking on this button, triggers a check for any new client version availability in the upgrade server.

• The machine must be online to be able to check updates.

• If there is any new version available, a confirmation pop-up is displayed to the operator for starting the upgrade or a reminder is displayed.

Registration Tasks

The operator can initiate any task from amongst- New registrations, Update UIN, Lost UIN, Correction flow. To get started, the operator needs to select a language for data entry. The number of languages displayed in the UI is configurable and depends on the country.

New registration

An operator can initiate the process of registering a new applicant in the MOSIP ecosystem by filling the new registration form with the resident.

Below are few of the processes that needs to be completed for a new registration.

1. Capture consent- For every registration, the registration client provides an option for the operator to mark an individual's consent for data storage and utilization.

2. Enter demographic data and upload documents If the resident has a pre-registration application ID, the operator can auto-populate the demographic data and the documents by entering the pre-registration ID. If the resident does not have a pre-registration ID, the operator can enter the resident’s demographic details (such as Name, Gender, DOB, Residential Address, etc.) and upload the documents (such as Proof of Address, Proof of Identity, Proof of Birth) based on the ID Schema defined by the country.

3. Capture biometrics of a resident The capture of biometrics is governed by the country, i.e. capture of each modality (fingerprint, iris or face) can be controlled by the country using the global configuration. When the operator clicks on the Capture button and tries to capture the biometrics of the resident, the device needs to make the capture when the quality of the biometrics is more than the threshold configured by the country. The device will try to capture the biometrics until the quality threshold has crossed or the device capture timeout has crossed which is also configurable.

After the timeout has occurred and the captured quality of biometrics is less than the threshold, registration client provides an option to re-try capture of biometrics but for a particular number of times which is also configurable. If the resident has a biometric exception (resident is missing a finger/iris or quality of finger/iris is very poor) the operator can mark that particular biometrics as exception but the operator has to capture the resident's exception photo.

What is the difference between an adult' and an infant' biometric capture?

• For an adult, all the configured biometrics can be captured.

• For an infant, by default, only the face biometrics is allowed to be captured.

1. Concept of biometric exception

• Permanent or temporary missing / defective fingers or irises can be marked as exception during registration process.

• Marked exception finger / iris names are sent as part of rcapture request to SBI.

• A photo of resident is captured highlighting his/her biometric exceptions called as Proof of exception (POE).

• Biometric exception photo is captured by the biometric face camera device.

• Until 1.2.0, POE was collected only as documentType field. From 1.2.0.1, Captured biometric exception photo is stored in the biometric data file (CBEFF xml file).

Update UIN

When a resident visits the registration center to update their demographic or biometric details, the operator captures the updated data as provided by the resident in the registration client. The resident needs to give their UIN and also select the field(s) that needs an update. The image below gives an idea of the update UIN process Flow in the registration client.

Lost UIN

There are two situations where a Lost UIN flow is used. I am listing here the situations.

• The registrant has lost their Identity details.

• The registrant never received his identity due to a wrong address/email/phone

The registrant visits the registration centre to retrieve the same. The operator then captures the biometrics and the demographic details of the individual and processes a request to retrieve the lost UIN. As biometrics play a crucial role in identifying a person's identity, it is mandated to provide the biometrics as a part of the Lost UIN flow. Other details like demographic data, and uploading documents are optional.

• As a part of Lost UIN flow, the contact details like the phone number/ e-mail address of the UIN holder can also be updated and stored in the ID Repository based on the value provided for the property uingenerator.lost.packet.allowed.update.fields which is specified in the Registration Processor properties.

• If the value already exists for the above mentioned property and once the lost UIN is found, details of the identity of the individual are sent to the newly provided phone number/ e-mail address.

Example: uingenerator.lost.packet.allowed.update.fields= phone,email

Correction process

For a resident whose UIN is yet not generated, they can get a request intimation to re-provide their details with a RequestId. The same AddtionalInfo RequestId must be provided to the operator during the correction flow.

Note- The above mentioned Registration tasks are completely configurable through UI Specs<>

Preview and Packet authentication

• The operator can preview the data filled and navigate back to the respective tabs in case of corrections.

• Once the resident and the operator are satisfied with the data being captured, the operator can proceed to the Authenticate tab and provide his valid credentials to mark the complete of the registration task.

Acknowledgement receipt and printing

Once the registration process (new registration, UIN update or lost UIN, correction) is completed, the registration client generates an acknowledgement receipt. This receipt contains a QR code of the Registration application ID, captured demographic data in the selected language, photograph of the resident and ranking of each finger from 1 to 10 (1 being the finger with the best quality). This receipt is print friendly and can be used for printing using any printer.

The image below is that of a sample acknowledgement receipt.

End-of-day processes

Pending Approval

The Supervisor has the exclusive authority to approve/reject packets. The supervisor is supposed to manually re-verify the registrations before uploading them to the server. This page enables them to perform this activity.

Steps to approve/reject packets

1. Click on any of the registrations listed in the left pane. The registration details are displayed on the right pane.

2. Supervisor needs to manually verify all the details in the right pane.

3. Supervisor can click Approve/Reject button based on their verification.

4. To mark the completion of this approval process, they need to click on Authenticate and provide their credentials.

5. On successful authentication, approved/rejected packets will be removed from here and be seen on the Application Upload page.

Re-registrations

All the registrations which are being marked with the RE-REGISTER status is listed here.

Dashboard

On clicking Dashboard, the Registration client dashboard HTML template is rendered. Default dashboard displays information about the operator, Packets and the Sync Activities.

News and updates

This section has been reserved for the countries to be able to display their live news and updates. This can be implemented as per a country's requirements.

Consent

During the training of the Operators, It must be ensured that consent is obtained directly from the resident whose personal information is being collected and processed. There is no technical way to handle this scenario, so the operator training must include this activity as a manual process and emphasize upon strictly following the same.

Overview

The primary objective of the tablet version is to facilitate the registration process for residents, especially those who are unable to physically visit registration centers. It also serves remote locations where setting up registration centers is not feasible. To address this challenge, the Android Registration Client was created, enabling operators and supervisors to easily reach remote areas and maximize resident registrations across the country.

Features

The first developer release of the Android Registration Client offers the following key features:

1. Operator/ Supervisor Login (offline and online): Operators can securely login using their credentials, whether in offline or online mode, to carry out various registration transactions. To enable offline login, the operator must have previously logged in and synchronized their data over a network.

2. Multi-language Support: The Android Registration Client supports multiple languages for content display and data entry.

• Display Language: Display Language refers to the language used for rendering UI elements such as labels and headings. With the Android Registration Client, Operators have the option to choose their preferred language for UI display. This language selection can be made on the login screen. Currently, the supported display languages include Arabic, French, and English.

• New languages can be added by following the below steps:

• Additional languages can be configured by adding localization files in lib/l10n folder present in the root project directory("android_registration_client").

• The languages that are rendered on the UI will be based on the country configuration (after master data sync). The default display language is English. Other languages will be available in the UI after the master data sync.

• Data Entry Language: The Data Entry Language refers to the specific language utilized by the Operator while gathering data, which is then stored on the server in that selected language. During the registration process, the Operator can choose the language preference for the data collected, allowing applicants to provide information in their desired language. This language selection option becomes available upon initiating a new registration. The responsibility for managing the data entry language lies within the UI Spec, and any modifications or changes can be made through that specification.

1. Auto-Sync/ manual sync: On launching the Android Registration Client and logging in for the first time, the system automatically syncs the following data:

• Configuration sync: Sync of properties which drives in deciding the ARC UI functionality. For example: Invalid login attempts, idle timeout, thresholds, etc.

• Masterdata sync: As a part of this sync, supporting information like Dynamic field data, templates, locations, screen authorization, blocklisted words, etc. are pulled in.

• UserDetails sync: userID, along with their status is synced. Only the user details belonging to machine mapped center will be synced.

• Certificate sync: Certificates used to validate the server signatures, device CA certificates, and public key (specific to a center and machine, also called policy key) used to encrypt the registration packet will be synced.

1. • Consent: Before the registration process, applicants must provide consent to the terms and conditions presented on the consent screen. This explicitly asks the applicant to grant permission for storing and using their Personally Identifiable Information (PII).

   • Demographic Details: Once the consent is obtained, the Operator will enter the demographic data of the applicant in the language preferred by the applicant. This includes details such as their name, gender, date of birth, and residential address.

   • Documents Upload: Following the completion of the demographic details, the Operator can select the document type, input the reference, and upload the supporting documents provided by the applicant. Supporting documents may include Proof of Address, Proof of Identity, and Proof of Birth, based on the country-specific requirements.

   • Biometrics: After the documents have been uploaded, the Operator will proceed to capture the applicant's biometrics. The biometrics captured are as follows:

The acquisition of biometric data is regulated by the country. The country has control over the capture of each type of biometric (fingerprint, iris, or face) through the global configuration. When the Operator selects the Capture button, the biometric SBI application is accessed to capture the biometrics.

Once the biometrics are obtained, the data and control are returned to the Android Registration Client. To obtain the resident's biometrics, the quality of the captured image must exceed the threshold specified by the country. The biometrics can be captured a set number of times if necessary to meet the quality threshold. In situations where none of the captured images meet the threshold, the image with the highest quality score will be saved.

If the resident has a biometric exception (such as a missing finger/eye or very poor finger/iris quality), the Operator can designate that particular biometric as an exception. However, the Operator must still capture the resident's exception photo.

• Preview section: The Operator can review the data entered by the applicant, including demographic information, uploaded documents, and captured biometrics. This preview allows the Operator to ensure the accuracy of the entered data. If any mistakes are found, the Operator can easily go back to the corresponding section and make the necessary corrections. If the data is correct, the Operator can proceed to the next step, which is to authenticate themselves.

• Operator authentication: Once both the Operator and applicant have confirmed that the data is accurately filled, the Operator is required to authenticate themselves using their credentials. After a successful authentication, the data packets are created and only then the sync and upload operations can be performed.

• Packet sync: After the applicant's registration form has been completed and the Operator has authenticated themselves, a packet sync must be performed. This can be done either manually or as a background job(auto sync and upload of packets). Packet sync ensures that the packet is prepared for uploading and the status of the uploaded packet is synchronized with the server.

• Packet Upload: Once the packet sync is completed, the system will proceed to upload the packet to the server when an internet connection is available. If there is no network access, the system will attempt to upload the packet as soon as connectivity is established.

• Acknowledgment section: Following the completion of the new registration process, an acknowledgment receipt is generated. This receipt includes the AID(Application ID), captured demographic data in the selected language, a photograph of the resident, and a ranking of each finger from 1 to 10, with 1 representing the finger with the best quality. The receipt is designed to be easily printed.

exceptionalBiometrics exceptions: If the resident has a biometric exception (such as a missing finger/eye or very poor finger/iris quality), the Operator can designate that particular biometric as an exception. However, the Operator must still capture the resident's exception photo.

• Preview section: The Operator can review the data entered by the applicant, including demographic information, uploaded documents, and captured biometrics. This preview allows the Operator to ensure the accuracy of the entered data. If any mistakes are found, the Operator can easily go back to the corresponding section and make the necessary corrections. If the data is correct, the Operator can proceed to the next step, which is to authenticate themselves.

• Operator authentication: Once both the Operator and applicant have confirmed that the data is accurately filled, the Operator is required to authenticate themselves using their credentials. After a successful authentication, the data packets are created and only then the sync and upload operations can be performed.

• Packet sync: After the applicant's registration form has been completed and the Operator has authenticated themselves, a packet sync must be performed. This can be done either manually or as a background job(auto sync and upload of packets). Packet sync ensures that the packet is prepared for uploading and the status of the uploaded packet is synchronized with the server.

• Packet Upload: Once the packet sync is completed, the system will proceed to upload the packet to the server when an internet connection is available. If there is no network access, the system will attempt to upload the packet as soon as connectivity is established.

• Acknowledgment section: Following the completion of the new registration process, an acknowledgment receipt is generated. This receipt includes the AID(Application ID), captured demographic data in the selected language, a photograph of the resident, and a ranking of each finger from 1 to 10, with 1 representing the finger with the best quality. The receipt is designed to be easily printed.

1. Operator onboarding: To log in to the Android Registration Client, the operator must complete the onboarding process. This functionality is available only during the first online login. The operator must onboard by capturing their fingerprints, thumbprints, iris, and face. Once these are captured, the operator can start registering residents and using other services.

2. Dashboard: The Operator can access the dashboard where he can view the following:

   1. Packets created: This will show the total number of packets created from the time the Android Registration Client was installed.

   2. Packets Synced: This will show the total number of packets synced from the time the Android Registration Client was installed.

   3. Packets Uploaded: This will show the total number of packets uploaded from the time the Android Registration Client was installed.

   4. User details:

      1. User ID: This will show the list of User IDs of the Users mapped to the device.

      2. Username: This will show the list of usernames of the Users mapped to the device.

      3. Status: This will show the status of Users mapped to the device. This can take values such as onboarded, active, inactive, etc.

3. Supervisor's Approval: Once the packet is created by the Operator, as an additional check, the Supervisor will have to go through each application to make sure the details filled are coherent. At this stage, the Supervisor can either Approve the Application or he can Reject it. If the Supervisor decides to reject it, they also will have to mandatorily mention the reason for rejection. Once the Application has been Approved or Rejected, the Supervisor will have to authenticate himself by entering his Username and Password. Once they have successfully authenticated, the Application will be removed from the “Supervisor’s Approval” section and will be moved to the “Manage Application” Section.

1. Manual Application upload/export: Once the Application is either Approved or Rejected by the Supervisor, those packets can be uploaded to the server from the “Manage Application” section. If there is internet connectivity, the packet will be synced and uploaded to the server but in case of lack of internet connectivity, the User can also export the packet to their local device storage.

2. Update UIN: In a scenario where the Resident wants to update their data, they can do so by letting the Operator know their UIN and the data that needs to be updated. Residents can update their demographic details, documents, and biometrics using this feature.

3. Logout: Using this feature, once the user is done with their registration and other activities, they can logout. If no background tasks are running, the user will be immediately logged out. If there are tasks (like sync) running in the background, the user will be notified about the same. From here if the User wants to cancel the logout, the background activities will keep running whereas if the user chooses to logout, they will be logged out and the background activities will be terminated.

4. Update operator's biometrics: In a scenario where the operator wants to update his biometric section from operational tasks to update.

5. Handles Feature: The Handles Feature is designed to streamline citizen registration and authentication. During registration, specific attributes such as email, phone number, or national ID—can be designated as a handle. This handle serves as a unique identifier that can later be used for authentication for various services. Handles can also be used to update data in case of data discrepancies. By allowing flexible and secure identification, the feature enhances the accuracy and integrity of citizen records while simplifying user interactions with government systems.

Configuration Guide

UI Specifications

Compatibility

The Android Registration Client is compatible with the following MOSIP platform versions:

1. 1.1.5.x

2. LTS 1.2.0 and above

The documentation here will guide you through the pre-requisites and the other necessary details required for Android Registration Client developer setup.

The android-registration-client repository contains the Android Registration Client software for MOSIP. The feature-flutter branch focuses on integrating Flutter into the client.

Setup

To set up the Android Registration Client with Flutter and Android Studio, follow the steps below:

Prerequisites

Step 1: Clone the Repository

The develop branch of android-reg-client is currently being actively developed. If you wish to access this branch, you can clone the repository by executing the following command in your terminal. Alternatively, you can download one of the releases available in the repository's release section.

Active Branches:

Step 2: Set up Flutter in Android Studio

1. To begin, launch Android Studio.

2. Next, select Open an existing Android Studio project and navigate to the cloned repository.

3. Open the android-registration-client directory as a project in Android Studio.

4. In order to integrate Flutter with Android Studio, install the Flutter plugin by accessing File > Settings > Plugins and searching for Flutter. Proceed to click on Install to install the plugin.

5. To ensure proper functionality, configure the Flutter SDK path by navigating to File > Settings > Languages & Frameworks > Flutter and specifying the Flutter SDK path as the location where you have installed Flutter.

6. Finally, save the changes by clicking on the "Apply" button.

Customizing the Registration Client

• Styling of the application can be configured by modifying these files lib/utils/app_style.dart, lib/utils/app_config.dart

• Application language bundles can be added to this path lib/l10n After adding the bundle run the below command to generate Localization data (Required for the first time).

• The label and application logo can be changed here android/app/src/main/AndroidManifest.xml

Step 3: Build and Run the Application

• The pigeon.sh file consists of the necessary commands for downloading dependencies and generating Flutter - Android native communication code. Please execute the pigeon.sh file or execute the commands within the file separately.

• Ensure you have connected an Android device or initiated an Android emulator.

• Open the terminal within Android Studio or use an external terminal.

• Navigate to the android-registration-client directory.

• Run the following command to build and execute the application:

Step 4: Build, debug, and release APK

Execute the commands below to debug and release the APK

Set up Mock MDS for Biometric Scan

The Mock MDS tool can be utilized to simulate the functionalities of biometric devices. The Mock MDS application is compliant with CTK standards and can serve as a substitute for Android SBI modules during testing and validation.

1. Install the Mock MDS application.

2. Access the Settings menu.

3. Under Device Configuration, choose Registration from the dropdown menu.

4. In P12 Configuration:

   • Enter the necessary credentials for the Device Key and upload the Device P12 file.

   • Enter the required credentials for the FTM Key and upload the FTM P12 file.

   • Complete all fields in MOSIP IDA Configuration.

5. In Modality Configuration, specify the quality score for Face, Finger, and Iris scans(these values can also be adjusted during testing).

6. Click on the Save button.

7. Go back to the Home Page and select LOAD AND VALIDATE CERTIFICATES.

A toast message will be displayed indicating the success of the validation process.

To download the Mock SBI APK, click on camera-mds.zip.

Contributions

License

Support

Sources

Settings Schema

Default settings schema is configured as below:

Device settings

• All the connected devices are listed in this page.

• Option to scan for SBI for any specific port range is available in this page.

• If more than one device is idenitied, operator can choose amongst the listed devices to set the default device for the current login session.

• Access control on this page is controlled via the settings-schema.

Global configuration

• All the Registration Client related configuration key-value pairs are listed in this page.

• Operator can set the local preference on the server configraton value, applicable only for permitted configuration keys.

• Access control on this page is controlled via the settings-schema.

Scheduled Jobs

• All the available background jobs are listed here along with their cron expression.

• Every job's next and previous trigger time is listed along with the job name.

• Privileged operator can update the cron expression of any job.

• Synchornize Data in home page will trigger all of these listed jobs with just one click.

• If the operator needs to trigger specific job, the same can be handled in this page.

• Access control on this page is controlled via the settings-schema.

Following are the metrics that are collected in the client application using the micrometer library:

• JVM Memory Metrics

• JVM Thread Metrics

• JVM GC Metrics

• JVM Heap Pressure Metrics

• Processor Metrics

• Class Loader Metrics

• Disk Metrics

• Packet Metrics based on client and server status

All the metrics collected are appended to metrics.log file. Rolling policy of the metrics.log is defined in registration-services logback.xml.

Below are the challenges faced in exporting the collected metrics from client application to the server for further analysis:

1. Unreliable network conditions on field.

2. Metrics files are mostly large files, and cannot afford retries on failed attempts.

3. Required HTTP based metrics export.

To overcome the above challenges, Registration Client is built with tus-java-client (version: 0.4.3) . Tusd server URL and the upload chunk-size are made configurable in the client application.

mosip.registration.tus.server.url: This is the server URL config which specifies to which URL the metrics files are to be uploaded.

mosip.registration.tus.server.upload.chunksize: This config defines the chunk size, which means, how much size of the file is to be uploaded at once. By default, this is given as 1024, which means 1KB

Note:

• Tusd is a popular implementation of the Tus protocol that can be used as a standalone server. It is a part of the MOSIP deployment.

Each metric json logged into metrics.log file is tagged with machine name. Refer the below log lines with the machine names.

• A job is scheduled to upload collected metrics to server from the client application.

• Job runs with a fixed delay of 15 minutes.

• Resumable file URLs are stored under .metrics folder of registration client. Once the complete file is uploaded to server, the metrics file is deleted locally.

Registration Client UI Specifications

Overview

In the Registration Client, currently, Registration Tasks(process) forms are configurable using the UI specifications.

Each process has multiple screens and each screen is rendered with one or more fields.

Process/ Task spec JSON template

Screen spec JSON template

Field spec JSON template

Sample correction process SPEC: Biometric Correction

Enabling Handles Feature

Add the following in the properties section of IDSchema:

Example: