Latest Release

Version: 1.2.0.1 Beta 4

• Name: Fourth patch on Asymmetric Amoeba

• Date: 12th January, 2024

• Release Notes

Version: 1.2.0.1 Beta 3

• Name: Third patch on Asymmetric Amoeba

• Date: 14th April, 2023

• Release Notes

Older Releases

Version: 1.2.0.1 Beta 2

• Name: Second patch on Asymmetric Amoeba

• Date: 8th January, 2023

• Release Notes

Version: 1.2.0.1 Beta 1

• Name: First patch on Asymmetric Amoeba

• Date: 14th October, 2022

• Release Notes

Version: 1.2.0

• Name: Asymmetric Amoeba

• Date: 14th February, 2022

• Recommended Patch Version: 1.2.0.1 Beta 2

• Release Notes

Refer to Older Releases.

Release Name: Android Registration Client DP1

Release version: vDP1

Support: Developer Preview Release1

Release Date: 7th Nov, 2023

Overview

The Android Registration Client is a tablet application that serves as a portable version of the existing desktop Registration Client. It has been developed to support accessibility on all Android devices. The existence of Android Registration Client came about in order to meet the mobility requirements of countries adopting MOSIP.

The primary objective of the tablet version is to facilitate the registration process for residents, specifically those who are unable to physically visit registration centres and also serve remote locations where setting up Registration centres is not feasible. To address this challenge, the Android Registration Client was created, enabling Operators/ Supervisors to easily reach the remote areas and maximise resident registrations across the country.

The key features provided on the Android Registration Client are:

• Operator/Supervisor Login (offline and online)

• Multi-language support

• Auto-Sync/ manual sync

• New Registrations

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

1. 1.1.5.x

2. LTS 1.2.0 and above

Repository Released

Dependencies:

1. mosipdev/kernel-syncdata-service:1.1.5.3- This image contains temporary fix for encryption methodology for Android Registration Client. In the next release, there will be some decryption login changes and this will no longer be needed.

Build and Deploy

To access the build and read through the deployment instructions, refer to the Deployment Guide.

Configurations

For details related to resident portal configurations, refer to the Configuration Guide.

Video

To have a quick glance at the features, refer the video!

Scope

The scope of testing is to verify fitment to the specification from the perspective of:

• Functionality

• Deployability

• Configurability

• Customizability

Verification is performed not only from the end-user perspective but also from the System Integrator (SI) point of view. Hence, the configurability and extensibility of the software are also assessed. This ensures the readiness of software for use in multiple countries. Since MOSIP is an “API First” product platform, the verification scope required comprehensive automation testing for all the MOSIP APIs. An automated Test Rig is created for the same.

Test approach

Persona based approach has been adopted to perform the IV&V(Independent Verification and Validation) by simulating the test scenarios that resemble a real-time implementation.

A Persona is a fictional character/ user profile created to represent a user type that might use a product/ or a service in a similar way. Persona-based testing is a software testing technique that puts software testers in the customer's shoes, assesses their needs from the software and thereby determines use cases/ scenarios that the customers will execute. The persona's needs may be addressed through any of the following:

• Functionality

• Deployability

• Configurability

• Customizability

The verification methods may differ based on how the need was addressed.

For regression check, MOSIP Test Rig, an automation testing suite is indigenously designed and developed for supporting persona-based testing. MOSIP Test Rig covers end-to-end test execution and reporting. The end-to-end functional test scenarios are written starting from pre-registration, to the creation of the packet in the registration centre, processing the packet through the registration processor, generating UIN and authenticating identity using IDA through various permutations and combinations of cases being covered. MOSIP Test Rig will be an open-source artifact which can also be enhanced and used by countries to validate the SI deliveries before going live. Persona classes include both negative and positive personas. Negative persona classes include users like Bribed Registration Office, Malicious Insider etc. The needs of positive persona classes must be met, whereas the needs of negative persona classes must be effectively restricted by the software.

Verified configuration

Verification is performed on the configuration mentioned below:

• Default configuration- with 1 Language (English)

Main feature tested

• Deployment testing as per the Upgrade Runbook.

• Reprocess the packets (which are generated and paused in 1.1.5.x at various stages) after the upgrade.

• Reg.Client 1.1.5.5 and Reg.Client 1.2.0.1

• Reg.Client upgraded from 1.1.5.5 to 1.2.0.1

External API verification results for all modules

The below section provides details on API test metrics for all modules by executing MOSIP functional automation Framework. All external API test executions were performed at module-level isolation. Each endpoint is tested with the test data and expectations of each test data are mapped to assert the test case.

Test Rate: 83.88 with Pass Rate: 76.25%

Here is the detailed breakdown of metrics:

Functional and automation test rig code base branch which is used for the metrics are:

https://github.com/mosip/mosip-functional-tests/tree/release-1.2.0.1

https://github.com/mosip/mosip-automation-tests/tree/release-1.2.0.1

Testing End-to-End flow(s)

End-to-end flows are a set of stateful test cases that expects the results across multiple modules. The test does not cover the intermediary stages, rather concentrates on the end result for a given data. The test covers both negative scenarios and positive scenarios with real world scenarios. Below are the end-to-end scenarios test metrics by executing MOSIP Automation Framework.

Test Rate: 97.33% with Pass Rate: 56%

Detailed Test metrics

Below are the detailed test metrics by performing manual/ automation testing. The project metrics are derived from Defect density, Test coverage, Test execution coverage, test tracking and efficiency.

