1 of 16

Additional Information

Introduction

Modular Open Source Identity Platform (MOSIP) integrates a suite of Mock Services designed to emulate key functionalities of MOSIP services within the framework. In the development, testing, and demonstration phases, Mock Services will make available a controlled environment to evaluate MOSIP features.

This document details each of the mock services and explains its significance within the MOSIP architecture.

Below are the current set of Mock Services available in MOSIP, the services are subject to modifications, as may be planned, in future releases. Please refer to the latest available version of the document.

Mock MDS (MOSIP Device Services)

Simulates device services for testing, authentication and delete registration functionalities.
Allows developers to interact with a device-service environment without a physical device.

Mock MV (Manual Verification)

Reproduces the manual verification process for testing and validation purposes.
Enables the testing of manual verification workflows without human intervention.

Mock ABIS (Automated Biometric Identification System)

Simulates the functionality of the Automated Biometric Identification System (ABIS).
Facilitates testing of biometric matching, search, and integration with ABIS without accessing production data.
Maintains resident biometric uniqueness through de-duplication.
Interfaces with MOSIP via message queues in JSON format.
Supports 1:N de-duplication and adheres to ABIS API Specifications.

Mock SDK (Software Development Kit)

Replicates MOSIP's Biometric Software Development Kit (SDK) for testing and debugging purposes.
Allows developers to integrate biometric functionalities into applications without connecting to physical device.
Used for 1:N match, quality, extraction, etc.
Simulation is available as Mock BioSDK, installed in the MOSIP sandbox.
Exposes REST APIs for 1:1 match and quality check at the MOSIP backend.

Mock SMTP (Simple Mail Transfer Protocol)

Handling Duplicate Entries

This document addresses how an error in Database upgrade script can be managed effectively.

Issue

If the below error has been encountered while attempting to execute the upgrade script, this can be resolved by following the steps mentioned in this document.

Error message

psql:sql/1.1.5.5_to_1.2.0.1-B1_upgrade.sql:13: ERROR: could not create unique index "cert_thumbprint_unique" DETAIL: Key (cert_thumbprint, partner_domain)=(231bd472ab24ef60ec6*******2cace89c34, AUTH) is duplicated. psql:sql/1.1.5.5_to_1.2.0.1-B1_upgrade.sql:13: STATEMENT: ALTER TABLE keymgr.ca_cert_store ADD CONSTRAINT cert_thumbprint_unique UNIQUE (cert_thumbprint,partner_domain);

The error message states that a unique index, named cert_thumbprint_unique, cannot be created due to a duplicate entry. Specifically, the values for the cert_thumbprint and partner_domain columns, which are (231bd472ab24ef60ec6*******2cace89c34, AUTH), already exist in the database. This duplicate entry violates the unique constraint defined for the ca_cert_store table in the mosip_keymanager database.

To address and successfully execute the DB upgrade script, the following steps can be taken:

Identify the duplicate entries in the mosip_keymanager table.

To accomplish this, use the provided SQL query:

SELECT * 
FROM keymgr.ca_cert_store 
WHERE (cert_thumbprint, partner_domain) IN 
      (SELECT cert_thumbprint, partner_domain 
       FROM your_table_name 
       GROUP BY cert_thumbprint, partner_domain 
       HAVING COUNT(*) > 1);

This query will retrieve the rows of data that contain duplicate entries.

As a precautionary measure, it is advisable to create a backup of all the duplicate values.
Remove the duplicate entries so that only one composite key remains. The aforementioned SQL script can be reused to verify that the duplicates have been successfully deleted. If the result is empty, then all duplicates have been removed.
By following these steps, the problem should be resolved, and the DB upgrade script can be executed without any further issues.

Adapting Changes in Administration Roles

Below is the list of admin roles:

GLOBAL_ADMIN
ZONAL_ADMIN
REGISTRATION_ADMIN
MASTERDATA_ADMIN
KEY_MAKER

GLOBAL_ADMIN

ZONAL_ADMIN

REGISTRATION_ADMIN

MASTERDATA_ADMIN

KEY_MAKER

Here:

Green- colored represent persisted roles.

Blue- colored cells represent newly added roles.

Red- colored cells represent removed roles.

How to adjust the role accessibilities for existing users after upgrading to 1.2.0.1-x from 1.1.5.5-P1?

For a user having GLOBAL_ADMIN role:

If a GLOBAL_ADMIN user is performing Certificate related operations then KEY_MAKER role need to be added to that user.
If a GLOBAL_ADMIN user is performing Packet Bulk Upload then REGISTRATION_ADMIN role need to be added to that user.

For a user having ZONAL_ADMIN role:

If a ZONAL_ADMIN user is performing Certificate related operations then KEY_MAKER role need to be added to that user.
If a ZONAL_ADMIN user is performing Packet Bulk Upload then REGISTRATION_ADMIN role need to be added to that user.

For a user having REGISTRATION_ADMIN role:

If a REGISTRATION_ADMIN user is performing Certificate related operations then KEY_MAKER role need to be added to that user.

For a user having MASTERDATA_ADMIN role:

If a MASTERDATA_ADMIN user is performing GenerateCSR then KEY_MAKER role need to be added to that user.
If a MASTERDATA _ADMIN user is performing Packet Bulk Upload then REGISTRATION_ADMIN role need to be added to that user.

Note: A few new permissions were added to MASTERDATA_ADMIN and KEY_MAKER roles, please refer to the above role matrix table and if there is any inconsistency in the accessibility or roles of existing user, please reassign the roles to the user accordingly.

Identifying Applicant Type

Location: repository

Applicant-type MVEL script usages in MOSIP modules :

This MVEL script is used to determine the type of applicant based on the captured demographic data during the registration process.

→ Set of rules to determine the type of applicant is written as an MVEL script.

→ Applicant Data required for the evaluation passed as “identity” map to the MVEL context.

→ def getApplicantType() method MUST be defined in the script. The string returned from this method should be a valid applicant type code or error code (KER-MSD-151, KER-MSD-147)

applicant_type_code - Must be one of the values in the apptyp_code column in “master.applicant_valid_document" table.

"KER-MSD-147" - returned when any of the demographics that are required for the script to return a code are empty (As per default script, it throws this exception if gender or residenceStatus or age is not filled / empty).

"KER-MSD-151" - returned when the DOB exceeds the current date.

→ Data in the “identity” map are key-value pairs. The Key is the field id in the id-schema.

→ For the fields which are based on dynamic field values. For Ex: gender

“identity” map will have 2 mappings, genderCode, and gender. where the

identity.genderCode = “FLE”

identity.gender = “Female”

→ Age group configuration is also passed in the MVEL context as below

{ “ageGroups” : {'INFANT':'0-5','MINOR':'6-17','ADULT':'18-200'} } and will be accessible as below in the script.

ageGroups.INFANT = “0-5”

ageGroups.MINOR = “6-17”

ageGroups.ADULT = “18-200”

Sample MVEL script is defined here https://github.com/mosip/mosip-config/blob/master/applicanttype.mvel

Note: In Pre-registration and Registration-Client, applicant-type code is used to control the list of documents to be collected during the registration process.

The applicant_type_code returned from this mvel script will be then used to fetch the required documents from master.applicant_valid_document table.

For example, if the script returns applicant_type_code as “001”, all those entries in the applicant_valid_document table with app_typ_code as “001” will be picked and shown in the respective document dropdowns.

Attaching the sample csv file below which lists down the required entries for master.applicant_valid_document table.

We can upload this default data from Admin Portal through Bulk Upload feature.

The steps to be followed are mentioned below:

Login to Admin Portal.
Navigate to Bulk Upload → Master Data.
Select the Insert operation, select the table name (ApplicantValidDocument) from the dropdown and upload the csv file.
Click on Upload, which saves the uploaded data to the server DB.

Attaching screenshot for reference:

Changes in Camel Route

This document outlines the changes made to the camel route file following the migration.

In the 1.2.0.1 release, there is a default camel route file for each registration type, without any differentiation between the dmz and mz concepts. This is due to the transition from V2 to V3 deployment, which is mandatory.

Workflow commands are implemented to handle the isValid and internal error, with the primary purpose of making important decisions regarding the overall workflow state. Previously, these decisions were made within each individual stage, but now we are transferring them to the camel route, allowing for easier customization by different countries. This change grants more flexibility in controlling the workflow and reduces the reliance on specific stages for decision-making. It is mandatory for the registration table to be updated with packet processing results in each stage, whether successful or failed, excluding the status code. The example below demonstrates one of the workflow commands utilized in routes.

<to uri="workflow-cmd://complete-as-failed" />

Below are the workflow commands:

Commands

Usage

workflow-cmd://complete-as-processed

The status code will be updated to "PROCESSED" and a websub event will be sent to the notification service for notification purposes. Additionally, it will check if there is an additional request ID present. If so, a tag will be created with a specific registration type and flow status set as "PROCESSED". Furthermore, the latest transaction status code of the main flow will be updated to "REPROCESS" in order to resume processing. Lastly, notifications will be added for failed, rejected, processed, and pause-and-request-additional-info records within the workflow.

workflow-cmd://complete-as-rejected

The status code will be updated to "REJECTED" and a websub event will be sent to the notification service for notification. Additionally, it will verify if there are any additional request IDs present. If so, a tag will be created for the specific registration type with a flow status of "REJECTED", and the processing of the main flow will be resumed.

workflow-cmd://complete-as-failed

The status code will be updated to FAILED, and a websub event will be sent to the notification service for notifying relevant parties. Additionally, if there is an additional request ID present, a tag will be created with the corresponding registration type and flow status as FAILED. Following this, the processing of the main flow will resume.

workflow-cmd://mark-as-reprocess

It will update status code to REPROCESS. It will create tag with particular reg type with flow status as FAILED

workflow-cmd://anonymous-profile

To store packet details in anonymous profile table

workflow-cmd://pause-and-request-additional-info

It will verify if there is an additional request ID. If there is, it will update the status code to "FAILED" and the latest transaction status code of the main workflow to "REPROCESS" in order to resume processing of the main workflow. If there is no additional request ID, it will update the status code to "PAUSED_FOR_ADDITIONAL_INFO" and create the additional request ID. It will then send a web sub-event to the notification service to trigger a notification.

The OSI validator stage is divided into four stages: operator-validator stage, supervisor-validator stage, introducer-validator stage, and cmd-validator stage. If a packet is determined to be valid, it will be directed from the packet classifier to the cmd-validator stage. This step is mandatory.

1.1.5.5

<route id="packet-classifier-->quality-checker new route">
        <from uri="eventbus:packet-classifier-new-bus-out" />
        <log
            message="packet-classifier-->quality-checker new route ${bodyAs(String)}" />
        <choice>
            <when>
                <simple>${bodyAs(String)} contains '"isValid":true'</simple>
                <to uri="eventbus:quality-checker-bus-in" />
            </when>
            <when>
                <simple>${bodyAs(String)} contains '"isValid":false' and ${bodyAs(String)} contains '"internalError":false'</simple>
                <to uri="eventbus:message-sender-bus-in" />
            </when>
            <when>
                <simple>${bodyAs(String)} contains '"internalError":true'</simple>
                <to uri="eventbus:retry-bus-in" />
            </when>
            <otherwise>
                <to uri="eventbus:error-bus-in" />
            </otherwise>
        </choice>
    </route>

1.2.0.1

<route id="packet-classifier-->cmd-validator new route">
     <from uri="eventbus://packet-classifier-new-bus-out" />
     <log message="packet-classifier-->quality-classifier new route ${bodyAs(String)}" />
     <choice>
        <when>
           <jsonpath>$.[?(@['isValid'] == false && @['internalError'] == true)]</jsonpath>
           <to uri="workflow-cmd://complete-as-failed" />
           <to uri="workflow-cmd://anonymous-profile" />
        </when>
        <when>
           <jsonpath>$.[?(@['isValid'] == true && @['internalError'] == true)]</jsonpath>
           <to uri="workflow-cmd://mark-as-reprocess" />
        </when>
        <when>
           <jsonpath>$.[?(@['isValid'] == false && @['internalError'] == false)]</jsonpath>
           <to uri="workflow-cmd://complete-as-failed" />
           <to uri="workflow-cmd://anonymous-profile" />
        </when>
        <otherwise>
           <to uri="eventbus://c-m-d-validator-bus-in" />
        </otherwise>
     </choice>
  </route>

Tags will be created in the packet classifier stage. Depending on the tags, the packet will be transferred from the command validator stage to either the supervisor or operator stage. In order to introduce validation and check tags, packets will be moved accordingly. The availability of tags allows us to modify camel routes. (Mandatory)

      <route id="cmd-validator-->operator-validator new route">
      <from uri="eventbus://c-m-d-validator-new-bus-out" />
      <log message="cmd-validator-->operator-validator/supervisor-validator new route ${bodyAs(String)}" />
      <choice>
         <when>
            <jsonpath>$.[?(@['isValid'] == false &amp;&amp; @['internalError'] == true)]</jsonpath>
            <to uri="workflow-cmd://complete-as-failed" />
            <to uri="workflow-cmd://anonymous-profile" />
         </when>
         <when>
            <jsonpath>$.[?(@['isValid'] == true &amp;&amp; @['internalError'] == true)]</jsonpath>
            <to uri="workflow-cmd://mark-as-reprocess" />
         </when>
         <when>
            <jsonpath>$.[?(@['isValid'] == false &amp;&amp; @['internalError'] == false)]</jsonpath>
            <to uri="workflow-cmd://complete-as-failed" />
            <to uri="workflow-cmd://anonymous-profile" />
         </when>
         <when>
            <jsonpath suppressExceptions="true">$.[?(@['tags']['META_INFO-OPERATIONS_DATA-officerId'] != '' &amp;&amp; @['tags']['META_INFO-OPERATIONS_DATA-officerId'] != '--TAG_VALUE_NOT_AVAILABLE--')]</jsonpath>
            <to uri="eventbus://operator-validator-bus-in" />
         </when>
         <when>
            <jsonpath suppressExceptions="true">$.[?(@['tags']['META_INFO-OPERATIONS_DATA-supervisorId'] != '' &amp;&amp; @['tags']['META_INFO-OPERATIONS_DATA-supervisorId'] != '--TAG_VALUE_NOT_AVAILABLE--')]</jsonpath>
            <to uri="eventbus://supervisor-validator-bus-in" />
         </when>
         <otherwise>
            <to uri="workflow-cmd://complete-as-failed" />
            <to uri="workflow-cmd://anonymous-profile" />
         </otherwise>
      </choice>
   </route>

