Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
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:
Unreliable network conditions on field.
Metrics files are mostly large files, and cannot afford retries on failed attempts.
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.
This guide helps the operator in setting up the registration client.
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.
To onboard the machine and the operator, the Admin needs to:
Create and activate the registration client machine using Admin portal.
Create a user/operator account in Keycloak
Assign the operator a role of either the Supervisor or Officer using the Admin portal.
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]
To setup the registration client:
Download the reg-client.zip from the hosted server.
Unzip the client. You can see the directory structure below.
Click run.bat to launch 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.
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.
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.
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.
In the development environment, Registration client can be tested using mock SBI. Find the instructions to build and run the mock SBI, click here.
1. Incorrect username/password
2. Configuration / masterdata Sync failed
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 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 .
To know more about the features present in the Registration Client, refer to .
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 .
The relationship of Registration Client with other services is explained here. NOTE: The numbers do not signify sequence of operations or control flow.
Registration Client connects to the Upgrade Server to check on upgrades and patch downloads.
All the masterdata and configurations are downloaded from SyncData-service.
Registration Client always connects to external biometric devices through SBI.
Registration Client scans the document proofs from any document scanner.
Acknowledgement receipt print request is raised to any connected printers.
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.
All the synced packets are uploaded to Packet Receiver service one by one.
The image below shows the setup of Registration Client Host machine.
Registration Client comprises of JavaFX UI, Registration-services libaries and any third party biometric-SDK.
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.
Registration Client connects to local Derby database. This is used to store all the data synced.
All the completed registration packets are stored under packetstore directory.
.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.
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.
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.
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 settings schema is configured as below:
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.
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.
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.
The registration UI forms are rendered using respective UI specification JSON. This is derived from the 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.
The Tus protocol is designed to enable resumable uploads of large files over HTTP, which can be useful for web applications that need to handle file uploads in unreliable network conditions or with large files that might take a long time to upload. For more information on TUS, refer .
Registration Client can be customized as per a country' requirements. For details related to Registration Client configurations, refer to .
Default UI Specifications loaded with Sandbox installation is available
To know more about the developer setup, read .
Clicking on in the home page opens a pop-up displaying configured Settings page as per the above sample settings schema.
The guide here lists down some of the important properties that may be customised 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 properites, then refer to the files listed below.
IMPORTANT : From the LTS version, All the properties are synced to the registration-client only from registration-default.properties file.
See Module Configuration for location of these files.
Registration Client reaches SBI on 127.0.0.1 within the below configured port range. As per SBI spec, allowed port range is from 4501 to 4600.
Timeouts in milliseconds set during any http calls to SBI.
Quality score threshold based on modality, Possible values 1 to 100
Retry attemps, Possible values 1 to 10
Quality score threshold based on modality for operator authentication, Possible values 1 to 100
Registration client 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 consturctor 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 shown below for MOCK SDK named as mockvendor:
On every successful biometric capture during registration, 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
Jobs like RID sync, packet upload, status sync is carried out in batches, number of registration records to be executed in a batch on every trigger.
Only the modalities configured will be collected during operator onboarding.
On every Pre-Registration application fetch in registration page, clears all the captured data prior to Pre-Registration application fetch. Set the field id's which should not be cleared after Pre-Registration application fetch. It is comma separated list of field ids as per UI-SPEC.
Storage Location to store the downloaded Pre-Registration Packets in local system
Pre-registration applications fetch time span, No. of days before appointment date.
Comma separated list of offline job ids. Offline jobs are the jobs which are not part of manual sync.
Comma separated list of untagged job ids. Untagged jobs, which will be not part of manual sync but only from scheduler.
Comma separated list of job ids which needs Registration Client restart.
Registration batch jobs scheduler.
Default CRON expression for scheduling the Jobs.
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 the this config mosip.registration.docscanner.id map supports regex.
Enable GPS device for capturing the geo-location. If y, GPS device will be enabled. If n, 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
To Reset Password in Registration Client
On clicking Reset password from the Actions menu present in the top right corner of Home page, it redirects the operator to the URL below which is configurable.
Enables / disables reviewer authentication on any biometric exception during registration
If enabled cross-checks of residents biometrics with locally stored operator biometric templates.
Minimum disk space required to create a packet - in MB
Registration packet store location
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 operator, if operator is idle for the specified duration
mosip.registration.idle_time=900
Time in Seconds to diplay the warning message pop-up to operator, if 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 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 disbaled
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 registration date to delete synced and uploaded registration packet
mosip.registration.reg_deletion_configured_days=1
No. of days beyond appointment date to delete unconsumed pre-registration application data
mosip.registration.pre_reg_deletion_configured_days=1
Maximum duration to which registration is permitted without sync of master data
mosip.registration.sync_transaction_no_of_days_limit=5
Allowed number of invalid login attempts
mosip.registration.invalid_login_count=50
Used to configure the time (in minutes) for locking account after crossing configured invalid login count
mosip.registration.invalid_login_time=2
Configuration used to check if any sync job is missed / failed beyond expected days, this configuration is checked everytime operator clicks on any registration process. We follow 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 format to be displayed on acknowledgement slip, default value - dd/MM/yyyy hh:mm a
Date format to be displayed on Registration Client dashboard, default format - dd MMM hh:mm a
This guide contains all the details you may want to know about the operator onboarding.
To generate the first operator in MOSIP eco-system, refer to the steps below.
The Admin needs to:
Create the role Default in KeyCloak with all the other roles.
Create the operator' user account in KeyCloak.
Assign the operator user account with the Default role.
Perform Zone and Center mapping for the operator using the Admin Portal.
Onboard the operator machine using the Admin Portal. Machine' details can be extracted using the TPM utility
The operator will need to:
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.
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.
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 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.
Request from Registration Client goes to Registration Processor for operator authentication.
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.
Success/Failure response sent back to Registration Processor based on the authentication result.
Registration Processor sends back this response to Registration Client.
After successful authentication, the captured biometrics are sent to configured Bio-SDK to extract templates.
Extracted templates are sent back from Bio-SDK.
The extracted templates are stored in local Derby DB.
These templates stored in local DB can be used later for operator's biometric-authentication and also for local de-duplication checks during registration.
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.
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).
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.
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.
Below are a list of tools required in Registration Client:
JDK 11
Any IDE (like Eclipse, IntelliJ IDEA)
Apache Maven (zip folder)
Git
Follow the steps below to set up Registration Client on your local system:
For the code setup, clone the Registration Client repository and follow the guidelines mentioned in the Code Contributions.
Open the project folder where pom.xml is present.
Open command prompt from the same folder.
Run the command mvn clean install -Dgpg.skip=true -DskipTests=true to build the project and wait for the build to complete successfully.
After building of a project, open Eclipse and select Import Projects → Maven → Existing Maven Projects → Next → Browse to project directory → Finish.
After successful importing of project, update the project by right-click on Project → Maven → Update Project.
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.
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)
This guide describes the various functions provided in the Home page of the reference UI implementation of the registration client.
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)
Breadcrumbs (User Guide/Reset Password/Logout)
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.
Configuration sync: Sync of properties which drives in deciding the RC UI functionality. For example: Invalid login attempts, idle timeout, thresholds, etc.
Masterdata sync : As a part of this sync, supporting information like Dynamic fields 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, public key (specific to a center and machine, also called as policy key) used to encrypt the registration packet will be synced.
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.
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.
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.
Using this option, the operators can onboard themselves anytime.
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.
APPROVED
REJECTED
SYNCED
EXPORTED
Server Status:
On success,
PUSHED
PROCESSED
ACCEPTED
On failure,
REREGISTER
REJECTED
RESEND
This column displays the type of registration packet (New packet, Lost packet, Update packet, Correction packet)
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.
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.
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.
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.
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.
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.
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.
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).
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.
The UIN update feature is configurable by a country. The Admin can turn ON or OFF, the UIN update feature using the configuration.
There might be a situation when a resident might have lost his UIN and visits the registration center for retrieving 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 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, 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.update.information) 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 corresponding to the property value can be fetched from Packet manager and updated in ID Repository.
Example: uingenerator.lost.packet.update.information= phone,email
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<>
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.
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.
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
Click on any of the registrations listed in the left pane. The registration details are displayed on the right pane.
Supervisor needs to manually verify all the details in the right pane.
Supervisor can click Approve/Reject button based on their verification.
To mark the completion of this approval process, they need to click on Authenticate and provide their credentials.
On successful authentication, approved/rejected packets will be removed from here and be seen on the Application Upload page.
All the registrations which are being marked with the RE-REGISTER status is listed here.
On clicking Dashboard, the Registration client dashboard HTML template is rendered. Default dashboard displays information about the operator, Packets and the Sync Activities.
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.
For more details, refer .
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 defined by the country.