The various metrics that assist in test tracking and efficiency are as follows:

• Passed Test Cases Coverage: It measures the percentage of passed test cases. (Number of passed tests / Total number of tests executed) x 100

• Failed Test Case Coverage: It measures the percentage of all the failed test cases. (Number of failed tests / Total number of test cases executed) x 100

Sonar Report

Overview

Release Name: 1.2.0.1 Beta4

Release Version: 1.2.0.1-B4

Support: Developer Release

Release Date: 12th January, 2024

The MOSIP 1.2.0.1 Beta4 release marks an upgrade from version 1.1.5.x to 1.2.0.1. This release primarily focuses on the migration of all services/modules to V3 architecture. Additionally, it includes important bug fixes, enhancements to security, and improvements in performance.

To know more about the upgrades, refer Upgrade Runbook.

Repository Released

Documentation

• For complete documentation, refer to 1.2.0 LTS documentation.

• To read though the Test Reports, refer here.

• Deployment documentation and scripts have been enhanced and are compliant with V3 architecture.

• Developer documentation has been included for all repositories to facilitate the setup process on developers' local systems.

Overview

Release Name: 1.2.0.1 Beta3

Release Version: 1.2.0.1-B3

Support: Developer Release

Release Date: 14th April 2023

The 1.2.0.1 Beta3 release of MOSIP is a patch release on top of the . This patch release mainly contains all the fixes for bugs, security and performance given as part of the and additional integrations modification for the and .

Repository Released

Documentation

Deployment documentation and scripts have been enhanced and are compliant with V3 architecture.

Developer documentation for all the repositories has been added for developers to set up in their local systems.

Release Name: Resident Services

Release version: vDP1

Support: Developer Preview Release1

Release Date: 12th Sept, 2023

Overview

This release marks the developer's preview release of Resident Services, offering valuable insights into the range of features and functionality available. Resident Services is designed to run on 1.2.0.1-B3 version of MOSIP platform. Resident Services are the self-services which are used by the residents themselves via a portal. is a web-based UI application that provides residents of a country the services related to their Unique Identification Number (UIN). The residents can perform various operations related to their UIN/ VID and can also raise concerns if any through the portal.

The key features provided on the Resident portal are:

1. Avail UIN services using UIN/VID (through ):

   • View My History

   • Manage My VID

   • Secure My ID

   • Track My Requests

   • Get Personalised Card

   • Share My Data

   • Logout

2. Get Information

   • About Registration Centers

   • List of supporting documents

3. Get My UIN (using UIN/ VID/ AID)

4. Verify email ID and/ or phone number

5. Responsive UI support- Support for the application to work seamlessly on various resolutions.

6. Book an appointment for new enrolment (via the pre-registration portal)

7. Ancillary features

   • Font size

   • Get Notifications (email and bell notifications)

   • View profile details of the logged in user (name, photo, and last login details)

Repository Released

Services

Resident Portal UI

Build and Deploy

Configurations

Developers Guide

For a detailed description of Resident Services, code, design, and setup steps, refer to:

API

Test Report

Scope

The scope of testing is to verify fitment to the specification from the perspective of:

• Functionality

• Deployability

• Configurability

• Customizability

Verification is performed not only from the end-user perspective but also from the System Integrator (SI) point of view. Hence, the configurability and extensibility of the software are also assessed. This ensures the readiness of software for use in multiple countries. Since MOSIP is an “API First” product platform, the verification scope required comprehensive automation testing for all the MOSIP APIs. An automated Test Rig is created for the same.

Test approach

Persona based approach has been adopted to perform the IV&V(Independent Verification and Validation) by simulating the test scenarios that resemble a real-time implementation.

A Persona is a fictional character/ user profile created to represent a user type that might use a product/ or a service in a similar way. Persona-based testing is a software testing technique that puts software testers in the customer's shoes, assesses their needs from the software and thereby determines use cases/ scenarios that the customers will execute. The persona's needs may be addressed through any of the following:

• Functionality

• Deployability

• Configurability

• Customizability

The verification methods may differ based on how the need was addressed.

For regression check, MOSIP Test Rig, an automation testing suite is indigenously designed and developed for supporting persona-based testing. MOSIP Test Rig covers end-to-end test execution and reporting. The end-to-end functional test scenarios are written starting from pre-registration, to the creation of the packet in the registration centre, processing the packet through the registration processor, generating UIN and authenticating identity using IDA through various permutations and combinations of cases being covered. MOSIP Test Rig will be an open-source artifact which can also be enhanced and used by countries to validate the SI deliveries before going live. Persona classes include both negative and positive personas. Negative persona classes include users like Bribed Registration Office, Malicious Insider etc. The needs of positive persona classes must be met, whereas the needs of negative persona classes must be effectively restricted by the software.

Verified configuration

Verification is performed on various configurations as mentioned below:

• Default configuration- with 3 Lang

• Virtual countries

  • 1 Lang configuration

  • 2 Lang configuration

  • 3 Lang configuration

External API verification results for all modules

The below section provides details on API test metrics for all modules by executing MOSIP functional automation Framework. All external API test executions were performed at module-level isolation. Each endpoint is tested with the test data and expectations of each test data are mapped to assert the test case.

Test Rate: 100% with Pass Rate: 96%

Here is the detailed breakdown of metrics:

Testing End-to-End flow(s)