The quality checker stage has been updated to the quality classifier stage. Packets are now transferred from the supervisor, operator, and introducer stages to the quality classifier stage, depending on the designated route. This change is mandatory.

<route id="operator-validator-->supervisor-validator new route">
   <from uri="eventbus://operator-validator-new-bus-out" />
   <log message="operator-validator-->supervisor-validator/introducer-validator/demo-dedupe new route ${bodyAs(String)}" />
   <choice>
      <when>
         <jsonpath>$.[?(@['isValid'] == false &amp;&amp; @['internalError'] == true)]</jsonpath>
         <to uri="workflow-cmd://complete-as-failed" />
         <to uri="workflow-cmd://anonymous-profile" />
      </when>
      <when>
         <jsonpath>$.[?(@['isValid'] == true &amp;&amp; @['internalError'] == true)]</jsonpath>
         <to uri="workflow-cmd://mark-as-reprocess" />
      </when>
      <when>
         <jsonpath>$.[?(@['isValid'] == false &amp;&amp; @['internalError'] == false)]</jsonpath>
         <to uri="workflow-cmd://complete-as-failed" />
         <to uri="workflow-cmd://anonymous-profile" />
      </when>
      <when>
         <jsonpath suppressExceptions="true">$.[?(@['tags']['META_INFO-OPERATIONS_DATA-supervisorId'] != '' &amp;&amp; @['tags']['META_INFO-OPERATIONS_DATA-supervisorId'] != '--TAG_VALUE_NOT_AVAILABLE--')]</jsonpath>
         <to uri="eventbus://supervisor-validator-bus-in" />
      </when>
      <when>
         <jsonpath suppressExceptions="true">$.[?(@['tags']['AGE_GROUP'] == 'INFANT' || @['tags']['AGE_GROUP'] == 'MINOR' || @['tags']['INTRODUCER_AVAILABILITY'] == 'true')]</jsonpath>
         <to uri="eventbus://introducer-validator-bus-in" />
      </when>
      <otherwise>
         <to uri="eventbus://quality-classifier-bus-in" />
      </otherwise>
   </choice>
</route>

Instead of manual verification in section 1.1.5.5, it is now replaced with manual adjudication in section 1.2.0.1. Additionally, a new route has been specified from the manual adjudication stage to the UIN generator stage in the XML route. In cases where duplicates are identified, the manual adjudication stage is added to the route after the demo dedupe and bio dedupe processes. This change is mandatory.

1.1.5.5

<route id="manual-verification-->uin-generation new route">
        <from uri="eventbus:manual-verification-new-bus-out" />
        <log
            message="manual-verification-->uin-generation new route ${bodyAs(String)}" />
        <choice>
            <when>
                <simple>${bodyAs(String)} contains '"isValid":true'</simple>
                <to uri="eventbus:uin-generator-bus-in" />
            </when>
            <when>
                <simple>${bodyAs(String)} contains '"isValid":false' and ${bodyAs(String)} contains '"internalError":false'</simple>
                <to uri="eventbus:message-sender-bus-in" />
            </when>
            <when>
                <simple>${bodyAs(String)} contains '"internalError":true'</simple>
                <to uri="eventbus:retry-bus-in" />
            </when>
            <otherwise>
                <to uri="eventbus:error-bus-in" />
            </otherwise>
        </choice>
    </route>

1.2.0.1

<route id="manual-adjudication-->uin-generation new route">
      <from uri="eventbus://manual-adjudication-new-bus-out" />
      <log message="manual-adjudication-->uin-generation new route ${bodyAs(String)}" />
      <choice>
         <when>
            <jsonpath>$.[?(@['isValid'] == false && @['internalError'] == true)]</jsonpath>
            <to uri="workflow-cmd://complete-as-failed" />
            <to uri="workflow-cmd://anonymous-profile" />
         </when>
         <when>
            <jsonpath>$.[?(@['isValid'] == true && @['internalError'] == true)]</jsonpath>
            <to uri="workflow-cmd://mark-as-reprocess" />
         </when>
         <when>
            <jsonpath>$.[?(@['isValid'] == false && @['internalError'] == false)]</jsonpath>
            <to uri="workflow-cmd://complete-as-rejected" />
            <to uri="workflow-cmd://anonymous-profile" />
         </when>
         <otherwise>
            <to uri="eventbus://uin-generator-bus-in" />
         </otherwise>
      </choice>
   </route>

New route has been added from UIN generator stage to biometric-extraction stage. This stage fetches biometric extraction policy from PMS and sends to ID Repository (mandatory).

 <route id="uin-generation route-->biometric-extraction-stage new route">
   <from uri="eventbus://uin-generator-new-bus-out" />
   <log message="uin-generation-->biometric-extraction-stage route ${bodyAs(String)}" />
   <choice>
      <when>
         <jsonpath>$.[?(@['isValid'] == false &amp;&amp; @['internalError'] == true)]</jsonpath>
         <to uri="workflow-cmd://complete-as-failed" />
         <to uri="workflow-cmd://anonymous-profile" />
      </when>
      <when>
         <jsonpath>$.[?(@['isValid'] == true &amp;&amp; @['internalError'] == true)]</jsonpath>
         <to uri="workflow-cmd://mark-as-reprocess" />
      </when>
      <when>
         <jsonpath>$.[?(@['isValid'] == false &amp;&amp; @['internalError'] == false)]</jsonpath>
         <to uri="workflow-cmd://complete-as-failed" />
         <to uri="workflow-cmd://anonymous-profile" />
      </when>
      <otherwise>
         <to uri="eventbus://biometric-extraction-bus-in" />
         <to uri="workflow-cmd://anonymous-profile" />
      </otherwise>
   </choice>
</route>

New route has been added from biometric-extraction stage to Finalization stage. This stage publishes draft version to ID Repository DB (Mandatory).


<route id="biometric-extraction route-->finalization-stage new route">
   <from uri="eventbus://biometric-extraction-new-bus-out" />
   <log message="biometric-extraction-->finalization-stage route ${bodyAs(String)}" />
   <choice>
      <when>
         <jsonpath>$.[?(@['isValid'] == false &amp;&amp; @['internalError'] == true)]</jsonpath>
         <to uri="workflow-cmd://complete-as-failed" />
         <to uri="workflow-cmd://anonymous-profile" />
      </when>
      <when>
         <jsonpath>$.[?(@['isValid'] == true &amp;&amp; @['internalError'] == true)]</jsonpath>
         <to uri="workflow-cmd://mark-as-reprocess" />
      </when>
      <when>
         <jsonpath>$.[?(@['isValid'] == false &amp;&amp; @['internalError'] == false)]</jsonpath>
         <to uri="workflow-cmd://complete-as-failed" />
         <to uri="workflow-cmd://anonymous-profile" />
      </when>
      <otherwise>
         <to uri="eventbus://finalization-bus-in" />
      </otherwise>
   </choice>
</route>

New route has been added from Finalization stage to Printing stage. This stage creates Credential Request for printing systems (mandatory).

 <route id="finalization route-->printing-stage new route">
      <from uri="eventbus://finalization-new-bus-out" />
      <log message="finalization-->printing-stage route ${bodyAs(String)}" />
      <choice>
         <when>
            <jsonpath>$.[?(@['isValid'] == false &amp;&amp; @['internalError'] == true)]</jsonpath>
            <to uri="workflow-cmd://complete-as-failed" />
            <to uri="workflow-cmd://anonymous-profile" />
         </when>
         <when>
            <jsonpath>$.[?(@['isValid'] == true &amp;&amp; @['internalError'] == true)]</jsonpath>
            <to uri="workflow-cmd://mark-as-reprocess" />
         </when>
         <when>
            <jsonpath>$.[?(@['isValid'] == false &amp;&amp; @['internalError'] == false)]</jsonpath>
            <to uri="workflow-cmd://complete-as-failed" />
            <to uri="workflow-cmd://anonymous-profile" />
         </when>
         <otherwise>
            <to uri="eventbus://printing-bus-in" />
         </otherwise>
      </choice>
   </route>

Based on Tags related to quality score, the packets will move form quality classifier to workflow-cmd://pause-and-request-additional-info or demodedupe (optional).

1.1.5.5

<route id="quality-checker-->osi-validator new route">
        <from uri="eventbus:quality-checker-new-bus-out" />
        <log
            message="quality-checker-->osi-validator new route ${bodyAs(String)}" />
        <choice>
            <when>
                <simple>${bodyAs(String)} contains '"isValid":true'</simple>
                <to uri="eventbus:o-s-i-validator-bus-in" />
            </when>
            <when>
                <simple>${bodyAs(String)} contains '"isValid":false' and ${bodyAs(String)} contains '"internalError":false'</simple>
                <to uri="eventbus:message-sender-bus-in" />
            </when>
            <when>
                <simple>${bodyAs(String)} contains '"internalError":true'</simple>
                <to uri="eventbus:retry-bus-in" />
            </when>
            <otherwise>
                <to uri="eventbus:error-bus-in" />
            </otherwise>
        </choice>
    </route>

1.2.0.1


<route id="quality-classifier-->demo-dedupe new route">
      <from uri="eventbus://quality-classifier-new-bus-out" />
      <log message="quality-classifier-->demo-dedupe new route ${bodyAs(String)}" />
      <choice>
         <when>
            <jsonpath>$.[?(@['isValid'] == false && @['internalError'] == true)]</jsonpath>
            <to uri="workflow-cmd://complete-as-failed" />
            <to uri="workflow-cmd://anonymous-profile" />
         </when>
         <when>
            <jsonpath>$.[?(@['isValid'] == true && @['internalError'] == true)]</jsonpath>
            <to uri="workflow-cmd://mark-as-reprocess" />
         </when>
         <when>
            <jsonpath>$.[?(@['isValid'] == false && @['internalError'] == false)]</jsonpath>
            <to uri="workflow-cmd://complete-as-failed" />
            <to uri="workflow-cmd://anonymous-profile" />
         </when>
         <when>
            <jsonpath suppressExceptions="true">$.[?(@['tags']['BIOMETRIC_CORRECTION_FLOW_STATUS'] in ['FAILED'] || @['tags']['BIOMETRIC_CORRECTION_FLOW_STATUS'] in ['REJECTED'])]</jsonpath>
            <setProperty propertyName="ADDITIONAL_INFO_PROCESS"><constant>BIOMETRIC_CORRECTION</constant></setProperty>
            <setProperty propertyName="PAUSE_FOR"><constant>1296000</constant></setProperty>
            <to uri="workflow-cmd://pause-and-request-additional-info" />
         </when>
         <when>
            <jsonpath suppressExceptions="true">$.[?(@['tags']['Biometric_Quality-Iris'] in ['Average', 'Good','--Biometrics-Not-Available--'] && @['tags']['Biometric_Quality-Finger'] in ['Average', 'Good', '--Biometrics-Not-Available--'] && @['tags']['Biometric_Quality-Face'] in ['Average', 'Good', '--Biometrics-Not-Available--'])]</jsonpath>
            <to uri="eventbus://demo-dedupe-bus-in" />
         </when>
         <when>
            <jsonpath suppressExceptions="true">$.[?(@['tags']['Biometric_Quality-Iris'] in ['Poor'] || @['tags']['Biometric_Quality-Finger'] in ['Poor'] || @['tags']['Biometric_Quality-Face'] in ['Poor'])]</jsonpath>
            <setProperty propertyName="ADDITIONAL_INFO_PROCESS"><constant>BIOMETRIC_CORRECTION</constant></setProperty>
            <!-- PAUSE_FOR is in seconds -->
            <setProperty propertyName="PAUSE_FOR"><constant>1296000</constant></setProperty>
            <to uri="workflow-cmd://pause-and-request-additional-info" />
         </when>
         <otherwise>
            <to uri="workflow-cmd://complete-as-failed" />
            <to uri="workflow-cmd://anonymous-profile" />
         </otherwise>
      </choice>
   </route>

We can use JSON path also and update the conditions. If we want to update route based on isValid and internalError then follow the below syntax (optional)

<jsonpath>$.[?(@['isValid'] == true && @['internalError'] == true)]</jsonpath>

If we wish to use check condition based on address, then follow the below syntax (optional) ,

<jsonpath suppressExceptions="true">$.[?(@['messageBusAddress']['address'] == 'verification-bus-in')]</jsonpath>

If we wish to use the check condition based on Tags, then follow as below (optional):

<jsonpath suppressExceptions="true">$.[?(@['tags']['AGE_GROUP'] == 'INFANT' || @['tags']['AGE_GROUP'] == 'MINOR' || @['tags']['INTRODUCER_AVAILABILITY'] == 'true')]</jsonpath>