End-to-end flows are a set of stateful test cases that expects the results across multiple modules. The test does not cover the intermediary stages, rather concentrates on the end result for a given data. The test covers both negative scenarios and positive scenarios with real world scenarios. Below are the end-to-end scenarios test metrics by executing MOSIP Automation Framework.

Test Rate: 100% with Pass Rate: 75%

Detailed Test metrics

Below are the detailed test metrics by performing manual/ automation testing. The project metrics are derived from Defect density, Test coverage, Test execution coverage, test tracking and efficiency.

The various metrics that assist in test tracking and efficiency are as follows:

• Passed Test Cases Coverage: It measures the percentage of passed test cases. (Number of passed tests / Total number of tests executed) x 100

• Failed Test Case Coverage: It measures the percentage of all the failed test cases. (Number of failed tests / Total number of test cases executed) x 100

Scope and Objective

Verifying the LTS bug fixes and performing regression for the same.

Testing tools

• Manual testing for bug validation.

• DSL automation/ API test rig: Java, Selenium

Test deliverables

• Test report with results

• Feature health report

Verified Configuration

• Tested in environments supporting 2 languages: Eng, Ara

• Features tested on V2 as well as V3 console

Functional test results by modules

Below are the test metrics by performing functional tests:

Tests execution for bugs verification and sanity testing

API Test Automation Metrics

Note: The number of failed test cases is cumulative of issues in released software as well the issues in the test automation scripts.

Testing Scope

The scope of testing is to verify fitment to the specification from the perspective of

• Functionality

• Deployability

• Configurability

• Customizability

Verification is performed not only from the end user perspective but also from the System Integrator (SI) point of view. Hence Configurability and Extensibility of the software is also assessed. This ensures readiness of software for use in multiple countries. Since MOSIP is an “API First” product platform, Verification scope required comprehensive automation testing for all the MOSIP APIs. An automation Test Rig is created for the same. All MOSIP UIs are reference implementations and these were verified through UI automation Test rig for Registration Client and Admin UI.

Test Approach

Persona based approach has been adopted to perform the IV&V, by simulating test scenarios that resemble a real-time implementation.

A Persona is a fictional character/user profile created to represent a user type that might use a product/or a service in a similar way. Persona based testing is a software testing technique that puts software testers in the customer's shoes, assesses their needs from the software and thereby determines use cases/scenarios that the customers will execute. The persona needs may be addressed through any of the following.

• Functionality

• Deployability

• Configurability

• Customizability

The verification methods may differ based on how the need was addressed.

For regression check, “MOSIP Test Rig” - an automation testing suite - which is indigenously designed and developed for supporting persona based testing. MOSIP Test Rig covers the end to end test execution and reporting. The end-to-end functional test scenarios are written starting from pre-registration, to creation of packet in registration centre, processing the packet through the registration processor, generating UIN and authenticating identity using IDA through various permutation and combinations of cases being covered. MOSIP Test Rig will be an open source artifact which can also be enhanced and used by countries to validate the SI deliveries before going live. Persona classes include both negative and positive personas. Negative persona classes include users like Bribed Registration Office, Malicious Insider etc. The needs of positive persona classes must be met, whereas the needs of negative persona classes must be effectively restricted by the software.

Verified configuration

Verification is performed on various configurations as mentioned below

• Default configuration - with 3 Languages

• Virtual countries

  • 1 Language configuration

  • 2 Language configuration

  • 3 Language configuration

Test execution statistics

Functional test results by modules

Below are the test metrics by performing functional testing using mockMDS and mockABIS. The process followed was black box testing which based its test cases on the specifications of the software component under test. Functional test was performed in combination of individual module testing as well as integration testing. Test data were prepared inline with the user stories. Expected results were monitored by examining the user interface. The coverage includes GUI testing, System testing, End-To-End flows across multiple languages and configurations. The testing cycle included simulation of multiple identity schema and respective UI schema configurations.

Test Rate : 100% with Pass Rate : 93%

Here is the detailed breakdown of metrics

External API verification results by modules

Below section provides details on API test metrics by executing MOSIP functional automation Framework. All external API test executions were performed at module level isolation. Each end point is tested with the test data and expectations of each test data are mapped to assert the test case.

Total number of external endpoints : 444 and total tested : 414

Test Rate : 93% with Pass Rate : 99%

Here is the detailed breakdown of metrics

Testing End To End flow(s)

End-To-End flows are a set of stateful test cases that expects the results across multiple modules. The test does not cover the intermediary stages, rather concentrates on the end result for a given data. The test covers both negative scenarios and positive scenarios with real world scenarios. Below are the End-To-End scenarios test metrics by executing MOSIP Automation Framework.

Test Rate : 98% with Pass Rate : 100%

Testing with Real Device

Below are the test metrics by performing functional testing with Tech5 SDK, Syncbyte devices and combination of real and mockABIS based on the scenario being tested. The test cases cover the real device/SDK/ABIS integration points. The responses from the system are validated at the integration points and results are asserted at the end of the flow. The logical endpoint differs depending on the test scenario being executed. These are executed with the help of the MOSIP supported partners.

Test Rate : 86% with Pass Rate : 86%

Detailed Test metrics

Below are the detailed test metrics by performing manual/automation testing. The project metrics are derived from Defect density, Test coverage, Test execution coverage, test tracking and efficiency.

The various metrics that assist in test tracking and efficiency are as follows:

• Passed Test Case Coverage: It measures the percentage of passed test cases.(Number of passed tests / Total number of tests executed) x 100

• Failed Test Case Coverage: It measures the percentage of all the failed test cases. (Number of failed tests / Total number of test cases executed) x 100

Overview

Release Name: 1.2.0.1 Beta 2

Release Version: 1.2.0.1-B2

Support: Developer Release

Release Date: 8-Jan 2023

The 1.2.0.1 Beta 2 release of MOSIP is a patch release on top of the Long-Term Support (LTS) release 1.2.0. This patch release mainly contains all the fixes for bugs, security and performance given as part of the 1.2.0.1-B1 patch and additional integrations modification for the and .

Repository Released

Documentation

For complete documentation, refer to 1.2.0 LTS documentation.

Deployment documentation and scripts have been enhanced and are compliant with V3 architecture.

Developer documentation for all repositories has also been added for developers to set up in their local systems.

• Repository-wise sonar report that covers the following:

  • Code coverage report

  • Critical Open Bugs

  • Security vulnerabilities

  • Security Hotspots

Overview

Release Name: 1.2.0.1 Beta1

Release Version: 1.2.0.1-B1

Support: Developer Release

Release Date: 14-Oct 2022

The 1.2.0.1 Beta release of MOSIP is the first patch release on top of the Long-Term Support (LTS) release 1.2.0. This patch release mainly contains the fixes for bugs, security and performance. This release also contains minor feature enhancements. One of the major highlights of this patch release is the V3 deployment. Support for legacy V2 deployment is deprecated. The recommended deployment method will be V3 deployment architecture.

Repository Released

Modules

Commons

• Bug fix: Filter search was not working for the user zone and center mapping page. This error was because keycloak expected two different values for first name and last name and none of it should be null. As a fix, changes were made in keycloak. #MOSIP-18973

Administration

• Bug fix: In the admin UI, there was a restriction on the number of drop-downs as it was hardcoded and hence it wasn’t flexible. As a fix, the property-filterValueMaxCount:{"default":${mosip.kernel.filtervalue.max_columns},"registrationcenters":50,"locations":100} was added which has the ability to configure the number of items in drop-down. #MOSIP-19978

• Bug fix: Audit logs were not listed for few transactions. After the fix, audit logs were getting listed in the DB. #MOSIP-19965

• Bug_fix: In the admin portal, the cloning feature was not working. If a template had to be cloned from English to Arabic, on Arabic login, it displayed template not found error even though template was present. This issue has been fixed and cloning feature is now working. #MOSIP-19935

• Bug fix: User zone and center mapping column sort was not working as expected. As a fix, sorting for logical column was removed. #MOSIP-19934

• Bug fix: For bulk upload, the event Id in audit log was incorrectly being captured. After the fix, the audit logs displayed the expected event Id. #MOSIP-19841

• Bug fix: In admin portal, when the center is inactive, the user should still be able to change the zone. After the fix, user was able to change the zone with an inactive center. #MOSIP-19817

• Bug fix: In admin portal, for an active center, when a device was created in that center, on editing the device, it did not display the expected values (it was blank). After the fix, the device details are visible in edit mode. #MOSIP-19806

• Bug fix: In Arabic language, on selecting the location on 1st level of hierarchy, the value in 3rd level of hierarchy was being populated. After the fix, the value of only 2nd level of hierarchy is populated on selecting the location on 1st level of hierarchy. #MOSIP-19699

• Bug fix: In admin portal, when the status of a language dependent masterdata was changed or if it was decommissioned, in a particular language, it was expected to be reflecting in other languages as well. After the fix, it was reflecting in Arabic language as well. #MOSIP-19652

• Bug fix: For language dependent masterdata, both the code and lang_code should have primary_key_constraint so that one is able to have same code in different languages. As a fix primary_key_constraint was added. #MOSIP-18682

• Bug fix: Failure/Error messages are displayed with "!". In case of failures and errors, the exclamation symbol from the end of the text was removed to fix the issue.#MOSIP-18658

• Bug fix: In the existing dynamic field, the "name" and "description" field were editable. After the bug fix, those were made to be non-editable. #MOSIP-18589

• Bug fix: In the admin portal, when one adds values under an existing dynamic field, the description of that value should be pre-filled with the data in the existing dynamic field. After the fix, the description was auto-filled as expected. #MOSIP-18584

• Feature upgrade: While creating dynamic field, initially, we used to input the data as dataType and now it is entered as text field. #MOSIP-16855

• Bug fix: In admin portal, the pagination options were displayed in "English" language by default instead of the logged-in language. After the fix, pagination was displayed in the logged-in language.#MOSIP-16382

• Bug fix: In admin module, \tags were visible in the UI. After the fix, \tags were removed from the UI. #MOSIP-19979

• Bug fix: The audit logs were being logged in with incorrect event messages. As a fix, static audit logs were updated to fix the event messages. #MOSIP-19966

• Bug fix: In admin module, packet upload was failing. As a fix, data-read role was assigned to the user. #MOSIP-19818

• Bug fix: In Admin module, one was able to map Machine and Device to different Center ID which does not belong to that zone. As a fix, a validation was put in place to check if the center ID belongs to the given Zone or not. #MOSIP-19724

Registration Client

• Bug fix: Crop and Delete option was not working in Scan document window. After the fix, it was possible to perform the crop and delete action. #MOSIP-19431

• Bug fix: Capture Time not displaying in Supervisor/Operator Biometric screen in Registration Client. The “Capture Time” label is removed from UI. #MOSIP-18720

• Bug fix: In Registration Client, ""/"" Symbol is displaying before all Registration tasks. Removed slash before the registration tasks to fix the issue. #MOSIP-18649"