If we want to set the property in camel route, then follow the steps as below. .

This property is used for PAUSE and RESUME feature. We cant set application properties here (optional)

<setProperty propertyName="PAUSE_FOR"><constant>1296000</constant></setProperty>

As a part of the 1.2.0.1 update, if no biometric data is available, the system will proceed to the verification stage. This stage is only relevant in cases where the required biometrics are missing from the packet. The system will send the applicant's demographic and biometric information to the external Verification System (VS) through a queue and Datashare. Upon receiving the decision from the VS, the system will proceed accordingly and forward the packets. In case of rejection, the applicant will be notified (optional).

New route is specified from verification to UIN generator stage route.xml


 <route id="verification route-->uin-generator new route">
      <from uri="eventbus://verification-new-bus-out" />
      <log message="verification route-->uin-generator new route ${bodyAs(String)}" />
      <choice>
         <when>
            <jsonpath>$.[?(@['isValid'] == false &amp;&amp; @['internalError'] == true)]</jsonpath>
            <to uri="workflow-cmd://complete-as-failed" />
            <to uri="workflow-cmd://anonymous-profile" />
         </when>
         <when>
            <jsonpath>$.[?(@['isValid'] == true &amp;&amp; @['internalError'] == true)]</jsonpath>
            <to uri="workflow-cmd://mark-as-reprocess" />
         </when>
         <when>
            <jsonpath>$.[?(@['isValid'] == false &amp;&amp; @['internalError'] == false)]</jsonpath>
            <to uri="workflow-cmd://complete-as-failed" />
            <to uri="workflow-cmd://anonymous-profile" />
         </when>
         <otherwise>
            <to uri="eventbus://uin-generator-bus-in" />
         </otherwise>
      </choice>
   </route>

Now securezone-notification stage can consume from securezone-notification-bus-in address which is from packet receiver stage. We can even use, http://regproc-group2.regproc/registrationprocessor/v1/securezone/notification instead of http://mz.ingress:30080/registrationprocessor/v1/securezone/notification (optional)

1.1.5.5

<route id="packet-reciever-->securezone-notification new route">
    <from uri="eventbus:packet-receiver-new-bus-out" />
    <log
        message="packet-reciever-->packet-uploader new ${bodyAs(String)}" />
    <choice>
        <when>
            <simple>${bodyAs(String)} contains '"isValid":true'</simple>
            <process ref="tokenGenerationProcessor"/>
            <setHeader headerName="CamelHttpMethod">
                <constant>POST</constant>
            </setHeader>
            <setHeader headerName="Content-Type">
                <constant>application/json</constant>
            </setHeader>
            <setHeader headerName="Cookie">
                <simple>${header.Cookie}</simple>
            </setHeader>
            <setBody>
                <simple>${bodyAs(String)}</simple>
            </setBody>
            <to uri="http://mz.ingress:30080/registrationprocessor/v1/securezone/notification" />
        </when>
        <when>
            <simple>${bodyAs(String)} contains '"internalError":true'</simple>
            <to uri="eventbus:retry-bus-in" />
        </when>
        <otherwise>
            <to uri="eventbus:error-bus-in" />
        </otherwise>
    </choice>
</route>

1.2.0.1

<route id="packet-receiver-->securezone-notification new route">
  <from uri="eventbus://packet-receiver-new-bus-out" />
  <log message="packet-receiver-->securezone-notification new ${bodyAs(String)}" />
  <choice>
     <when>
        <jsonpath>$.[?(@['isValid'] == false && @['internalError'] == true)]</jsonpath>
        <to uri="workflow-cmd://complete-as-failed" />
     </when>
     <when>
        <jsonpath>$.[?(@['isValid'] == true && @['internalError'] == true)]</jsonpath>
        <to uri="workflow-cmd://mark-as-reprocess" />
     </when>
     <when>
        <jsonpath>$.[?(@['isValid'] == false && @['internalError'] == false)]</jsonpath>
        <to uri="workflow-cmd://complete-as-failed" />
     </when>
     <otherwise>
        <to uri="eventbus://securezone-notification-bus-in" />
     </otherwise>
  </choice>

~~~

Changes in Role Management based on Client IDs

Partner Management Services

In previous versions (1.1.5.x) of our system, we utilized the mosip-partner-client for Partner Management Services (PMS). However, starting from version 1.2.0.1 onwards, we have implemented the use of mosip-pms-client instead. This transition has led to updates in service account roles, client scopes, and client configurations.

Please find below the details of the changes made to service account roles and client scopes.

Service account roles for Partner-Management-Services

mosip-partner-client (1.1.5.x)

mosip-pms-client (1.2.0.1)

Client Scopes for Partner-Management-Services:

Admin-Services

In version 1.1.5.x, the mosip-admin-client was utilized for administrative services. We are also continuing to utilize the same client in version 1.2.0.1. While there have been modifications to the service account roles, the Client scopes have remained unchanged. Please find below the updated service account role adjustments. Additionally, it is worth noting that MOSIP Commons is also utilizing this client.

Service account roles for Admin-Services:

Client scopes are the same for mosip-admin-client in 1.2.0.1 & 1.1.5.1

email
profile
roles
web-origins

Pre-registration

In version 1.1.5.x, we utilized the 'mosip-prereg-client' for Pre-Registration. This client is also utilized in version 1.2.0.1. There have been modifications in the service account roles, while the client scopes have remained unchanged. Please find below the updated service account roles.

Service account roles for Pre-Registration:

Note: Prior to proceeding with the upgrade, please ensure that the INDIVIDUAL role has been removed.

Client scopes are the same for mosip-prereg-client in 1.2.0.1 & 1.1.5.1

email
profile
roles
web-origins

ID Authentication

In the previous version 1.1.5.x, the mosip-ida-client module was responsible for handling ID authentication. However, starting from version 1.2.0.1, we have switched to using mpartner-default-auth for this purpose. This transition has brought about several changes, including modifications to service account roles, client scopes, and client configurations. Below is an overview of the changes in service account roles and client scopes.

Service account roles for id-authentication:

Client Scopes for id-authentication:

Digital-card-service

In the previous version, 1.1.5.x, we did not employ any clients for our digital card service. However, in the latest version, 1.2.0.1, we have implemented the use of the mpartner-default-digitalcard client. Please find below the service account roles and client scopes associated with the mpartner-default-digitalcard client.

Service account roles assigned to _mpartner-default-digitalcard_** in 1.2.0.1**

CREATE_SHARE
CREDENTIAL_REQUEST
default_roles_mosip
PRINT_PARTNER
PUBLISH_CREDENTIAL_STATUS_UPDATE_GENERAL
SUBSCRIBE_ CREDENTIAL_ISSUED_INDIVIDUAL
SUBSCRIBE_IDENTITY_CREATED_GENERAL
SUBSCRIBE_IDENTITY_UPDATED _GENERAL

Client scopes assigned to _mpartner-default-digitalcard_** in 1.2.0.1**

email
profile
roles
web-origins

Print

In version 1.1.5.x, we do not employ any clients for printing. However, beginning from version 1.2.0.1, we utilize the mpartner-default-print client. Please find below the service account roles and client scopes associated with the mpartner-default-print client.

Service account roles assigned to _mpartner-default-print_** in 1.2.0.1**

CREATE_SHARE
default_roles_mosip
PUBLISH_CREDENTIAL_STATUS_UPDTAE_GENERAL
SUBSCRIBE_ CREDENTIAL_ISSUED_INDIVIDUAL

Client scopes assigned to _mpartner-default-print_** in 1.2.0.1**

email
profile
roles
web-origins

ID Repository

In version 1.1.5.x, we utilized the mosip-regproc-client for id-repository. Starting from version 1.2.0.1, we have transitioned to using mosip-idrepo-client. This switch has led to modifications in service account roles, client scopes, and client settings. Below are the details of the changes in service account roles and client scopes.

Client Scopes for id-repository:

Service account roles for id-repository:

Resident Services

In version 1.1.5.x, we utilized the mosip-resident-client for Resident Services. This client is also employed in version 1.2.0.1. Although there were modifications in service account roles, the client scopes remain unchanged. Below the details of the alterations made in service account roles.

Service account roles for Resident-Services:

Client Scopes for Resident-Services:

Compliance-Tool-Kit

In previous iterations (1.1.5.x) of our system, we did not employ any clients for the compliance toolkit. However, beginning with version 1.2.0.1, we have implemented the use of mosip_toolkit_client. The following information outlines the service account roles and client scopes associated with mosip_toolkit_client.

Service account roles assigned to _mosip_toolkit_client_** in 1.2.0.1**

default_roles_mosip

Client scopes assigned to _mosip_toolkit_client_** in 1.2.0.1**

email
profile
roles
web-origins

Handling Case Insensitive Duplicated User Details

In the registration processor, there was an issue where packets were failing at the supervisor validation stage when the username of the supervisor was entered in a different case than it appeared in the database. To resolve this issue, a case insensitive search will be implemented to retrieve the username of the supervisor during the validation stage.

In order for this fix to work properly, it is necessary for the user_id column of the user_details table in the master database to not contain any case insensitive duplicates.

If there are any duplicates in this table, packets will fail at the supervisor validation stage once again. Therefore, it is important to deactivate or delete these case insensitive duplicates. It should be noted that this action will not have any impact on other areas, as the mapping between keycloak users and the user_id of the user_details table is one-to-one and case insensitive.

How can we identify case-insensitive duplicates in the `user_id` column of the `user_details` table?

Follow these steps:

Log in to the master schema of the mosip_master database.
Open a query tool.
Execute the following SQL command in the query tool:
```
SELECT lowerid, cnt from (SELECT count(*) as cnt,LOWER(id) as lowerid FROM master.user_detail group by lowerid) t1 where cnt>1 ;
```
Make sure to copy the output to a text file to manage the duplicate data effectively.

How to deactivate/delete the case insensitive duplicates?

Login in to the admin portal with a user having ZONAL_ADMIN role.
On the left pane, click on Resources in the side-menu.
Select User Center Mapping under Resources in the side-menu.
Click Filter on the User Center Mapping page.
Enter the user_id that was retrieved from the database and copied into the text file. After entering the user_id, click on the Apply button.
- Now, on the User Center Mapping page, case insensitive duplicates of user_id would be displayed.
- Based on the Center, choose the entry that can be deactivated/deleted.
- Now click on the ellipsis of the selected entry.
Select the appropriate action (Delete/ Deactivate) on that entry.

Managing Unequal Certificates

First, we will compare the thumbprints in the key_alias tables' thumbprint column of the mentioned IDA and Keymanager DB.

To check if the thumbprints are the same in both databases, we can follow these steps. For demonstration purposes, we will use 'mpartner-default-auth' as an example.

Check through SQL commands

-- SQL commands to find the entry in both Keymanager  and IDA databases respectively. The cert_thumbprint column to be compared between both the entries.
select * from key_alias where app_id='PARTNER' and ref_id = 'mpartner-default-auth' order by key_expire_dtimes desc limit 1;
select * from key_alias where app_id='IDA' and ref_id = 'mpartner-default-auth' order by key_expire_dtimes desc limit 1;

In the results of the above query, if it is found that the thumbprints do not match, the next objective is to take the MOSIP signed certificate from keymanager and store it in IDA manually, so that they match.

Here is a simple method to accomplish that task.

A. Perform the required authentication at authmanager portal using the below swagger URL

Sample request body:


{
  {
  "id": "string",
  "version": "string",
  "requesttime": "2023-08-31T12:42:06.436Z",
  "metadata": {},
  "request": {
   "clientId": "mosip-regproc-client",
    "secretKey": "****************",
    "appId": "regproc"
  }
}

B. Get the certificate using following swagger URL

In the app_id field use : PARTNER , in the ref_id field use : name of the partner whose cert thumbprints are mismatching such as mpartner-default-auth.

Sample response:

{
  "id": null,
  "version": null,
  "responsetime": "2023-08-31T12:44:28.804Z",
  "metadata": null,
  "response": {
    "certificate": "-----BEGIN CERTIFICATE-----\nMIIDjCCAqagAwgKoZIhvcNAQELBQAwdjELMAkGA1UE\nBhMCSU4xCzAJBgNVBAgMAktBMRIwEAYDVQQHDAlCQU5HQUxPUkUxDTALBgNVBAoM\nBElJVEIxIDAeBgNVBAsMF01PU0lQLVRFQ0gtQ0VOVEVSIChQTVMpMRUwEwYDVQQD\nDAx3d3cubW9zaXAuaW8wHhcNMjMwNzE4MDgwNDA4WhcNMjQwNzE3MDgwNDA4WjCB\ngzELMAkGA1UEBhMCSU4xCzAJBgNVBAgMAktBMRIwEAYDVQQHDAlCQU5HQUxPUkUx\nDTALBgNVBAoMBElJVEIxIDAeBgNVBAsMF01PU0lQLVRFQ0gtQ0VOVEVSIChJREEp\nMSIwIAYDVQQDDBlJREEtbXBhcnRuZXItZGVmYXVsdC1hdXRoMIIBIjANBgkqhkiG\n9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtcHF46xabZVp3WtvULbMT/5BBDtzO5pR00nb\nhg+lJ/Tjxtdk6XnMWV7uDD3vsAAhyBw/DxD0DApb02o6Ocf8yMl5NSWIPzJPFSGw\nL6fMhJUuocE/Ng9fVQ4cO9gC/QLxVKTRncpGJeXh0WE6zcZO5t8Vkvy8hq5IIS44\nOECp9ynhx6OIhvEZaJmETmnVQoYZ6KhcPVNgb7otXimSOmuZ4XDhYSJXxE7CT7V+\n8Q/pZvQ4apjmPhqCB5dypEwkuFvDk1fkRJhyHgZhd8adsuj3mbRlK9O7tHFV0hV2\nYo93csKu7AqqU7H+H788CDkjmOX6LqaHk5LxPufsKOWp8DfhqQIDAQABo0IwQDAP\nBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBRDUl0RAF5gjF8Kqn0SQW8oTpWgcTAO\nBgNVHQ8BAf8EBAMCAqQwDQYJKoZIhvcNAQELBQADggEBAA7dj1TqEHjZFMju9wt8\nDRI4sUMbf4YtPQQ65ACZ5K+mSBsKWwNQHXna8wn7JMOAFZFxNmz8TKFXAFBbVfYg\neqd2LPsgVpUTy35E3BwjTU90X0viS6o/2bNT0UAo5u1s9PG9YY7p/AUfr1x3kVow\nkplctHOwFmEF1S+Gzq2F1q7sFV41sePYNf5ZEDByc37M9Mdm7D4nddcnYFEbSOdT\nOOCVjt9yM50rE7OinFdBMlkkRiWazuxoXmR2ysumIf0szfNLuCsvJUZw68MUWY8g\nNuPEOUxOo3Es7uNkPTWbLPN5p2tMGNJ3LC4cp86e1aSCzNRFYeDcPbuvf966CY4M\n7X8=\n-----END CERTIFICATE-----\n",
    "certSignRequest": null,
    "issuedAt": "2023-07-18T08:04:08.000Z",
    "expiryAt": "2024-07-17T08:04:08.000Z",
    "timestamp": "2023-08-31T12:44:28.855Z"
  },
  "errors": null
}

C. Now, reauthenticate in the same authmanager URL (note the different clientId , appId and corresponding secret key changes )

https://api-internal.dev.mosip.net/v1/authmanager/swagger-ui/index.html?configUrl=/v1/authmanager/v3/api-docs/swagger-config#/authmanager/clientIdSecretKey

Sample Request

{
  {
  "id": "string",
  "version": "string",
  "requesttime": "2023-08-31T12:42:06.436Z",
  "metadata": {},
  "request": {
    "clientId": "mosip-ida-client",
    "secretKey": "************",
    "appId": "ida"
  }
}

D. After getting the certificate through step B mentioned above, copy it and use it in the following POST request in the below swagger URL:

https://api-internal.dev.mosip.net/idauthentication/v1/internal/swagger-ui/index.html?configUrl=/idauthentication/v1/internal/v3/api-docs/swagger-config#/keymanager/uploadCertificate

In applicationId field use IDA and in the referenceId field use name of the partner whose cert thumbprints are mismatching such as mpartner-default-auth.

Sample request

{
  "id": "string",
  "version": "string",
  "requesttime": "2023-08-31T12:46:55.317Z",
  "metadata": {},
  "request": {
    "applicationId": "IDA",
    "referenceId": "mpartner-default-auth",
    "certificateData": "certificate from step-B"
  }
}

After successfully completing this final step, we can proceed to the SQL cmd check mentioned at the beginning of this document and ensure that the thumbprints now match.

Basic Troubleshooting

Always ensure that you are using the correct base-url for your environment. In our case, it is dev.mosip.net and this should be used in all swagger links. Make sure to change it according to your requirement.
If you encounter an error code such as "errorCode": "500", "message": "401 Unauthorized", please re-authenticate using the authmanager token provided and ensure that you are using the proper credentials.
If you receive a 400 Bad request error, please resend your request with the correct time format and verify that your request JSON is in the specified format.
If you encounter any other issues, please remember to post your queries on the MOSIP Community.

New Datashare Properties

If a country desires to designate specific data sharing to be transmitted on HTTP or HTTPS endpoints, they should accomplish this by including the Domain URL of the data sharing in the policy field itself. This will have priority over any other settings.

Furthermore, two new fields have been incorporated into the policy:

shareDomainUrlWrite: This field should be employed by individual modules when calling the data sharing functionality to write data.
shareDomainUrlRead: This field should be used by the data sharing functionality when generating a URL to share with modules for reading data.

Note: It is important to note that these fields are compatible with previous versions and are not obligatory to include in all policies. They can be utilized only if a country sees a need for the new features.

Handling Non-Recoverable Packets

After running the reprocess utility and regproc reprocessor, it is possible that a few packets may end up in the FAILED status. This can occur due to various reasons such as environment instability or high parallel processing of packets. The following steps will help in identifying if such packets exist and how to handle them.

To handle these packets, please follow the below steps:

Use the sample query below to find out if there are packets in a non-recoverable state:

SELECT * FROM registration WHERE status_code='FAILED' AND latest_trn_Dtimes > '2023-10-10 10:00:00.000000' AND cr_Dtimes < '2023-08-25 00:00:00.000000';

Here, cr_Dtimes should be less than the time of upgrade completion and the processing of the first packet. latest_trn_Dtimes should be greater than the time of upgrade completion and the processing of the first packet. If there are no packets in this status, no further action is required. If any packets are found with the above status, proceed to step 2.

Before running the reprocess utility to process the packet from the beginning as per the APPROACH 1 in document, update the DEFAULT QUERY in the config.py file as per the requirements to process non-recoverable records.

The sample query is as follows:

SELECT reg_id, process, workflow_instance_id, iteration FROM registration WHERE status_code='FAILED' AND latest_trn_Dtimes > '2023-10-10 10:00:00.000000' AND cr_Dtimes < '2023-08-25 00:00:00.000000' LIMIT 1000;

Here, the status code should be set to FAILED. cr_Dtimes should be less than the time of upgrade completion and the processing of the first packet. latest_trn_Dtimes should be greater than the time of upgrade completion and the processing of the first packet.

After changing the query in config.py, please refer to the documentation on how to set up and run the reprocessor script.

To reprocess packets, use the following command:

$ ./reprocess.py --db

Partners' Certificate Expired

Here's how to fix it!.

The key point to note here is that MOSIP only accepts partners whose client certificates have a minimum of 1 year of validity remaining. MOSIP re-signs the client certificate with a 1-year validity. The respective partner must renew their certificate before the MOSIP-signed certificate expires in order to continue communication with MOSIP.

However, if this renewal is not done, the certificates will expire.

Here is a three-step process to address this scenario:

a. How to check the validity of your partner's certificate?

To check the validity, the user must have access to the database.

The user can access the mosip_keymanager database and open two tables: ca_cert_store and partner_cert_store.

The ca_cert_store table stores the CA and SUBCA/Intermediate CA certificates, while the partner_cert_store table stores the PARTNER/CLIENT certificates. In both of these tables, there are columns named cert_not_before and cert_not_after which provide details about the validity of the partner's certificate.

b. How to extend the validity of the partner's certificate?

There are two categories of partners: MOSIP Internal partners (e.g., IDA) and External partners (e.g., Device Partners, MISP partners).

For MOSIP Internal partners, if the validity of their certificate needs to be increased, the onboarder script can be run again for that specific partner. The onboarder will create fresh certificates and upload them to extend the validity.
For External Partners, they will need to obtain fresh certificates from their CA and upload them to extend their validity.

c. Troubleshooting common errors:

KER-ATH-401 Authentication Failed

If the user encounters this error code, it means that the user is not authenticated. The user should authenticate first before using the API.

KER-PCM-005 Root CA Certificate not found.

If the user encounters this error code, it means that there is an issue with either the CA or SUBCA certificate. The user must resolve the CA/SUBCA issue first.

Handling Partner Organization Name Mismatch Issue

This document helps in addressing an error related to partner organization name mismatch.

How do we handle this error?

During the partner certificate renewal process, users may encounter an error message while uploading the partner certificate.

KER-PCM-008 
Partner Organization Name not Matched.

The error code KER-PCM-008 indicates a partner organization name mismatch.

This error suggests that the organization name on the partner's certificate is different from the one originally registered with.

To resolve this issue, users need to manually update the name column in the partner table of the mosip_pms database with the new organization name from the fresh certificates.

After successfully uploading the partner certificate, it is important to restart the partner-management-service pod.

<<>

Registration Client Upgrade

The Registration Client Docker serves as a registration client zip downloader and upgrade server. The Nginx server within the Registration Client Docker container provides all necessary artifacts and resources during the upgrade process.

Patch updates:

When the registration client is launched, it downloads the manifest file from the upgrade server if the machine is online. Otherwise, it uses the local manifest file.
The client compares the checksum of each JAR file in the lib directory with the checksum stored in the manifest file. If there's a mismatch, the client considers the file invalid and deletes it before downloading it from the client upgrade server.
A checksum mismatch may be intentional for the rollout of hotfixes in the libraries used by the registration client or in the registration-client and registration-service module.
Patch updates do not support the upgrade of local Derby DB.

Assumption:

No major or minor version changes should occur for registration-client and registration-services modules.
Registration clients must be online to receive patch updates.

To roll out patches:

Rebuild the Registration Client Dockerfile and publish it with the same version.
Restart the registration client pod in Rancher.

For slow connections or connection failures:

If the client fails to download the manifest file when the machine is online, the registration client application will exit and report a build status check failure in the pre-loader screen.
If the latest manifest file is successfully downloaded but fails to download all the patches, the registration client application will exit and report a patch download failure.
In both cases, the operator/supervisor must restart the registration client application with a stable network connection. Upon restart, the client application will repeat the check from the server and continue the patch update.

Patch updates can include updates to existing libraries and the addition of new files. However, they are only applied to files in the lib directory.

Note: Deleting the registration-client.jar or registration-services.jar is not recoverable.

Version upgrade

This procedure entails upgrading from one version of the software to the next iteration.

Additionally, this may involve upgrading local derby databases.

Upon each launch of the registration client, the client retrieves the maven-metadata.xml file from the client upgrade server. The version specified in the local manifest file is then compared to the initial version element found in the maven-metadata.xml.

Should the version values differ, the client recognizes it as an available upgrade to a new version.

Above is the sample content of maven-metadata.xml.

The version upgrades are not performed automatically and must be initiated by the operator or supervisors. The process for the version upgrade can be outlined as follows:

Backup the database, libraries, binary, and manifest files and folders.
Download the latest JAR files and manifest files from the upgrade server to the local machine.
Prompt the operator/supervisor to restart the registration client with the upgraded JAR files.
Upon restart, the application executes the database upgrade scripts.
If the execution of the upgrade scripts is successful, the registration client starts and the version upgrade process is considered complete.
In the event of failure, rollback scripts for the database are executed and the registration client application exits. The operator/supervisor must rerun the registration client to initiate the execution of the upgrade database scripts.
Once the version upgrade process is successfully completed, the backup folder is removed and the registration client is fully functional for use.

From version 1.1.5.5 and above, the registration client now has the ability to upgrade directly from one version to another without going through the versions in between.

To enable this upgrade process, a new configuration has been introduced. This configuration is required for the upgrade to any higher version. The configuration key that needs to be set is mosip.registration.verion.upgrade.version-mappings.

The version-mappings configuration specifies the list of released versions of the registration client, their respective release order, and the database scripts folder name.

For example, to upgrade from version 1.1.4 to version 1.1.5.5, the configuration should be specified as follows:

This configuration needs to be specified in the spring.properties file of the registration-services.

During the registration client upgrade process, the application retrieves the above configuration and initiates the database upgrade based on the specified list of versions.

The upgrade progresses according to the releaseOrder and executes the necessary database scripts based on the dbVersion value.

How to roll out version upgrades?

In rancher,

Delete the existing version helm deployment of the registration client.
Deploy the new version of the registration client helm chart.

Example:

Let us assume that the registration-client version 1.1.5.5 is currently running, and we have to upgrade to version 1.2.0.1 version.

What happens after deploying the 1.2.0.1 version registration client in rancher?

Registration clients downloading the maven-metadata.xml from the upgrade server will be aware of the new version availability.

content:

Based on the first version available in the maven-metadata.xml, registration client will next download the MANIFEST.MF.

After the successful download of the manifest file, the registration client will start the download of all the new files, updates the existing file if the hash is mismatched, and deletes the unused files from the lib directory.

After completing the download, operator/supervisor will be prompted to restart the registration client.

Next restart, will start the registration client as version 1.2.0.1 and starts the DB upgrade script execution if present based on the version-mappings configuration available.

The status of the DB script execution is printed on the preloader screen and also logged into registration.log.

Backups and rollbacks

During the version upgrade process, we create backups of the manifest, db, lib, and bin folders in the designated backup directory. Once the upgrade is completed successfully, the backups are cleared. However, if the upgrade fails, we only roll back the changes made to the database.

In the event that the registration client application gets stuck during the upgrade due to errors or failures in the background, it is necessary for the operator or supervisor to manually roll back to the previous version of the registration client.

Below are the steps for manually rolling back:

1.1.4.* to 1.1.5.5 / 1.1.4.* to 1.2.0.*

Close the registration client application.
Delete the db and .mosipkeys folders in the reg-client working directory.
Navigate to the designated backup directory, where you will find a folder named after the previous version and the timestamp when it was created. For example, "1.1.4.4_2023-05-30 13-00-27.238Z".
Copy all the files and folders (lib, bin, MANIFEST.MF) from the backup to the registration client working directory, except for the .mosipkeys folder.
Copy the .mosipkeys folder from the backup to the home directory of the current user.
Launch the registration client application again.

1.1.5.5 to 1.2.0.*

Close the registration client application.
Delete the db folder, if it exists, in the registration client working directory.
Navigate to the designated backup directory, where you will find a folder named after the previous version and the timestamp when it was created. For example, "1.1.5.5_2023-05-30 13-00-27.238Z".
Copy all the files and folders (lib, bin, MANIFEST.MF) from the backup to the registration client working directory.
Launch the registration client application again.

By following these steps, the registration client application will be successfully rolled back to its previous version.

Guide to Reprocess Packets Manually

This document provides instructions on manually reprocessing all packets from the beginning after migration. The 1.2.0.1 release introduces multiple new stages and a new tagging mechanism. All packets that have not been processed before migration will be reprocessed to ensure they go through the new stages.

To facilitate packet reprocessing, MOSIP provides a Python script. This approach involves fetching all RIDs from the database using a query and processing them from the beginning. Please consult the documentation for instructions on setting up and running the reprocessing script. The query can be found in the config.py file.

Note: This script is highly customizable, and each country can modify it according to their specific requirements. This document outlines the general approach for reprocessing packets. If a country has special needs, the query will need to be adjusted accordingly.

The following command should be used to reprocess packets:

$ ./reprocess.py --db

It is important to first reprocess just one packet after migration to ensure that all stages are functioning correctly. This can be accomplished by setting the limit to 1. Please refer to the explanation below for instructions on changing the limit.

APPROACH 1

DEFAULT QUERY

query="SELECT reg_id, process, workflow_instance_id FROM registration WHERE latest_trn_status_code IN ('SUCCESS', 'REPROCESS', 'IN_PROGRESS') AND reg_process_retry_count <= 500 AND latest_trn_dtimes < (SELECT NOW() - INTERVAL '1 DAY') AND status_code NOT IN ('PROCESSED', 'FAILED', 'REJECTED') LIMIT 1000"

The default query reprocesses all packets that were not "PROCESSED" or "REJECTED" before migration. The query uses a limit of 1000 packets and a 1-second delay between each packet. This means that when the script is executed, it will reprocess 1000 packets one by one with a 1-second interval. These settings can be adjusted if necessary in the config.py file:

LIMIT 1000 # Can be changed as needed.
latest_trn_dtimes < (SELECT NOW() - INTERVAL '1 DAY') # Can be changed based on the time difference during migration.
delay = 1 # Seconds

This query also selects packets that are one day old (latest_trn_dtimes < (SELECT NOW() - INTERVAL '1 DAY')). This ensures that the script does not reprocess the same packets repeatedly. The time frame should be adjusted according to the system downtime caused by migration.

A country can determine the number of packets to be reprocessed in each batch and set the limit accordingly. The script should be executed the necessary number of times. For example, if there are 10000 pending packets and the limit is set to 1000, the script should be run 10 times.

APPROACH 2

This approach is designed for countries where packets are not directly routed from the securezone. In cases where the country has disabled routing from the securezone by setting the below property to false, the securezone notification stage should be disregarded. This is because any packets that have not moved beyond the securezone will be taken care of by the automated reprocessor.

Property: securezone.routing.enabled=false

This approach is similar to APPROACH 1 with one key difference. It utilizes the latest_trn_type_code in the query to specifically target packets that are stuck in these stages for reprocessing. It will disregard packets stuck in other stages.

Note: If any custom stage is introduced by the country, the latest_trn_type_code should be added to the query.

Query:

query="select reg_id,process,workflow_instance_id from registration where latest_trn_status_code in ('SUCCESS', 'REPROCESS', 'IN_PROGRESS') and reg_process_retry_count<=500 and latest_trn_dtimes < (SELECT NOW() - INTERVAL '1 DAY') and status_code NOT IN ('PROCESSED', 'FAILED', 'REJECTED')
and latest_trn_type_code in ('UPLOAD_PACKET', 'VALIDATE_PACKET', 'QUALITY_CHECK', 'OSI_VALIDATE', 'BIOMETRIC_AUTHENTICATION', 'DEMOGRAPHIC_VERIFICATION', 'BIOGRAPHIC_VERIFICATION', 'MANUAL_VERIFICATION', 'UIN_GENERATOR') LIMIT 1000"

Changes in Camel Route

This document outlines the changes made to the camel route file following the migration.

In the 1.2.0.1 release, there is a default camel route file for each registration type, without any differentiation between the dmz and mz concepts. This is due to the transition from V2 to V3 deployment, which is mandatory.

Workflow commands are implemented to handle the isValid and internal error, with the primary purpose of making important decisions regarding the overall workflow state. Previously, these decisions were made within each individual stage, but now we are transferring them to the camel route, allowing for easier customization by different countries. This change grants more flexibility in controlling the workflow and reduces the reliance on specific stages for decision-making. It is mandatory for the registration table to be updated with packet processing results in each stage, whether successful or failed, excluding the status code. The example below demonstrates one of the workflow commands utilized in routes.

<to uri="workflow-cmd://complete-as-failed" />

Below are the workflow commands:

Commands

Usage

workflow-cmd://complete-as-processed

workflow-cmd://complete-as-rejected

workflow-cmd://complete-as-failed

workflow-cmd://mark-as-reprocess

It will update status code to REPROCESS. It will create tag with particular reg type with flow status as FAILED

workflow-cmd://anonymous-profile

To store packet details in anonymous profile table

workflow-cmd://pause-and-request-additional-info

The OSI validator stage is divided into four stages: operator-validator stage, supervisor-validator stage, introducer-validator stage, and cmd-validator stage. If a packet is determined to be valid, it will be directed from the packet classifier to the cmd-validator stage. This step is mandatory.

1.1.5.5

<route id="packet-classifier-->quality-checker new route">
        <from uri="eventbus:packet-classifier-new-bus-out" />
        <log
            message="packet-classifier-->quality-checker new route ${bodyAs(String)}" />
        <choice>
            <when>
                <simple>${bodyAs(String)} contains '"isValid":true'</simple>
                <to uri="eventbus:quality-checker-bus-in" />
            </when>
            <when>
                <simple>${bodyAs(String)} contains '"isValid":false' and ${bodyAs(String)} contains '"internalError":false'</simple>
                <to uri="eventbus:message-sender-bus-in" />
            </when>
            <when>
                <simple>${bodyAs(String)} contains '"internalError":true'</simple>
                <to uri="eventbus:retry-bus-in" />
            </when>
            <otherwise>
                <to uri="eventbus:error-bus-in" />
            </otherwise>
        </choice>
    </route>

1.2.0.1

<route id="packet-classifier-->cmd-validator new route">
     <from uri="eventbus://packet-classifier-new-bus-out" />
     <log message="packet-classifier-->quality-classifier new route ${bodyAs(String)}" />
     <choice>
        <when>
           <jsonpath>$.[?(@['isValid'] == false && @['internalError'] == true)]</jsonpath>
           <to uri="workflow-cmd://complete-as-failed" />
           <to uri="workflow-cmd://anonymous-profile" />
        </when>
        <when>
           <jsonpath>$.[?(@['isValid'] == true && @['internalError'] == true)]</jsonpath>
           <to uri="workflow-cmd://mark-as-reprocess" />
        </when>
        <when>
           <jsonpath>$.[?(@['isValid'] == false && @['internalError'] == false)]</jsonpath>
           <to uri="workflow-cmd://complete-as-failed" />
           <to uri="workflow-cmd://anonymous-profile" />
        </when>
        <otherwise>
           <to uri="eventbus://c-m-d-validator-bus-in" />
        </otherwise>
     </choice>
  </route>

Tags will be created in the packet classifier stage. Depending on the tags, the packet will be transferred from the command validator stage to either the supervisor or operator stage. In order to introduce validation and check tags, packets will be moved accordingly. The availability of tags allows us to modify camel routes. (Mandatory)

      <route id="cmd-validator-->operator-validator new route">
      <from uri="eventbus://c-m-d-validator-new-bus-out" />
      <log message="cmd-validator-->operator-validator/supervisor-validator new route ${bodyAs(String)}" />
      <choice>
         <when>
            <jsonpath>$.[?(@['isValid'] == false &amp;&amp; @['internalError'] == true)]</jsonpath>
            <to uri="workflow-cmd://complete-as-failed" />
            <to uri="workflow-cmd://anonymous-profile" />
         </when>
         <when>
            <jsonpath>$.[?(@['isValid'] == true &amp;&amp; @['internalError'] == true)]</jsonpath>
            <to uri="workflow-cmd://mark-as-reprocess" />
         </when>
         <when>
            <jsonpath>$.[?(@['isValid'] == false &amp;&amp; @['internalError'] == false)]</jsonpath>
            <to uri="workflow-cmd://complete-as-failed" />
            <to uri="workflow-cmd://anonymous-profile" />
         </when>
         <when>
            <jsonpath suppressExceptions="true">$.[?(@['tags']['META_INFO-OPERATIONS_DATA-officerId'] != '' &amp;&amp; @['tags']['META_INFO-OPERATIONS_DATA-officerId'] != '--TAG_VALUE_NOT_AVAILABLE--')]</jsonpath>
            <to uri="eventbus://operator-validator-bus-in" />
         </when>
         <when>
            <jsonpath suppressExceptions="true">$.[?(@['tags']['META_INFO-OPERATIONS_DATA-supervisorId'] != '' &amp;&amp; @['tags']['META_INFO-OPERATIONS_DATA-supervisorId'] != '--TAG_VALUE_NOT_AVAILABLE--')]</jsonpath>
            <to uri="eventbus://supervisor-validator-bus-in" />
         </when>
         <otherwise>
            <to uri="workflow-cmd://complete-as-failed" />
            <to uri="workflow-cmd://anonymous-profile" />
         </otherwise>
      </choice>
   </route>

<route id="operator-validator-->supervisor-validator new route">
   <from uri="eventbus://operator-validator-new-bus-out" />
   <log message="operator-validator-->supervisor-validator/introducer-validator/demo-dedupe new route ${bodyAs(String)}" />
   <choice>
      <when>
         <jsonpath>$.[?(@['isValid'] == false &amp;&amp; @['internalError'] == true)]</jsonpath>
         <to uri="workflow-cmd://complete-as-failed" />
         <to uri="workflow-cmd://anonymous-profile" />
      </when>
      <when>
         <jsonpath>$.[?(@['isValid'] == true &amp;&amp; @['internalError'] == true)]</jsonpath>
         <to uri="workflow-cmd://mark-as-reprocess" />
      </when>
      <when>
         <jsonpath>$.[?(@['isValid'] == false &amp;&amp; @['internalError'] == false)]</jsonpath>
         <to uri="workflow-cmd://complete-as-failed" />
         <to uri="workflow-cmd://anonymous-profile" />
      </when>
      <when>
         <jsonpath suppressExceptions="true">$.[?(@['tags']['META_INFO-OPERATIONS_DATA-supervisorId'] != '' &amp;&amp; @['tags']['META_INFO-OPERATIONS_DATA-supervisorId'] != '--TAG_VALUE_NOT_AVAILABLE--')]</jsonpath>
         <to uri="eventbus://supervisor-validator-bus-in" />
      </when>
      <when>
         <jsonpath suppressExceptions="true">$.[?(@['tags']['AGE_GROUP'] == 'INFANT' || @['tags']['AGE_GROUP'] == 'MINOR' || @['tags']['INTRODUCER_AVAILABILITY'] == 'true')]</jsonpath>
         <to uri="eventbus://introducer-validator-bus-in" />
      </when>
      <otherwise>
         <to uri="eventbus://quality-classifier-bus-in" />
      </otherwise>
   </choice>
</route>

Instead of manual verification in section 1.1.5.5, it is now replaced with manual adjudication in section 1.2.0.1. Additionally, a new route has been specified from the manual adjudication stage to the UIN generator stage in the XML route. In cases where duplicates are identified, the manual adjudication stage is added to the route after the demo dedupe and bio dedupe processes. This change is mandatory.

1.1.5.5

<route id="manual-verification-->uin-generation new route">
        <from uri="eventbus:manual-verification-new-bus-out" />
        <log
            message="manual-verification-->uin-generation new route ${bodyAs(String)}" />
        <choice>
            <when>
                <simple>${bodyAs(String)} contains '"isValid":true'</simple>
                <to uri="eventbus:uin-generator-bus-in" />
            </when>
            <when>
                <simple>${bodyAs(String)} contains '"isValid":false' and ${bodyAs(String)} contains '"internalError":false'</simple>
                <to uri="eventbus:message-sender-bus-in" />
            </when>
            <when>
                <simple>${bodyAs(String)} contains '"internalError":true'</simple>
                <to uri="eventbus:retry-bus-in" />
            </when>
            <otherwise>
                <to uri="eventbus:error-bus-in" />
            </otherwise>
        </choice>
    </route>

1.2.0.1

<route id="manual-adjudication-->uin-generation new route">
      <from uri="eventbus://manual-adjudication-new-bus-out" />
      <log message="manual-adjudication-->uin-generation new route ${bodyAs(String)}" />
      <choice>
         <when>
            <jsonpath>$.[?(@['isValid'] == false && @['internalError'] == true)]</jsonpath>
            <to uri="workflow-cmd://complete-as-failed" />
            <to uri="workflow-cmd://anonymous-profile" />
         </when>
         <when>
            <jsonpath>$.[?(@['isValid'] == true && @['internalError'] == true)]</jsonpath>
            <to uri="workflow-cmd://mark-as-reprocess" />
         </when>
         <when>
            <jsonpath>$.[?(@['isValid'] == false && @['internalError'] == false)]</jsonpath>
            <to uri="workflow-cmd://complete-as-rejected" />
            <to uri="workflow-cmd://anonymous-profile" />
         </when>
         <otherwise>
            <to uri="eventbus://uin-generator-bus-in" />
         </otherwise>
      </choice>
   </route>

New route has been added from UIN generator stage to biometric-extraction stage. This stage fetches biometric extraction policy from PMS and sends to ID Repository (mandatory).

 <route id="uin-generation route-->biometric-extraction-stage new route">
   <from uri="eventbus://uin-generator-new-bus-out" />
   <log message="uin-generation-->biometric-extraction-stage route ${bodyAs(String)}" />
   <choice>
      <when>
         <jsonpath>$.[?(@['isValid'] == false &amp;&amp; @['internalError'] == true)]</jsonpath>
         <to uri="workflow-cmd://complete-as-failed" />
         <to uri="workflow-cmd://anonymous-profile" />
      </when>
      <when>
         <jsonpath>$.[?(@['isValid'] == true &amp;&amp; @['internalError'] == true)]</jsonpath>
         <to uri="workflow-cmd://mark-as-reprocess" />
      </when>
      <when>
         <jsonpath>$.[?(@['isValid'] == false &amp;&amp; @['internalError'] == false)]</jsonpath>
         <to uri="workflow-cmd://complete-as-failed" />
         <to uri="workflow-cmd://anonymous-profile" />
      </when>
      <otherwise>
         <to uri="eventbus://biometric-extraction-bus-in" />
         <to uri="workflow-cmd://anonymous-profile" />
      </otherwise>
   </choice>
</route>

New route has been added from biometric-extraction stage to Finalization stage. This stage publishes draft version to ID Repository DB (Mandatory).


<route id="biometric-extraction route-->finalization-stage new route">
   <from uri="eventbus://biometric-extraction-new-bus-out" />
   <log message="biometric-extraction-->finalization-stage route ${bodyAs(String)}" />
   <choice>
      <when>
         <jsonpath>$.[?(@['isValid'] == false &amp;&amp; @['internalError'] == true)]</jsonpath>
         <to uri="workflow-cmd://complete-as-failed" />
         <to uri="workflow-cmd://anonymous-profile" />
      </when>
      <when>
         <jsonpath>$.[?(@['isValid'] == true &amp;&amp; @['internalError'] == true)]</jsonpath>
         <to uri="workflow-cmd://mark-as-reprocess" />
      </when>
      <when>
         <jsonpath>$.[?(@['isValid'] == false &amp;&amp; @['internalError'] == false)]</jsonpath>
         <to uri="workflow-cmd://complete-as-failed" />
         <to uri="workflow-cmd://anonymous-profile" />
      </when>
      <otherwise>
         <to uri="eventbus://finalization-bus-in" />
      </otherwise>
   </choice>
</route>

New route has been added from Finalization stage to Printing stage. This stage creates Credential Request for printing systems (mandatory).

 <route id="finalization route-->printing-stage new route">
      <from uri="eventbus://finalization-new-bus-out" />
      <log message="finalization-->printing-stage route ${bodyAs(String)}" />
      <choice>
         <when>
            <jsonpath>$.[?(@['isValid'] == false &amp;&amp; @['internalError'] == true)]</jsonpath>
            <to uri="workflow-cmd://complete-as-failed" />
            <to uri="workflow-cmd://anonymous-profile" />
         </when>
         <when>
            <jsonpath>$.[?(@['isValid'] == true &amp;&amp; @['internalError'] == true)]</jsonpath>
            <to uri="workflow-cmd://mark-as-reprocess" />
         </when>
         <when>
            <jsonpath>$.[?(@['isValid'] == false &amp;&amp; @['internalError'] == false)]</jsonpath>
            <to uri="workflow-cmd://complete-as-failed" />
            <to uri="workflow-cmd://anonymous-profile" />
         </when>
         <otherwise>
            <to uri="eventbus://printing-bus-in" />
         </otherwise>
      </choice>
   </route>

Based on Tags related to quality score, the packets will move form quality classifier to workflow-cmd://pause-and-request-additional-info or demodedupe (optional).

1.1.5.5

<route id="quality-checker-->osi-validator new route">
        <from uri="eventbus:quality-checker-new-bus-out" />
        <log
            message="quality-checker-->osi-validator new route ${bodyAs(String)}" />
        <choice>
            <when>
                <simple>${bodyAs(String)} contains '"isValid":true'</simple>
                <to uri="eventbus:o-s-i-validator-bus-in" />
            </when>
            <when>
                <simple>${bodyAs(String)} contains '"isValid":false' and ${bodyAs(String)} contains '"internalError":false'</simple>
                <to uri="eventbus:message-sender-bus-in" />
            </when>
            <when>
                <simple>${bodyAs(String)} contains '"internalError":true'</simple>
                <to uri="eventbus:retry-bus-in" />
            </when>
            <otherwise>
                <to uri="eventbus:error-bus-in" />
            </otherwise>
        </choice>
    </route>

1.2.0.1


<route id="quality-classifier-->demo-dedupe new route">
      <from uri="eventbus://quality-classifier-new-bus-out" />
      <log message="quality-classifier-->demo-dedupe new route ${bodyAs(String)}" />
      <choice>
         <when>
            <jsonpath>$.[?(@['isValid'] == false && @['internalError'] == true)]</jsonpath>
            <to uri="workflow-cmd://complete-as-failed" />
            <to uri="workflow-cmd://anonymous-profile" />
         </when>
         <when>
            <jsonpath>$.[?(@['isValid'] == true && @['internalError'] == true)]</jsonpath>
            <to uri="workflow-cmd://mark-as-reprocess" />
         </when>
         <when>
            <jsonpath>$.[?(@['isValid'] == false && @['internalError'] == false)]</jsonpath>
            <to uri="workflow-cmd://complete-as-failed" />
            <to uri="workflow-cmd://anonymous-profile" />
         </when>
         <when>
            <jsonpath suppressExceptions="true">$.[?(@['tags']['BIOMETRIC_CORRECTION_FLOW_STATUS'] in ['FAILED'] || @['tags']['BIOMETRIC_CORRECTION_FLOW_STATUS'] in ['REJECTED'])]</jsonpath>
            <setProperty propertyName="ADDITIONAL_INFO_PROCESS"><constant>BIOMETRIC_CORRECTION</constant></setProperty>
            <setProperty propertyName="PAUSE_FOR"><constant>1296000</constant></setProperty>
            <to uri="workflow-cmd://pause-and-request-additional-info" />
         </when>
         <when>
            <jsonpath suppressExceptions="true">$.[?(@['tags']['Biometric_Quality-Iris'] in ['Average', 'Good','--Biometrics-Not-Available--'] && @['tags']['Biometric_Quality-Finger'] in ['Average', 'Good', '--Biometrics-Not-Available--'] && @['tags']['Biometric_Quality-Face'] in ['Average', 'Good', '--Biometrics-Not-Available--'])]</jsonpath>
            <to uri="eventbus://demo-dedupe-bus-in" />
         </when>
         <when>
            <jsonpath suppressExceptions="true">$.[?(@['tags']['Biometric_Quality-Iris'] in ['Poor'] || @['tags']['Biometric_Quality-Finger'] in ['Poor'] || @['tags']['Biometric_Quality-Face'] in ['Poor'])]</jsonpath>
            <setProperty propertyName="ADDITIONAL_INFO_PROCESS"><constant>BIOMETRIC_CORRECTION</constant></setProperty>
            <!-- PAUSE_FOR is in seconds -->
            <setProperty propertyName="PAUSE_FOR"><constant>1296000</constant></setProperty>
            <to uri="workflow-cmd://pause-and-request-additional-info" />
         </when>
         <otherwise>
            <to uri="workflow-cmd://complete-as-failed" />
            <to uri="workflow-cmd://anonymous-profile" />
         </otherwise>
      </choice>
   </route>

We can use JSON path also and update the conditions. If we want to update route based on isValid and internalError then follow the below syntax (optional)

<jsonpath>$.[?(@['isValid'] == true && @['internalError'] == true)]</jsonpath>

If we wish to use check condition based on address, then follow the below syntax (optional) ,

<jsonpath suppressExceptions="true">$.[?(@['messageBusAddress']['address'] == 'verification-bus-in')]</jsonpath>

If we wish to use the check condition based on Tags, then follow as below (optional):

<jsonpath suppressExceptions="true">$.[?(@['tags']['AGE_GROUP'] == 'INFANT' || @['tags']['AGE_GROUP'] == 'MINOR' || @['tags']['INTRODUCER_AVAILABILITY'] == 'true')]</jsonpath>

If we want to set the property in camel route, then follow the steps as below. .

This property is used for PAUSE and RESUME feature. We cant set application properties here (optional)

<setProperty propertyName="PAUSE_FOR"><constant>1296000</constant></setProperty>

As a part of the 1.2.0.1 update, if no biometric data is available, the system will proceed to the verification stage. This stage is only relevant in cases where the required biometrics are missing from the packet. The system will send the applicant's demographic and biometric information to the external Verification System (VS) through a queue and Datashare. Upon receiving the decision from the VS, the system will proceed accordingly and forward the packets. In case of rejection, the applicant will be notified (optional).

New route is specified from verification to UIN generator stage route.xml


 <route id="verification route-->uin-generator new route">
      <from uri="eventbus://verification-new-bus-out" />
      <log message="verification route-->uin-generator new route ${bodyAs(String)}" />
      <choice>
         <when>
            <jsonpath>$.[?(@['isValid'] == false &amp;&amp; @['internalError'] == true)]</jsonpath>
            <to uri="workflow-cmd://complete-as-failed" />
            <to uri="workflow-cmd://anonymous-profile" />
         </when>
         <when>
            <jsonpath>$.[?(@['isValid'] == true &amp;&amp; @['internalError'] == true)]</jsonpath>
            <to uri="workflow-cmd://mark-as-reprocess" />
         </when>
         <when>
            <jsonpath>$.[?(@['isValid'] == false &amp;&amp; @['internalError'] == false)]</jsonpath>
            <to uri="workflow-cmd://complete-as-failed" />
            <to uri="workflow-cmd://anonymous-profile" />
         </when>
         <otherwise>
            <to uri="eventbus://uin-generator-bus-in" />
         </otherwise>
      </choice>
   </route>

1.1.5.5

<route id="packet-reciever-->securezone-notification new route">
    <from uri="eventbus:packet-receiver-new-bus-out" />
    <log
        message="packet-reciever-->packet-uploader new ${bodyAs(String)}" />
    <choice>
        <when>
            <simple>${bodyAs(String)} contains '"isValid":true'</simple>
            <process ref="tokenGenerationProcessor"/>
            <setHeader headerName="CamelHttpMethod">
                <constant>POST</constant>
            </setHeader>
            <setHeader headerName="Content-Type">
                <constant>application/json</constant>
            </setHeader>
            <setHeader headerName="Cookie">
                <simple>${header.Cookie}</simple>
            </setHeader>
            <setBody>
                <simple>${bodyAs(String)}</simple>
            </setBody>
            <to uri="http://mz.ingress:30080/registrationprocessor/v1/securezone/notification" />
        </when>
        <when>
            <simple>${bodyAs(String)} contains '"internalError":true'</simple>
            <to uri="eventbus:retry-bus-in" />
        </when>
        <otherwise>
            <to uri="eventbus:error-bus-in" />
        </otherwise>
    </choice>
</route>

1.2.0.1

<route id="packet-receiver-->securezone-notification new route">
  <from uri="eventbus://packet-receiver-new-bus-out" />
  <log message="packet-receiver-->securezone-notification new ${bodyAs(String)}" />
  <choice>
     <when>
        <jsonpath>$.[?(@['isValid'] == false && @['internalError'] == true)]</jsonpath>
        <to uri="workflow-cmd://complete-as-failed" />
     </when>
     <when>
        <jsonpath>$.[?(@['isValid'] == true && @['internalError'] == true)]</jsonpath>
        <to uri="workflow-cmd://mark-as-reprocess" />
     </when>
     <when>
        <jsonpath>$.[?(@['isValid'] == false && @['internalError'] == false)]</jsonpath>
        <to uri="workflow-cmd://complete-as-failed" />
     </when>
     <otherwise>
        <to uri="eventbus://securezone-notification-bus-in" />
     </otherwise>
  </choice>

~~~

Update Identity Mapping file in Configuration

As part of the migration process, we will be updating the latest version of the identity-mapping.json file (1.2.0.1) from the mosip-config. This update involves modifying the mapping values to align with the id schema of the respective country.

To guide you through the updating process, please refer to the following information:

In the provided sample identity-mapping.json, the focus will be solely on modifying the mapper values to match the id schema of the country.

{
   "identity":{
      "IDSchemaVersion":{
         "value":"IDSchemaVersion"
      },
      "name":{
         "value":"fullName"
      },
      "gender":{
         "value":"gender"
      },
      "dob":{
         "value":"dateOfBirth"
      },
      "age":{
         "value":"age"
      },
      "introducerRID":{
         "value":"introducerRID"
      },
      "introducerUIN":{
         "value":"introducerUIN"
      },
      "introducerVID":{
         "value":"introducerVID"
      },
      "introducerName":{
         "value":"introducerName"
      },
      "phone":{
         "value":"phone"
      },
      "phoneNumber":{
         "value":"phone"
      },
      "email":{
         "value":"email"
      },
      "emailId":{
         "value":"email"
      },
      "uin":{
         "value":"UIN"
      },
      "vid":{
         "value":"VID"
      },
      "individualBiometrics":{
         "value":"individualBiometrics"
      },
      "introducerBiometrics":{
         "value":"introducerBiometrics"
      },
      "individualAuthBiometrics":{
         "value":"individualAuthBiometrics"
      },
      "officerBiometricFileName":{
         "value":"officerBiometricFileName"
      },
      "supervisorBiometricFileName":{
         "value":"supervisorBiometricFileName"
      },
      "residenceStatus":{
         "value":"residenceStatus"
      },
      "preferredLanguage":{
         "value":"preferredLang"
      },
      "locationHierarchyForProfiling":{
         "value":"zone,postalCode"
      },
      "addressLine1":{
         "value":"addressLine1"
      },
      "addressLine2":{
         "value":"addressLine2"
      },
      "addressLine3":{
         "value":"addressLine3"
      },
      "location1":{
         "value":"city"
      },
      "location2":{
         "value":"region"
      },
      "location3":{
         "value":"province"
      },
      "postalCode":{
         "value":"postalCode"
      },
      "location4":{
         "value":"zone"
      },
      "fullAddress":{
         "value":"addressLine1,addressLine2,addressLine3,city,region,province,postalCode"
      },
      "bestTwoFingers":{
         "value":"bestTwoFingers"
      },
      "birthdate":{
         "value":"dateOfBirth"
      },
      "picture":{
         "value":"face"
      },
      "phone_number":{
         "value":"phone"
      },
      "address":{
         "value":"addressLine1,addressLine2,addressLine3,city,region,province,postalCode"
      },
      "individual_id":{
         "value":"individual_id"
      },
      "street_address":{
         "value":"addressLine1,addressLine2,addressLine3"
      },
      "locality":{
         "value":"city"
      },
      "region":{
         "value":"region"
      },
      "postal_code":{
         "value":"postalCode"
      },
      "country":{
         "value":"province"
      }
   },
   "metaInfo":{
      "value":"metaInfo"
   },
   "audits":{
      "value":"audits"
   },
   "documents":{
      "poa":{
         "value":"proofOfAddress"
      },
      "poi":{
         "value":"proofOfIdentity"
      },
      "por":{
         "value":"proofOfRelationship"
      },
      "pob":{
         "value":"proofOfDateOfBirth"
      },
      "poe":{
         "value":"proofOfException"
      }
   },
   "attributeUpdateCountLimit":{
      "fullName":2,
      "gender":1,
      "dob":1,
      "age":1
   }
}

According to the identity-mapping.json file mentioned above, we need to verify if a value is present in the country's ID schema. If the value exists, we can retain it as is. Otherwise, we should update the value in the identity-mapping.json file.

To illustrate, let's consider a few examples:

The fullName field is not included in the ID schema. Instead, it consists of firstName, middleName, and lastName. Therefore, we should replace the fullName with firstName, middleName, and lastName in the identity-mapping.json file.
Similarly, the introducerUIN field is not present in the schema, but instead, it has introducerCredentialID. Hence, we need to substitute introducerUIN with introducerCredentialID in the mapping.json file.
Additionally, since addressLine1 is not part of the schema, we should replace its value with presentAddressLine1, which is present.
Lastly, the phone field is not found in the schema, but mobileno is present. Thus, we need to replace phone with mobileno in the mapping.json file.
Our task is to compare each field value in the identity-mapping.json file with the ID schema and update it with the appropriate value based on the schema.

Sample Country’s ID schema

{
   "$schema":"http://json-schema.org/draft-07/schema#",
   "description":"string",
   "additionalProperties":false,
   "title":"string",
   "type":"object",
   "definitions":{
      "simpleType":{
         "uniqueItems":true,
         "additionalItems":false,
         "type":"array",
         "items":{
            "additionalProperties":false,
            "type":"object",
            "required":[
               "language",
               "value"
            ],
            "properties":{
               "language":{
                  "type":"string"
               },
               "value":{
                  "type":"string"
               }
            }
         }
      },
      "documentType":{
         "additionalProperties":false,
         "type":"object",
         "required":[
            "format",
            "type",
            "value"
         ],
         "properties":{
            "refNumber":{
               "type":"string"
            },
            "format":{
               "type":"string"
            },
            "type":{
               "type":"string"
            },
            "value":{
               "type":"string"
            }
         }
      },
      "biometricsType":{
         "additionalProperties":false,
         "type":"object",
         "properties":{
            "format":{
               "type":"string"
            },
            "version":{
               "type":"number",
               "minimum":0
            },
            "value":{
               "type":"string"
            }
         }
      }
   },
   "properties":{
      "identity":{
         "additionalProperties":false,
         "type":"object",
         "required":[
            "IDSchemaVersion",
            "firstName",
            "dateOfBirth",
            "pobCountry",
            "pobProvince",
            "pobCity",
            "gender",
            "residenceStatus",
            "bloodType",
            "permanentCountry",
            "permanentAddressLine1",
            "addressCopy",
            "presentCountry",
            "presentAddressLine1",
            "modeOfClaim",
            "proofOfAddress",
            "individualBiometrics"
         ],
         "properties":{
            "presentProvince":{
               "bioAttributes":[
                  
               ],
               "validators":[
                  {
                     "langCode":null,
                     "validator":"^(?=.{0,50}$).*",
                     "arguments":[
                        
                     ],
                     "type":"regex"
                  }
               ],
               "fieldCategory":"pvt",
               "format":"none",
               "fieldType":"default",
               "$ref":"#/definitions/simpleType"
            },
            "pobCountry":{
               "bioAttributes":[
                  
               ],
               "validators":[
                  {
                     "langCode":null,
                     "validator":"^(?=.{0,50}$).*",
                     "arguments":[
                        
                     ],
                     "type":"regex"
                  }
               ],
               "fieldCategory":"pvt",
               "format":"none",
               "fieldType":"default",
               "$ref":"#/definitions/simpleType"
            },
            "pobProvince":{
               "bioAttributes":[
                  
               ],
               "validators":[
                  {
                     "langCode":null,
                     "validator":"^(?=.{0,50}$).*",
                     "arguments":[
                        
                     ],
                     "type":"regex"
                  }
               ],
               "fieldCategory":"pvt",
               "format":"none",
               "fieldType":"default",
               "$ref":"#/definitions/simpleType"
            },
            "permanentBarangay":{
               "bioAttributes":[
                  
               ],
               "fieldCategory":"pvt",
               "format":"none",
               "fieldType":"default",
               "$ref":"#/definitions/simpleType"
            },
            "mobileno":{
               "bioAttributes":[
                  
               ],
               "fieldCategory":"pvt",
               "format":"none",
               "type":"string",
               "fieldType":"default"
            },
            "suffix":{
               "bioAttributes":[
                  
               ],
               "validators":[
                  {
                     "langCode":null,
                     "validator":"^(?=.{1,3}$).*",
                     "arguments":[
                        
                     ],
                     "type":"regex"
                  }
               ],
               "fieldCategory":"pvt",
               "format":"none",
               "fieldType":"default",
               "$ref":"#/definitions/simpleType"
            },
            "proofOfDateOfBirth":{
               "bioAttributes":[
                  
               ],
               "fieldCategory":"pvt",
               "format":"none",
               "fieldType":"default",
               "$ref":"#/definitions/documentType"
            },
            "introducerSuffix":{
               "bioAttributes":[
                  
               ],
               "validators":[
                  {
                     "langCode":null,
                     "validator":"^(?=.{1,3}$).*",
                     "arguments":[
                        
                     ],
                     "type":"regex"
                  }
               ],
               "fieldCategory":"evidence",
               "format":"none",
               "fieldType":"default",
               "$ref":"#/definitions/simpleType"
            },
            "introducerMiddleName":{
               "bioAttributes":[
                  
               ],
               "validators":[
                  {
                     "langCode":null,
                     "validator":"(?=(?:^\\w|Ñ|Ü|ü|ñ))([A-Z0-9a-zñÑ -.‘_ Üü]+)(?<=[^ ])$",
                     "arguments":[
                        
                     ],
                     "type":"regex"
                  }
               ],
               "fieldCategory":"evidence",
               "format":"none",
               "fieldType":"default",
               "$ref":"#/definitions/simpleType"
            },
            "presentCity":{
               "bioAttributes":[
                  
               ],
               "validators":[
                  {
                     "langCode":null,
                     "validator":"^(?=.{0,50}$).*",
                     "arguments":[
                        
                     ],
                     "type":"regex"
                  }
               ],
               "fieldCategory":"pvt",
               "format":"none",
               "fieldType":"default",
               "$ref":"#/definitions/simpleType"
            },
            "firstName":{
               "bioAttributes":[
                  
               ],
               "validators":[
                  {
                     "langCode":null,
                     "validator":"(?=(?:^\\w|Ñ|Ü|ü|ñ))([A-Z0-9a-zñÑ -.‘_ Üü]+)(?<=[^ ])$",
                     "arguments":[
                        
                     ],
                     "type":"regex"
                  }
               ],
               "fieldCategory":"pvt",
               "format":"none",
               "fieldType":"default",
               "$ref":"#/definitions/simpleType"
            },
            "IDSchemaVersion":{
               "bioAttributes":[
                  
               ],
               "fieldCategory":"none",
               "format":"none",
               "type":"number",
               "fieldType":"default",
               "minimum":0
            },
            "proofOfException":{
               "bioAttributes":[
                  
               ],
               "fieldCategory":"evidence",
               "format":"none",
               "fieldType":"default",
               "$ref":"#/definitions/documentType"
            },
            "registrationType":{
               "bioAttributes":[
                  
               ],
               "fieldCategory":"pvt",
               "format":"none",
               "fieldType":"dynamic",
               "$ref":"#/definitions/simpleType"
            },
            "permanentCountry":{
               "bioAttributes":[
                  
               ],
               "validators":[
                  {
                     "langCode":null,
                     "validator":"^(?=.{0,50}$).*",
                     "arguments":[
                        
                     ],
                     "type":"regex"
                  }
               ],
               "fieldCategory":"pvt",
               "format":"none",
               "fieldType":"default",
               "$ref":"#/definitions/simpleType"
            },
            "presentCountry":{
               "bioAttributes":[
                  
               ],
               "validators":[
                  {
                     "langCode":null,
                     "validator":"^(?=.{0,50}$).*",
                     "arguments":[
                        
                     ],
                     "type":"regex"
                  }
               ],
               "fieldCategory":"pvt",
               "format":"none",
               "fieldType":"default",
               "$ref":"#/definitions/simpleType"
            },
            "permanentProvince":{
               "bioAttributes":[
                  
               ],
               "validators":[
                  {
                     "langCode":null,
                     "validator":"^(?=.{0,50}$).*",
                     "arguments":[
                        
                     ],
                     "type":"regex"
                  }
               ],
               "fieldCategory":"pvt",
               "format":"none",
               "fieldType":"default",
               "$ref":"#/definitions/simpleType"
            },
            "proofOfRelationship":{
               "bioAttributes":[
                  
               ],
               "fieldCategory":"pvt",
               "format":"none",
               "fieldType":"default",
               "$ref":"#/definitions/documentType"
            },
            "UIN":{
               "bioAttributes":[
                  
               ],
               "fieldCategory":"none",
               "format":"none",
               "type":"string",
               "fieldType":"default"
            },
            "maritalStatus":{
               "bioAttributes":[
                  
               ],
               "fieldCategory":"pvt",
               "format":"none",
               "fieldType":"dynamic",
               "$ref":"#/definitions/simpleType"
            },
            "presentAddressLine1":{
               "bioAttributes":[
                  
               ],
               "validators":[
                  {
                     "langCode":null,
                     "validator":"^(?=.{0,255}$).*",
                     "arguments":[
                        
                     ],
                     "type":"regex"
                  }
               ],
               "fieldCategory":"pvt",
               "format":"none",
               "fieldType":"default",
               "$ref":"#/definitions/simpleType"
            },
            "presentZipcode":{
               "bioAttributes":[
                  
               ],
               "fieldCategory":"pvt",
               "format":"none",
               "fieldType":"default",
               "$ref":"#/definitions/simpleType"
            },
            "lastName":{
               "bioAttributes":[
                  
               ],
               "validators":[
                  {
                     "langCode":null,
                     "validator":"(?=(?:^\\w|Ñ|Ü|ü|ñ))([A-Z0-9a-zñÑ -.‘_ Üü]+)(?<=[^ ])$",
                     "arguments":[
                        
                     ],
                     "type":"regex"
                  }
               ],
               "fieldCategory":"pvt",
               "format":"none",
               "fieldType":"default",
               "$ref":"#/definitions/simpleType"
            },
            "presentAddressLine2":{
               "bioAttributes":[
                  
               ],
               "validators":[
                  {
                     "langCode":null,
                     "validator":"^(?=.{0,255}$).*",
                     "arguments":[
                        
                     ],
                     "type":"regex"
                  }
               ],
               "fieldCategory":"pvt",
               "format":"none",
               "fieldType":"default",
               "$ref":"#/definitions/simpleType"
            },
            "presentAddressLine3":{
               "bioAttributes":[
                  
               ],
               "validators":[
                  {
                     "langCode":null,
                     "validator":"^(?=.{0,255}$).*",
                     "arguments":[
                        
                     ],
                     "type":"regex"
                  }
               ],
               "fieldCategory":"pvt",
               "format":"none",
               "fieldType":"default",
               "$ref":"#/definitions/simpleType"
            },
            "guardianFirstName":{
               "bioAttributes":[
                  
               ],
               "validators":[
                  {
                     "langCode":null,
                     "validator":"(?=(?:^\\w|Ñ|Ü|ü|ñ))([A-Z0-9a-zñÑ -.‘_ Üü]+)(?<=[^ ])$",
                     "arguments":[
                        
                     ],
                     "type":"regex"
                  }
               ],
               "fieldCategory":"evidence",
               "format":"none",
               "fieldType":"default",
               "$ref":"#/definitions/simpleType"
            },
            "presentAddressLine4":{
               "bioAttributes":[
                  
               ],
               "validators":[
                  {
                     "langCode":null,
                     "validator":"^(?=.{0,255}$).*",
                     "arguments":[
                        
                     ],
                     "type":"regex"
                  }
               ],
               "fieldCategory":"pvt",
               "format":"none",
               "fieldType":"default",
               "$ref":"#/definitions/simpleType"
            },
            "proofOfAddress":{
               "bioAttributes":[
                  
               ],
               "fieldCategory":"pvt",
               "format":"none",
               "fieldType":"default",
               "$ref":"#/definitions/documentType"
            },
            "gender":{
               "bioAttributes":[
                  
               ],
               "fieldCategory":"pvt",
               "format":"",
               "fieldType":"dynamic",
               "$ref":"#/definitions/simpleType"
            },
            "modeOfClaim":{
               "bioAttributes":[
                  
               ],
               "fieldCategory":"pvt",
               "format":"none",
               "fieldType":"dynamic",
               "$ref":"#/definitions/simpleType"
            },
            "proofOfConsent":{
               "bioAttributes":[
                  
               ],
               "fieldCategory":"pvt",
               "format":"none",
               "fieldType":"default",
               "$ref":"#/definitions/documentType"
            },
            "guardianSuffix":{
               "bioAttributes":[
                  
               ],
               "validators":[
                  {
                     "langCode":null,
                     "validator":"^(?=.{1,3}$).*",
                     "arguments":[
                        
                     ],
                     "type":"regex"
                  }
               ],
               "fieldCategory":"evidence",
               "format":"none",
               "fieldType":"default",
               "$ref":"#/definitions/simpleType"
            },
            "bloodType":{
               "bioAttributes":[
                  
               ],
               "fieldCategory":"pvt",
               "format":"",
               "fieldType":"dynamic",
               "$ref":"#/definitions/simpleType"
            },
            "introducerFirstName":{
               "bioAttributes":[
                  
               ],
               "validators":[
                  {
                     "langCode":null,
                     "validator":"(?=(?:^\\w|Ñ|Ü|ü|ñ))([A-Z0-9a-zñÑ -.‘_ Üü]+)(?<=[^ ])$",
                     "arguments":[
                        
                     ],
                     "type":"regex"
                  }
               ],
               "fieldCategory":"evidence",
               "format":"none",
               "fieldType":"default",
               "$ref":"#/definitions/simpleType"
            },
            "guardianLastName":{
               "bioAttributes":[
                  
               ],
               "validators":[
                  {
                     "langCode":null,
                     "validator":"(?=(?:^\\w|Ñ|Ü|ü|ñ))([A-Z0-9a-zñÑ -.‘_ Üü]+)(?<=[^ ])$",
                     "arguments":[
                        
                     ],
                     "type":"regex"
                  }
               ],
               "fieldCategory":"evidence",
               "format":"none",
               "fieldType":"default",
               "$ref":"#/definitions/simpleType"
            },
            "individualBiometrics":{
               "bioAttributes":[
                  "leftEye",
                  "rightEye",
                  "rightIndex",
                  "rightLittle",
                  "rightRing",
                  "rightMiddle",
                  "leftIndex",
                  "leftLittle",
                  "leftRing",
                  "leftMiddle",
                  "leftThumb",
                  "rightThumb",
                  "face"
               ],
               "fieldCategory":"pvt",
               "format":"none",
               "fieldType":"default",
               "$ref":"#/definitions/biometricsType"
            },
            "presentBarangay":{
               "bioAttributes":[
                  
               ],
               "fieldCategory":"pvt",
               "format":"none",
               "fieldType":"default",
               "$ref":"#/definitions/simpleType"
            },
            "residenceStatus":{
               "bioAttributes":[
                  
               ],
               "fieldCategory":"kyc",
               "format":"none",
               "fieldType":"dynamic",
               "$ref":"#/definitions/simpleType"
            },
            "email":{
               "bioAttributes":[
                  
               ],
               "validators":[
                  {
                     "langCode":null,
                     "validator":"^[A-Za-z0-9_\\-]+(\\.[A-Za-z0-9_]+)*@[A-Za-z0-9_-]+(\\.[A-Za-z0-9_]+)*(\\.[a-zA-Z]{2,})$",
                     "arguments":[
                        
                     ],
                     "type":"regex"
                  }
               ],
               "fieldCategory":"pvt",
               "format":"none",
               "type":"string",
               "fieldType":"default"
            },
            "guardianMiddleName":{
               "bioAttributes":[
                  
               ],
               "validators":[
                  {
                     "langCode":null,
                     "validator":"(?=(?:^\\w|Ñ|Ü|ü|ñ))([A-Z0-9a-zñÑ -.‘_ Üü]+)(?<=[^ ])$",
                     "arguments":[
                        
                     ],
                     "type":"regex"
                  }
               ],
               "fieldCategory":"evidence",
               "format":"none",
               "fieldType":"default",
               "$ref":"#/definitions/simpleType"
            },
            "parentOrGuardianRID":{
               "bioAttributes":[
                  
               ],
               "fieldCategory":"evidence",
               "format":"none",
               "type":"string",
               "fieldType":"default"
            },
            "permanentZipcode":{
               "bioAttributes":[
                  
               ],
               "fieldCategory":"pvt",
               "format":"none",
               "fieldType":"default",
               "$ref":"#/definitions/simpleType"
            },
            "pobCity":{
               "bioAttributes":[
                  
               ],
               "validators":[
                  {
                     "langCode":null,
                     "validator":"^(?=.{0,50}$).*",
                     "arguments":[
                        
                     ],
                     "type":"regex"
                  }
               ],
               "fieldCategory":"pvt",
               "format":"none",
               "fieldType":"default",
               "$ref":"#/definitions/simpleType"
            },
            "addressCopy":{
               "bioAttributes":[
                  
               ],
               "validators":[
                  {
                     "langCode":null,
                     "validator":"^[YN]$",
                     "arguments":[
                        
                     ],
                     "type":"regex"
                  }
               ],
               "fieldCategory":"pvt",
               "format":"none",
               "type":"string",
               "fieldType":"default"
            },
            "dateOfBirth":{
               "bioAttributes":[
                  
               ],
               "validators":[
                  {
                     "langCode":null,
                     "validator":"^(1869|18[7-9][0-9]|19[0-9][0-9]|20[0-9][0-9])/([0][1-9]|1[0-2])/([0][1-9]|[1-2][0-9]|3[01])$",
                     "arguments":[
                        
                     ],
                     "type":"regex"
                  }
               ],
               "fieldCategory":"pvt",
               "format":"none",
               "type":"string",
               "fieldType":"default"
            },
            "individualAuthBiometrics":{
               "bioAttributes":[
                  "leftEye",
                  "rightEye",
                  "rightIndex",
                  "rightLittle",
                  "rightRing",
                  "rightMiddle",
                  "leftIndex",
                  "leftLittle",
                  "leftRing",
                  "leftMiddle",
                  "leftThumb",
                  "rightThumb",
                  "face"
               ],
               "fieldCategory":"pvt",
               "format":"none",
               "fieldType":"default",
               "$ref":"#/definitions/biometricsType"
            },
            "proofOfIdentity":{
               "bioAttributes":[
                  
               ],
               "fieldCategory":"pvt",
               "format":"none",
               "fieldType":"default",
               "$ref":"#/definitions/documentType"
            },
            "introducerCredentialID":{
               "bioAttributes":[
                  
               ],
               "fieldCategory":"evidence",
               "format":"none",
               "type":"string",
               "fieldType":"default"
            },
            "permanentAddressLine1":{
               "bioAttributes":[
                  
               ],
               "validators":[
                  {
                     "langCode":null,
                     "validator":"^(?=.{0,255}$).*",
                     "arguments":[
                        
                     ],
                     "type":"regex"
                  }
               ],
               "fieldCategory":"pvt",
               "format":"none",
               "fieldType":"default",
               "$ref":"#/definitions/simpleType"
            },
            "guardianBiometrics":{
               "bioAttributes":[
                  "leftEye",
                  "rightEye",
                  "rightIndex",
                  "rightLittle",
                  "rightRing",
                  "rightMiddle",
                  "leftIndex",
                  "leftLittle",
                  "leftRing",
                  "leftMiddle",
                  "leftThumb",
                  "rightThumb",
                  "face"
               ],
               "fieldCategory":"pvt",
               "format":"none",
               "fieldType":"default",
               "$ref":"#/definitions/biometricsType"
            },
            "middleName":{
               "bioAttributes":[
                  
               ],
               "validators":[
                  {
                     "langCode":null,
                     "validator":"(?=(?:^\\w|Ñ|Ü|ü|ñ))([A-Z0-9a-zñÑ -.‘_ Üü]+)(?<=[^ ])$",
                     "arguments":[
                        
                     ],
                     "type":"regex"
                  }
               ],
               "fieldCategory":"pvt",
               "format":"none",
               "fieldType":"default",
               "$ref":"#/definitions/simpleType"
            },
            "permanentCity":{
               "bioAttributes":[
                  
               ],
               "validators":[
                  {
                     "langCode":null,
                     "validator":"^(?=.{0,50}$).*",
                     "arguments":[
                        
                     ],
                     "type":"regex"
                  }
               ],
               "fieldCategory":"pvt",
               "format":"none",
               "fieldType":"default",
               "$ref":"#/definitions/simpleType"
            },
            "permanentAddressLine2":{
               "bioAttributes":[
                  
               ],
               "validators":[
                  {
                     "langCode":null,
                     "validator":"^(?=.{0,255}$).*",
                     "arguments":[
                        
                     ],
                     "type":"regex"
                  }
               ],
               "fieldCategory":"pvt",
               "format":"none",
               "fieldType":"default",
               "$ref":"#/definitions/simpleType"
            },
            "permanentAddressLine3":{
               "bioAttributes":[
                  
               ],
               "validators":[
                  {
                     "langCode":null,
                     "validator":"^(?=.{0,255}$).*",
                     "arguments":[
                        
                     ],
                     "type":"regex"
                  }
               ],
               "fieldCategory":"pvt",
               "format":"none",
               "fieldType":"default",
               "$ref":"#/definitions/simpleType"
            },
            "introducerLastName":{
               "bioAttributes":[
                  
               ],
               "validators":[
                  {
                     "langCode":null,
                     "validator":"(?=(?:^\\w|Ñ|Ü|ü|ñ))([A-Z0-9a-zñÑ -.‘_ Üü]+)(?<=[^ ])$",
                     "arguments":[
                        
                     ],
                     "type":"regex"
                  }
               ],
               "fieldCategory":"evidence",
               "format":"none",
               "fieldType":"default",
               "$ref":"#/definitions/simpleType"
            },
            "permanentAddressLine4":{
               "bioAttributes":[
                  
               ],
               "validators":[
                  {
                     "langCode":null,
                     "validator":"^(?=.{0,255}$).*",
                     "arguments":[
                        
                     ],
                     "type":"regex"
                  }
               ],
               "fieldCategory":"pvt",
               "format":"none",
               "fieldType":"default",
               "$ref":"#/definitions/simpleType"
            }
         }
      }
   }
}

Additional Information

Introduction

Mock ABIS (Automated Biometric Identification System)

Mock SDK (Software Development Kit)

Mock SMTP (Simple Mail Transfer Protocol)

Handling Duplicate Entries

Issue

Adapting Changes in Administration Roles

Identifying Applicant Type

Changes in Camel Route

1.1.5.5

1.2.0.1

1.1.5.5

1.2.0.1

1.1.5.5

1.2.0.1

Changes in Role Management based on Client IDs

Partner Management Services

Service account roles for Partner-Management-Services

Client Scopes for Partner-Management-Services:

Admin-Services

Pre-registration

ID Authentication

Digital-card-service

Print

ID Repository

Resident Services

Compliance-Tool-Kit

Handling Case Insensitive Duplicated User Details

How can we identify case-insensitive duplicates in the user_id column of the user_details table?

How to deactivate/delete the case insensitive duplicates?

Managing Unequal Certificates

Check through SQL commands

Basic Troubleshooting

New Datashare Properties

Handling Non-Recoverable Packets

Partners' Certificate Expired

Handling Partner Organization Name Mismatch Issue

Registration Client Upgrade

Version upgrade

Backups and rollbacks

1.1.4.* to 1.1.5.5 / 1.1.4.* to 1.2.0.*

1.1.5.5 to 1.2.0.*

Guide to Reprocess Packets Manually

Additional Information

Introduction

Mock ABIS (Automated Biometric Identification System)

Mock SDK (Software Development Kit)

Mock SMTP (Simple Mail Transfer Protocol)

Changes in Role Management based on Client IDs

Partner Management Services

Service account roles for Partner-Management-Services

Client Scopes for Partner-Management-Services:

Admin-Services

Pre-registration

ID Authentication

Digital-card-service

Print

ID Repository

Resident Services

Compliance-Tool-Kit

Managing Unequal Certificates

Check through SQL commands

Basic Troubleshooting

New Datashare Properties

Handling Partner Organization Name Mismatch Issue

Handling Non-Recoverable Packets

Handling Duplicate Entries

Issue

Pre-Registration UI Upgrade

How to define and publish UI specifications?

Changes in UI Specifications

UI Specifications of 1.1.5 and 1.2.0

1.1.5

1.2.0

Partners' Certificate Expired

Guide to Reprocess Packets Manually

Registration Client Upgrade

Version upgrade

Backups and rollbacks

How can we identify case-insensitive duplicates in the `user_id` column of the `user_details` table?

How can we identify case-insensitive duplicates in the `user_id` column of the `user_details` table?