• Bug fix: UI should be refactored with RTL support when logged in Arabic language, after fixing the issue, able to see all the pages in RTL format when logged in Arabic. #MOSIP-18641

• Bug fix: In Registration Client, the biometric correction label was overlapping with the consent screen. As a fix, wrap text was enabled on label. #MOSIP-18077

Partner Management Services

• Bug fix: In PMP UI, the error message logo was missing. As a fix, error icon was added throughout the application. #MOSIP-19976

• Bug fix: In FTM details menu button, the name was "create device" instead of "create FTM". As a fix, the name of the button of resource bundle was modified to create FTM instead of create device. #MOSIP-19918

• Bug fix: In PMP UI, filter labels were not pointing to logged in language. As a fix, support was added to display label in multi language. #MOSIP-19639

• Bug fix: In PMP UI, filter columns for partner menu was not proper. As a fix, the display label was modified. #MOSIP-19414

• Bug fix: In PMP UI, user was allowed to create SBI details without mandatory details. After the fix, without mandatory details, SBI creation is not allowed. #MOSIP-17562

• Bug fix: In FTM details page, the status should be approve/reject instead of active/de-active. After the fix, approve/reject labels were updated. #MOSIP-19823

• Bug fix: In PMP UI, the partner could be mapped to the same policy twice. After the fix, one partner can only be mapped to one policy. #MOSIP-19773

• Bugfix: In PMP UI, when a partner is registering themselves, the partner Id should be one single word with no space. After the fix, partner Id was not allowed to be created with space. #MOSIP-19404

• Bug fix: In PMP UI, partial search was not working. After the fix, partial search was working with asterisk(*). #MOISIP-19347

• Bug fix: In PMP UI, the partner admin should not be allowed to change the SBI details and FTM details after it was approved. After the fix, the SBI details and FTM details were made uneditable. #MOSIP-19309

• Bug fix: In PMP UI, the expected error message when the SBI details are added to the pending status device details was "Device details are not yet updated" instead "Device details does not exist" was seen. As a fix, label was updated. #MOSIP-19306

• Bug fix: In PMP UI, Search box was case sensitive in partner policy mapping. After the fix, the Search was made to be case insensitive. #MOSIP-19289

• Bug fix: In PMP UI, if a partner tries to register using an email which already exists, instead of displaying "email already registered", it was showing a blank page. After the fix, it was correctly showing the message. #MOSIP-19277

Pre-registration

• Bug fix: Cancel application mails from pre-registration were not being sent and email templates were not being fetched from correct template type code. After the fix, the mail contents were fetched from respective templates and cancel mails were duly sent. #MOSIP-18192

• Performance fix: Booking Slots were missing for many centers in cellbox2 env. As a fix, a code change was done in Batch Job to call master data API with sorting by "ID" instead of "createdDateTime". #MOSIP-19942

• Security fix: The attacker could potentially see the files from the application or system. Using this, attackers can access other files as well. To mitigate the risk, the URL should not allow path manipulation. The "accept known good" input validation strategy was put in place. Also, a whitelist of acceptable inputs that strictly conforms to specifications was used. #MOSIP-14246

• Bug fix: When a center was created without selecting lunch hours, at the center selection page it was showing lunch time as 12:00 AM to 12:00 AM. As a code fix, a condition "if lunchStartTime!= lunchEndTime" was put in place. #MOSIP-18985

Comprehensive Review

• Bug fix: PACKET_NOT_FOUND_EXCEPTION packet reprocessed after deleting from the landing zone. Cherry-pick was missed out from older branches(1.1.5), hence the Dev team updated changes in 1.2.0 and now it is working as expected. #MOSIP-19651

• Bug fix: DMZ packet servers were not able to handle multiple landing zones. After the fix, DMZ packet servers were able to handle multiple landing zones. #MOSIP-19650Reporter

• Bug fix: UIN generation notification email has $name_eng in template body. In the database, the name is not mentioned as per the ID schema, after making appropriate changes, the name is coming correctly in the email notification.G87 #MOSIP-11872

• Bug fix: If a RID was inserted twice, referenceId already exists (in ABIS) error was displayed and the packet was being sent for reprocessing. After the fix, the packet was not passed onto the reprocessing stage. #MOSIP-14191

ID Authentication

• Bug fix: Even when DEVICE_PROVIDER Id was hot listed, authentication was being performed successfully. As a fix, Client secret key in property mosip.mosip.hotlist.client.secret was duly configured. #MOSIP-19829

• Bug fix: Even with an invalid document Id, UIN was getting activated. As fix a, in ID schema, subType attributes was added. #MOSIP-19338

• Bug fix: Authentication was successfully performed even with garbage value of application property of demo service as mosip.env. As a fix, the only allowed values were restricted to IDA authentication property files. #MOSIP-19160

• Bug fix: In the database, when e-KYC was performed, the entries were incorrect as OTP-AUTH, KYC-AUTH. After the fix, the entries are KYC, authentication type (E.g.: KYC-AUTH, OTP-AUTH). #MOSIP-18285

• Bug fix: In the database, the column called cr_by was not being updated and was left empty. This bug was fixed, cr_by column has the correct value of who created that particular entry. #MOSIP-14291

• Bug fix: Once the transaction configuration was changed to "2", the transaction limit in IDA DB did not change. After the code fix, the changes in config properties were being reflected in the DB. #MOSIP-19736

Resident Services

• Bug fix: Notifications were not being sent as per the preferred language. After the fix, notifications for send OTP were received in preferred language. NOTE- UINs generated from IDREPO. #MOSIP-19371

• Bug fix: VID was not behaving correctly according to the config properties. Also, OTP was successfully being sent even with a revoked VID. After the fix, both the above issues were resolved and behavior of VID was based on config and also OTP could only be sent with a valid active VID. #MOSIP-19270

• Bug fix: In the process of updating the demographic details of the resident from resident API, base exception errors were displayed. After the code fix, we were able to update the demographic details successfully. #MOSIP-19525

DB Changes

Known Issues

To view the list of known issues, click here.

Note: The 1.2.0.1-B1 version of Registration Client will not support the latest mock MDS (1.2.1-SNAPSHOT). All the biometrics will be captured fine but exception photo capture fails. To know more, refer here.

Documentation

For complete documentation, refer to 1.2.0 LTS documentation.

Deployment documentation and scripts have been enhanced and are compliant with V3 architecture.

Developer documentation for repos have also been added for developers to setup in their local systems.

Release Name: Asymmetric Amoeba

Release Version: 1.2.0

Upgrade from: 1.1.5

Recommended Patch Version: 1.2.0.1 Beta

Release Date: 14th February 2022

Asymmetric Amoeba is a Long Term Support (LTS) release. This release focuses on easy manageability, usability, enhanced performance, robustness, security, inclusivity (supports 2+ languages with no restrictions), and comprehensive documentation.

As a part of manageability, a fully supported and with the ability to self-register partners is included. To help with the operational needs, a fully-working reference module is included that can be used by the adopters to track and monitor the analytics around MOSIP.

Major areas of work

• Robustness

• Partner Management Portal

• Administration Portal

• Functional bug fixes

• Performance fixes

• Security fixes

• Reporting

• Documentation

Repositories Released

• Pre-registration
• Administration
• Partner Management
• Test Repositories

List of documents

Purpose

SonarCloud is used as a tool for deep code analysis, to explore all source files, whether in branches or pull requests, to reach a green Quality Gate and promote the build.

• SonarCloud URL: https://sonarcloud.io/organizations/mosip/projects

• Git Branch: 1.2.0-rc2

LTS Release gates

• Code coverage: to be maintained greater than or equal to 80%

• Bugs: There should be no critical bugs open

• Security Vulnerability: 0

• Security Hotspot: 0

• Code Duplications to be maintained below 3%

Code Coverage

Target : Code coverage to be maintained greater than or equal to 80%

Reliability: Bugs

Target: There should be no critical bugs open

Security Vulnerabilities and Security Hotspots

Target: There should be no security vulnerabilities and hotspots

Code Duplications

Target: Code duplications should be less than 3%

Commons

• The reference ID object validator now supports the validation of dynamic field data.

• The has been upgraded

  • to support multiple ballerina servers.

  • to have authentication and authorization for all subscribers and publishers.

  • it also has a health check feature now.

• JCE (Java Cryptography Extension) integration in Key Manager Service has been added.

• The open ID authentication adaptor has been created to integrate with any open-ID compliant IAM solution.

Admin Services

• Using the , the administrator can now enter master data in multiple languages (more than two). Earlier, we had a restriction to run only with two languages.

• For Fetch APIs of some of the non-sensitive master data, authentication has been disabled and caching has been enabled. The master data APIs that are changed: applicant type, blocklisted words, document categories, document types, dynamic fields, exception holidays, gender types, id types, individual types, languages, locations, location hierarchy levels, templates, template type codes, title, valid documents, weekdays, working days, and zones.

• Using the admin portal, the administrator can

  • map or unmap a user in Keycloak with a center and zone.

  • view the packets that were paused by the registration processor and resume them for further processing.

  • add or remove dynamic field data.

  • retrieve an individual's lost RID or misplaced RID.

  • control the levels of location hierarchy they require while creating the registration centers. The level of the hierarchy can be configured through configuration property value.

  • map the users to a registration center and to a zone.

  • create and update dynamic fields such as Gender, Blood Type, Residence Status, Marital Status etc.

  • configure the number of kiosks in a particular registration center during the process of creating the registration center.

• The and are now stored separately in different database tables as well new API has been created to store the UI spec for pre-registration and registration client

  • UI spec version and ID schema version are independent.

  • If any new version of UI spec is published, then it will not affect the ID schema version.

  • If any new version of ID schema is published, the corresponding version of UI spec needs to be republished or updated.

• APIs for adding partner ID, individual ID (UIN and VID), and device (serial number, make or model) in the hotlist has been added.

Pre-registration

• Using the pre-registration, the resident can provide demographic data in multiple languages (more than two). Earlier there was a restriction for only two languages.

• • “alignmentGroup” property has been added to align multiple UI components horizontally.

  • “changeAction” property has been added to handle custom change actions between two or more UI components.

  • “containerStyle” and “headerStyle” properties have been added to override the default CSS.

  • “transliteration“ property has been added to enable or disable transliteration of an attribute.

  • Language-specific validators have been added.

  • Support from a date picker and number spinner has been added for date and ageDate control types.

  • The document upload screen is now rendered from UI spec.

• The captcha service has been enhanced and is available now.

• The application now gets locked once the appointment is booked. Post booking, the application details cannot be modified, but the booking can be cancelled or rescheduled.

• The notification template now supports having parameters like centre name and center address.

• One single bucket is being created to store all the documents of the resident.

• During application creation, consent is collected from the resident and stored as a JSON object in the audit table.

• Pre-registration packets shared during data sync are now being encrypted with the machine-specific TPM public key.

• Pre-registration packets can be synced to the registration client even if the booking is not performed.

• Created an error handling framework to handle technical errors thrown from service in the UI.

• Added support for displaying custom validation messages in UI components. For example, instead of just displaying 'Invalid email' or 'Invalid phone', it can be made more specific like 'Invalid email format' or 'Phone number cannot exceed 10 digits'.

• The Send OTP button on the login page will be disabled till the OTP expiry time elapses.

• A pre-registration application will be locked and no further modifications will be allowed on it once an appointment is booked for the same.

• Registration Client will be able to perform an on-demand fetch for pre-registration application irrespective of its booking status.

• Encryption of pre-registration data during data sync with Registration Client.

• The structure of how the documents were stored in MinIO has been changed. Now we will have a single bucket with different folders for each PRID.

• The resident's consent is captured as part of the audit table.

Registration Client [RC]

• In the UI spec,

  • the sub-type can be set to RID, UIN or VID to perform validation for RID, UIN and VID using the in-build validator libraries.

  • regex validation for different languages can be added.

  • support for multiple age groups has been added.

• A control panel has been added in the registration client for biometric devices, non-biometric devices, configurable settings, registration client jobs have been added.

  • If multiple devices are connected, we can set a particular device as the default.

  • All of the job schedules can be locally modified and the jobs can also be triggered individually.

• All operations on the registration client are now performed based on the local time zone.

• Any anti-virus or transliteration implementation can be plugged in during the registration client packaging.

• The GPS and scanner implementation is moved to separate libraries so that countries can customize these implementations.

• The CSS and icon bundles are now moved to the artifactory.

• In the CBEFF, now the below flags are being stored under the others section,

  • RETRIES, for number retries for biometric capture

  • FORCE_CAPTURED, to identify if forced capture was done

  • SDK_SCORE, to store the score of the biometric SDK

  • EXCEPTION, to mark the biometric type as an exception, here BDB will be empty.

  • CONFIGURED, to store the list of configured attributes in the outer BIR (as per the ID schema)

• The link for change and forgot password can be configured, so that, from the UI, the user can be redirected to the corresponding IAM page to perform these operations.

• Packets can be auto-uploaded to the server based on a configuration.

• There is a regular expression validation in place for multiple languages (earlier the system was able to validate data only for English).

• We now have a configurable antivirus that is being used during registration client packaging. This virus scanner will be able to run based on the configuration frequency in the background.

• 1. Device selection settings

  2. Sync Settings

  3. Global configuration settings

• The registration client is now capable of handling multiple time zones, including the local time zone and the UTC.

• The RC is now capable of having multiple themes based on the country's choice. This is possible because now there is separate CSS and icons based on the configuration.

• In the RC, the ID schema and UI specs are created and stored separately for each flow (like new registration, UIN update, lost ID) which makes sure that in future if any other flow needs to be added, it can be added with zero code change.

• The RC now has the dynamic layouts and dynamic screens as a single screen that supports all Demographic/Documents/Biometrics captured which essentially means that the order of occurrence of the screen is now configurable.

• When the password of an operator/supervisor is changed in Keycloak, the operator will be automatically be logged out if he/she is already logged in (in online mode) using the old password. In offline mode, the old password can still be used for creating packets, unless the client application has not synced with the server.

• The RC works with both SBI v1.0 and MDS v0.9.5.

Registration Processor

• Notifications to users are being sent based on the user preferred language set during registration.

• The OSI validator stage has been removed and segregated into multiple stages, i.e,

  • CMD validator stage for verifying centre, machine and device details.

  • Operator validator stage to validate the operator details.

  • Supervisor validator stage to validate the supervisor details.

  • Introducer validator stage to validate the introducer details.

• Based on tagging of packets in the packet classifier stage, rules have been added in the workflow configuration for different age groups (Infant, minor and adult). For example, introducer validation is made mandatory for Infants and minors based on camel workflow.

• In the quality check stage, the packets having poor quality scores are not being rejected, instead, these packets are tagged for having poor, average or good quality biometrics based on configured thresholds. The final decision to process these packets can be made by the camel workflow.

• The external integration stage has been moved to reference implementation and is removed from default camel routes and registration processor deployment.

• Once the packet is uploaded to MinIO, the registration processor notifies the registration client so that it can delete the packet.

• Trust validation of devices has been added to the registration processor.

• The mandatory check, master data validation and biometric check have been removed as these checks are done by the id object validator.

• The stages do not make the final decision instead the final decision is made by the workflow and these are the workflow actions set by the stages,

  • MARK_AS_PAUSED, when the stage requests the workflow to pause the packet processing

  • COMPLETE_AS_PROCESSED, when the packet is verified and UIN is issued or user data is updated.

  • COMPLETE_AS_REJECTED, when a duplicate is found or rejected by a manual adjudicator or supervisor.

  • COMPLETE_AS_FAILED, when a packet fails to process and is not marked for reprocessing

  • MARK_AS_REPROCESS, when a packet is marked for reprocessing.

• Based on the above workflow action set by a stage or tags configured a packet can now be paused during processing and it can be resumed by the administrator. A default time elapse has also been added to auto-resume the packet processing.

• The verticles are grouped together to optimize the CPU usage and are executed as a single-stage using the stage executor. The various stage groups and associated verticles are,

  • Stage group 1: packet receiver stage

  • Stage group 2: quality classifier, secure zone notification, and message sender stage

  • Stage group 3: ABIS handler, ABIS middleware, bio deduplication, and manual verification stage

  • Stage group 4: biometric authentication, and demo deduplication stage

  • Stage group 5: cmd validator, operator validator, supervisor validator, introducer validator, and packet validator stage

  • Stage group 6: packet uploader, and packet classifier stage

  • Stage group 7: uin generator, and printing stage

• XSD and biometric signature validations have been added in the packet validator stage.

• The internal data share URL for registration processor integration components (i.e. ABIS and manual adjudication system) can be configured from registration processor configurations. The data share for credential issuance can now be different from the data share for the registration processor.

• The pause and resume feature was decoupled from hotlisting feature and modified to support any configured tag.

• Tagging feature has been enhanced to support more tags on a packet.

• Certificate thumbprint will be shared as a part of authentication requests for all internal authentications from the registration processor.

• The registration officer/supervisors userId can now be mapped to VID/UIN in Keycloak

• An API has been added to the registration processor to find the resident’s lost RID.

• Readiness and liveliness probes have been created as part of registration processor service discovery and load-balancing features

• A new flow has been added to the registration processor to support and initiate correction. As a reference implementation, we have added a biometric correction flow.

• Virus scanner was made as a runtime dependency in the registration processor.

ID Repository

• APIs for creating, updating, retrieving and publishing drafts have been added.

• A job to re-seed all the credentials for a new ID Authentication instance or change in Datashare policy has been added.

ID Authentication [IDA]

• IDA is able to re-trigger the issuance of the credential for the missing active UIN or VID in IDA during startup.

• IDA is able to pull the failed web-sub messages and process them during startup.

• IDA is able to send notifications to residents based on the preferred language set by the resident during registration.

• The dependency for sending only primary and secondary language-based e-KYC responses have been removed. Now in e-KYC, the relying party needs to specify the language codes in the partner policy.

• Different configuration properties files have been created for IDA internal authentication, external authentication, e-KYC, OTP services for the web sub callback URL.

• Validation of the domain and environment values have been added. These are validated against a list of values added in the configuration.

• All validations apart from length and checksum have been removed for UIN and VID in IDA APIs.

• The certificate data from partner management is now retrieved via the data share URL.

• A new internal authentication API has been built with a different endpoint. This API doesn’t support, encryption, HMAC and biometric hash validation. It only performs signature validation of the header.

• IDA now has MOSIP authentication filter interfaces in place which has the capability of controlling the authentication type that will be applicable to the resident on a case basis(since an infant biometric is not captured, the system will only allow demographic authentication for infants).

• The hotlist validation can be enabled or disabled for various attributes like partner ID, individual ID (UIN and VID), and device (serial number, make or model) using configurations.

• All the master data, partner details and policy information is now being synced to IDA via. web-sub. IDA consumes this information from its database after the sync, hence it is now independent of all MOSIP modules.

• The demographic authentication with normalization is now externalized via an API. The implementation for the same is done in a separate library (which is part of our reference implementation) and can be configured easily in IDA.

• IDA is publishing events for any fraud management system for,

  • Validation failures

  • Authentication failures

  • Multiple OTP or authentication requests

• IDA is now capable of pulling the missing data (data that has been lost since the maximum retry limit has been exceeded once the IDA comes up after being down) such as credentials from the web sub-message store for all the records with the failed delivery status. For other data, such as partner data and master data, pulling of missing data will be done by Kafka.

• All the credential requests of UINs/VIDs that are updated/deactivated/revoked/blocked will be invalidated by the system.

• IDA database will now store the partner details which include data like partner ID, policy ID, MISP ID and API keys to authenticate the above entities directly from IDA.

• IDA can now validate whether the UIN, devices, partners or VIDs are hot listed or not when trying to perform an authentication.

• The CBEFF utility has been deprecated and the new implementation has been added.

• IDA can now authenticate identity details of the individual corresponding to the UIN in the request with dynamic demographic JSON and ID Schema hence the need to map ID attributes will not be required.

• IDA will now send notifications to the residents in the case of events like authentication failed/successful, authentication type lock/unlocked notification is sent to resident service and credential details stored successfully/failed notification is sent to the credential request service.

• Every time there is any changes made to the template or title in master data, it will be notified to IDA using web-sub hence updating the cache in IDA.

• IDA will now verify the device details when the biometric authentication request is received. It will validate the trust of the device provider & FTM partner, the timestamp in the digital ID, and the status of the device (whether it is active, de-active or hot listed).

• The system (IDA/ID repo) will have the ability to set an expiry date on a resident's identity record. This expiry date will control if the resident can perform authentication or not.

Resident Services

• The unlock authentication type API has been modified to support auto-lock after x seconds. When the time has passed the authentication type will be auto-locked after the time elapses.

• Resident services will now support multiple languages. There will be a list of mandatory languages as well as a list of optional languages for the resident to choose from.

• The notifications are being sent to the residents based on the preferred language set during registration.

Partner Management

• In this release partner management portal is available. This portal can be used by partner admin, policy admin and various MOSIP partners like authentication partners, device providers, FTM providers, and credential partners.

• The partner portal has the below features

  • Self-registration of partners

  • Partner specific certificate upload

  • Partner can add device models, FTM models, policy mapping, SBI details

  • Partner and policy admins can approve/reject partner requests, create policies and can add MOSIP compliant CA (certificate authorities)