1 of 39

Compliance Tool Kit

Overview

Compliance Tool Kit (CTK) is an online portal that can be used by MOSIP partners to test the compliance of their product developed as per specifications (specs) published/adopted by MOSIP.

Currently, CTK supports testing of compliance with the below specifications:

SBI: Secure Biometric Interface (SBI) is used to interface with biometric devices. Device partners are required to build a software layer that provides a unified communication protocol for all biometric capture use cases. The specifications that should be followed are defined as Secure Biometrics Interface (SBI) specs. The compliance tool kit ensures that the interface built by the device provider follows the specs, and a certain level of security and integrity is defined in the SBI spec. The device hardware security features are not tested as part of this toolkit.
CTK also supports the testing with Android SBI specifications.
SDK: Biometric Service Providers (BSPs) provide SDK implementation which supports quality check, match, extraction, and conversion of biometrics. MOSIP defines an iBioAPI as the specification for this SDK implementation. Biometric SDK providers are also required to integrate this HTTP service into their solution. This allows running the SDK as an independent HTTP service. The compliance tool kit would make sure that these interfaces are as per the MOSIP-defined specifications for smooth interaction.
ABIS: To provide a unique identity for a resident, MOSIP has to ensure that the uniqueness of the resident's biometrics is maintained. To achieve this, MOSIP interfaces with an Automated Biometric Identification System (ABIS) to perform the de-duplication of a resident's biometric data. ABIS is used for 1:N deduplication. MOSIP interacts with ABIS only via message queues. The JSON format is used for all control messages in the queue. ABIS must comply with the interface defined in ABIS API Specifications.

How does Compliance Tool Kit work?

To support compliance with the specifications, CTK has predefined test cases for each of the above specs.
Each test case is run on a given method of the specs. Each test case defines the attributes required to create the request to be sent to the method.
Each test case also defines the response expected from the method. In this response, various validators are run. Each validator will perform a predefined check on the response. If all validations are successful, the test case is passed otherwise it is a failed test case.
Partners can use CTK to run these test cases to check if their implementation adheres to the MOSIP’s specs or not.

Architecture

The diagram below illustrates the architecture of Compliance Tool Kit.

Default Collections for CTK

When a new project is created, two new collections will be automatically added to the project.
The first collection is the Compliance Collection, which is applicable for all project types. The second collection is the Quality Assessment Collection, specifically for SBI projects.

Compliance Collection Reporting Process (for all project types)

Partners can run the Compliance Collection and they can generate Draft Report for the same.
After self-review, the partners can submit the Draft Report for review by the CTK Admin.
CTK Admin can review the partner's test run, project details and all other details before Approving or Rejecting the Report.
Final report can be downloaded by both, the partner and CTK Admin.

Summarizing as below:

Partner > Add Project > Compliance Collection > Run Collection (Test Run) > View Test Run > Download Draft Report > Submit for Review
CTK Admin > View Draft Report / View Test Run > Approve / Reject Report

Quality Assessment Collection Reporting Process (only for SBI)

The Quality Assessment Collection reporting procedure is very similar to the Compliance Collection process.
Using this collection, partner can collect biometric scores for various groups of individuals (age wise, gender wise, occupation wise etc.).
BQAT SDK provides biometric score.
This biometric score serves as the basis for evaluating the quality of the SBI partner..

Summarizing as below:

Partner > Add Project > Quality Assessment Collection > Run Collection (Test Run) > View Test Run > Download Quality Assessment Draft Report > Submit for Review
CTK Admin > View Quality Assessment Draft Report / View Test Run > Approve / Reject Report

Compliance Tool Kit Portal

To set up the Compliance Tool Kit, refer to How to set up CTK.

To use the CTK portal, refer to the Compliance Tool Kit User Guide.

Build and deploy

To access the build and read through the deployment instructions, refer to the below-mentioned READMEs:

Configurations

For details related to the Compliance Tool Kit configurations, refer Compliance Tool Kit configuration document.

Developer Guide

To be able to add new test cases to CTK, refer to How to add more test cases.

Source code

To access the source code for Compliance Tool Kit, refer,

Version 1.4.0

Release Name: CTK 1.4.0

Support: Stable Release

Release Date: 15th April, 2024

Overview

The 1.4.0 version of CTK includes the following new features:

New Features in CTK 1.4.0 release

Quality Assessment Report is now available for Quality Assessment Collections. This report is eligible for review, similar to the Compliance Collection report.
Added a new CTK Landing page
Added Terms & Conditions consent popup for partners during login. If a partner does not provide consent, they will be automatically logged out.

SBI Testcases Enhancements

Added a negative SBI testcase SBI1196 where Discover request attributes are in UPPER CASE
Added testcases(SBI1197, SBI1198 and SBI1199) where bioSubTypes is optional in RCapture request
Enhanced all SBI schemas by adding "Additional Properties" as "false" in all nested objects as well. This will disallow any extra attributes at nested levels.
Community reported issue in the CTK UI GitHub repository is fixed - Android SBI CTK Check Device Status failed: SBI1028, SBI1029
In the trust validation process, we’ve now incorporated an additional check for the Organization Name. This check involves verifying both the logged-in user’s organization and the Subject Organization specified in the certificate. By doing so, we enhance the security and reliability of our validation procedures.
Responses from SBI RCapture will now be encrypted and stored in the CTK database.
In response to a community-reported issue, CTK now sends the ‘previousHash’ as the SHA256 hash of an empty UTF-8 string, rather than simply an empty string.
The attributes, "requestedScore" and "qualityScore" currently support floating point numbers in CTK schemas and testcases.

ABIS Testcases Enhancements

Added new ABIS DataShare related testcases ABIS3030, ABIS3031. ABIS3031 is inactive in this release since it needs some changes in kernel-auth-adapter.
Enhanced all ABIS schemas by adding "Additional Properties" as "false" in all nested objects as well. This will disallow any extra attributes at nested levels.

SDK Testcases Enhancements

Enhanced all SDK schemas by adding "Additional Properties" as "false" in all nested objects as well. This will disallow any extra attributes at nested levels.

Technical Enhancements

Added a Batch Job for Archival of oldest X test runs per collection to an archive table. This X is configurable.
API documentation
Create separate repository for CTK test cases.
CTK 1.4.0 test with latest released code of Mock MDS, Mock SDK and Mock ABIS
Capture BQAT version and other details in Quality Assessment Report
Fixed bugs identified in Security Testing of CTK

Repository Released

Repositories

Tags Released

mosip-compliance-toolkit

mosip-compliance-toolkit-ui

compliance-toolkit-batch-job

compliance-toolkit-testcases

mosip-config

Dependency

Artifactory: mosipid/artifactory-ref-impl: 1.2.0.1
Audit manager: mosipid/kernel-auditmanager-service: 1.2.0.1-B1
Auth Manager: mosipid/kernel-authmanager: 1.2.0.1-B1
Key Manager: modipid/kernel-keymanager-service: 1.2.0.1-B1
Partner Management: mosipid/partner-management-service: 1.2.0.1-B1
KeyCloak: mosipid/keycloak-init: 1.2.0.1-B1
Postgres: mosipid/postgres-init: 1.2.0.1-B1
Config Server: config-server: mosipid/config-server: 1.1.2
Notification Service: mosipid/kernel-notification-service: 1.2.0.1-B1
ClamAV: clamav/clamav: latest
MinIO

Post installation, follow the setup steps available here.

Documentation

Feature Documentation
Compliance Tool Kit User Guide
Android CTK App user Guide
QA Report
Videos

Version 1.3.0

Release Name: CTK 1.3.0

Upgrade From: CTK 1.2.0

Support: Stable Release

Release Date: 5th January, 2024

Note:

On January 25th, 2024, the mosip-compliance-toolkit tag has been updated from v1.3.0 to v1.3.1 in order to resolve a bug in the BiometricsQualityCheckValidator during the conversion of bioScore into bioScoreRange.
Furthermore, on February 12th, 2024, an update was made to the mosip-compliance-toolkit tag from v1.3.1 to v1.3.2. This update aims to address the issue of missing table names in the ddl.sql located within the db_scripts folder.

Overview

The 1.3.0 version of CTK includes the following new features:

Enhanced Report Generation and submission capabilities for CTK (Report for Review).
Added Admin login functionality to enable viewing Partner Reports, conducting Test Runs, and approving or rejecting submitted Reports.
Incorporated Quality Assessment testcases using BQAT quality check on biometrics captured by SBI devices.
Additional Hash Validation testcases for SBI to ensure data integrity.
Included support for Kibana Dashboards in CTK.

To know more about the Hash generation logic, read Hash Generation.

Repository Released

Repositories

Tags Released

mosip-compliance-toolkit

mosip-compliance-toolkit-ui

bio-utils

Imagedecoder

Dependency

Artifactory: mosipid/artifactory-ref-impl: 1.2.0.1-B2
Audit manager: mosipid/kernel-auditmanager-service: 1.2.0.1-B1
Auth Manager: mosipid/kernel-authmanager: 1.2.0.1-B1
Key Manager: modipid/kernel-keymanager-service: 1.2.0.1-B1
Partner Management: mosipid/partner-management-service: 1.2.0.1-B1
KeyCloak: mosipid/keycloak-init: 1.2.0.1-B1
Postgres: mosipid/postgres-init: 1.2.0.1-B1
Config Server: config-server: mosipid/config-server: 1.1.2
Notification Service: mosipid/kernel-notification-service: 1.2.0.1-B1
ClamAV: clamav/clamav: latest
MinIO

Post installation, follow the setup steps available here.

Test Report

Scope

The scope of testing revolved around verifying the compliance of the product as per the specifications published by MOSIP using the below devices:

The Windows Compliance tool kit was tested with the below specifications:

ABIS (Automated Biometric Identification System) Specifications was tested with Fingerprint, Iris and Face modalities as per specifications.
Secure Biometric Interface (SBI)
- Registration devices for Iris, Face and Fingerprint
- Authentication devices for Iris, Face and Fingerprint
Biometric SDK
- Quality Check
- Match
- Extraction
- Conversion

The Android Compliance tool kit app v1.2.0 was tested with the below specifications:

Secure Biometric Interface (SBI)
- Registration devices for Iris, Face and Fingerprint
- Authentication devices for Iris, Face and Fingerprint

Test Execution Statistics

ABIS Testing

MOSIP interfaces with an Automated Biometric Identification System (ABIS) to perform de-duplication of a resident's biometric data. A country may use multiple ABISs for the same biometric data and evaluate the best ABIS based on de-duplication quality. ABIS is used for 1:N de-duplication. For 1:1 authentication, Biometric SDK is used. MOSIP does not recommend using an ABIS for 1:1 authentication.

Test cases have been tested with MOSIP mock ABIS for compliance with the MOSIP specifications across 29 test cases.

Out of scope: Real ABIS testing in CTK 1.2.0

SBI Testing

The Secure Biometric Interface (SBI) is used to interface with the biometric devices. The Compliance tool kit was tested to ensure that the interface built by the device provider is following the specifications and security rules defined in the SBI spec. The device hardware security features are not tested as a part of Compliance tool kit.

For Android Authentication Devices using MOSIP's Android mock SBI

The Android CTK app v1.2.0 with MOSIP Android Mock SBI has been tested for compliance with the specifications across 55 test cases. Test cases specific to quality and user interactions have been tested with MOSIP Android mock SBI.

For Android Registration Devices using MOSIP's Android mock SBI

The Android CTK app v1.2.0 with MOSIP Android Mock SBI has been tested for compliance with the specifications across 64 test cases. Test cases specific to quality and user interactions have been tested with MOSIP Android mock SBI and real registration face SBI.

For Windows Authentication Devices using MOSIP's windows mock SBI

The Windows CTK 1.2.0 with MOSIP windows Mock SBI has been tested for compliance with the specifications across 55 authentication spec test cases.

For Windows Registration Devices using MOSIP's windows mock SBI

The Windows CTK 1.2.0 with MOSIP windows Mock SBI has been tested for compliance with the specifications across 76 registration spec test cases.

Out of scope: Real devices testing on Windows and android CTK.

SDK Testing

The SDK implementation has been tested to support quality check, match, extraction, and conversion of biometrics. Test cases have been tested with MOSIP mock SDK.

Out of scope: Segmentation testing and Real SDK testing.

Known Issues

After login to CTK Android app, the previous browser tab is not killed. Workaround: Once the popup appears, the user can manually close the tabs.
Newly registered user not landing on the CTK android home page (an intermittent issue observed on Samsung A03 mobile device).
In CTK Android app, UI elements are overlapping with each other (issue observed on Samsung A03 and Oneplus nord AC2001 mobiles because of screen size).
Add project/ collection takes empty spaces as name (validation is missing).
In Android CTK -Encryption Key button is not appearing for Auth projects (Workaround: Partners can download the Encryption Key from the web application.
With Android mock MDS, SBI1067 and SBI1068 testcases for Auth Iris ISO validation failing (issue with Android mock MDS).

Docker version (required for Compliance Tool Kit)

mosipqa/compliance-toolkit-service:1.2.0

mosipqa/compliance-toolkit-ui:1.2.0

mosipqa/postgres-init:1.2.0.1

mosipid/postgres-init:1.2.0.1-B2

mosipid/config-server:1.1.2

mosipid/kernel-auditmanager-service:1.2.0.1-B1

mosipid/kernel-auth-service:1.2.0.1-B2

mosipqa/authentication-service:1.2.0.1

mosipid/kernel-keymanager-service:1.2.0.1-B2

mosipid/keycloak-init:1.2.0.1-B2

mosipqa/partner-management-service:1.2.0.1

mosipqa/partner-onboarder:develop

mosipid/kernel-notification-service:1.2.0.1-B1

mosipid/mosip-keycloak:16.1.1-debian-10-r85

Sonar Report

MOSIP CTK Service

Test Report

The scope of testing revolved around verifying the compliance of the product as per the specifications published by MOSIP using the below devices:

Registration devices for Iris, Face and Fingerprint
Authentication devices for Iris, Face and Fingerprint

The Android Compliance tool kit App v1.1.0 was tested with the below specifications:

Secure Biometric Interface (SBI)

The Windows Compliance Tool kit was tested with the below specifications:

Secure Biometric Interface (SBI)

SDK

Quality Check
Match
Extraction
Conversion

Test Execution Statistics

SBI Testing

The Secure Biometric Interface (SBI) is used to interface with the biometric devices. The Compliance Tool kit was tested to ensure that the interface built by the device provider is following the specs and security rules defined in the SBI spec. The device hardware security features are not tested as part of Compliance Tool kit.

For Android Authentication Devices using MOSIP's Android mock SBI

The Android CTK app v1.1.0 with MOSIP Android Mock SBI has been tested for compliance with the specifications across 55 test cases.
Test cases specific to the quality and user interactions have been tested with MOSIP Android mock SBI.

For Android Registration Devices using MOSIP's Android mock SBI

The Android CTK app v1.1.0 with MOSIP Android Mock SBI has been tested for compliance with the specifications across 64 test cases.
Test cases specific to quality and user interactions have been tested with MOSIP Android mock SBI and real registration face SBI.

For Android Registration Devices using MOSIP's Android mock SBI

The Android CTK app v1.1.0 with real Android registration face SBI has been tested for compliance with the specification only for registration face device.

For Windows Authentication Devices using MOSIP's Windows mock SBI

The Windows CTK v1.1.0 with MOSIP Windows Mock SBI has been tested for compliance with the specifications across 55 authentication spec test cases.

For Windows Registration Devices using MOSIP's Windows mock SBI

The Windows CTK v1.1.0 with MOSIP windows Mock SBI has been tested for compliance with the specifications across 76 registration spec test cases.

Out of scope: Real devices testing in windows CTK.

SDK Testing

The SDK implementation has been tested to support quality check, match, extraction, and conversion of biometrics. Test cases have been tested with MOSIP mock SDK.

Out of scope: Segmentation testing and Real SDK testing

Known Issues

Docker version (required for Compliance Test Kit)

mosipqa/compliance-toolkit-service: 1.1.0

mosipqa/compliance-toolkit-ui: 1.1.0

mosipqa/postgres-init: 1.2.0.1

mosipid/postgres-init :1.2.0.1-B2

mosipid/config-server: 1.1.2

mosipid/kernel-auditmanager-service: 1.2.0.1-B1

mosipid/kernel-auth-service:1.2.0.1-B2

mosipqa/authentication-service: 1.2.0.1

mosipid/kernel-keymanager-service: 1.2.0.1-B2

mosipid/keycloak-init: 1.2.0.1-B2

mosipqa/partner-management-service: 1.2.0.1

mosipqa/partner-onboarder: develop

mosipid/kernel-notification-service: 1.2.0.1-B1

mosipid/keycloak-init: 1.2.0.1-B2

mosipid/mosip-keycloak: 16.1.1-debian-10-r85

mosipqa/keycloak-init: develop

Sonar Report

MOSIP CTK Service

MOSIP CTK UI Repository

Version 1.0.0

Release Name: CTK 1.0.0 (Beta)

Upgrade From:

Release Date: 3rd February 2023

Overview

The 1.0.0 version of MOSIP’s Compliance Tool Kit is the first patch release on top of the release on top of 0.0.9 version. This release covers similar features as the 0.0.9 version but has additional test scenarios for the SBI, like

Key Rotation Validations
Quality Check Validation of the biometrics captured in SBI
ISO Validation of the ISO data captured from the SBI

The subsequent releases will have more aggressive test scenarios and integration components (like ABIS, Manual Adjudication & Manual Verification systems).

Features Covered

The basic features such as,

Create a Project
Create a Collection
Run a Collection
View Details of a Test Run
Add Biometric Data

are available as part of the releases.

The current version can be used by the device and biometric SDK vendors to test their SBIs and SDKs.

As a part of the SBI test suite, we support the verification schema and signature verification of,

Interfaces
- Device discovery
- Device info
- Capture
- RCapture
Certification Level
- L0
- L1
Biometric Modalities
- Fingerprints
- Iris
- Face

As a part of the SDK test suite in the current version, we support the verification of schema and interface level verification for,

Interfaces
- Initialization
- Quality Check
- Matcher
- Extractor
- Converter
Biometric Modalities
- Fingerprint
- Iris
- Face

The detailed list of the test cases for SBI and SDK in the 1.0.0 version of the Compliance Tool Kit is available here:

Dependency

Artifactory: mosipid/artifactory-ref-impl: 1.2.0.1-B2
Audit manager: mosipid/kernel-auditmanager-service: 1.2.0.1-B1
Auth Manager: mosipid/kernel-authmanager: 1.2.0.1-B1
Key Manager: modipid/kernel-keymanager-service: 1.2.0.1-B1
Partner Management: mosipid/partner-management-service: 1.2.0.1-B1
KeyCloak: mosipid/keycloak-init: 1.2.0.1-B1
Postgres: mosipid/postgres-init: 1.2.0.1-B1
Config Server: config-server: mosipid/config-server: 1.1.2
Notification Service: mosipid/kernel-notification-service: 1.2.0.1-B1
ClamAV: clamav/clamav: latest
MinIO

Documentation

CTK Setup

Setup steps

Specifications

Test Report

Scope

The scope of testing revolved around verifying the compliance of the product as per the specifications published by MOSIP using the below devices:

The Windows Compliance tool kit was tested with the below specifications:

ABIS (Automated Biometric Identification System) Specifications was tested with Fingerprint, Iris and Face modalities as per specifications.
Secure Biometric Interface (SBI)
- Registration devices for Iris, Face and Fingerprint
- Authentication devices for Iris, Face and Fingerprint
Biometric SDK
- Quality Check
- Match
- Extraction
- Conversion

The Android Compliance tool kit app v1.2.0 was tested with the below specifications:

Secure Biometric Interface (SBI)
- Registration devices for Iris, Face and Fingerprint
- Authentication devices for Iris, Face and Fingerprint

Test Execution Statistics

ABIS Testing

Test cases have been tested with MOSIP mock ABIS for compliance with the MOSIP specifications across 29 test cases.

Out of scope: Real ABIS testing in CTK 1.2.0

SBI Testing

For Android Authentication Devices using MOSIP's Android mock SBI

For Android Registration Devices using MOSIP's Android mock SBI

For Windows Authentication Devices using MOSIP's windows mock SBI

The Windows CTK 1.2.0 with MOSIP windows Mock SBI has been tested for compliance with the specifications across 55 authentication spec test cases.

For Windows Registration Devices using MOSIP's windows mock SBI

The Windows CTK 1.2.0 with MOSIP windows Mock SBI has been tested for compliance with the specifications across 76 registration spec test cases.

Out of scope: Real devices testing on Windows and android CTK.

SDK Testing

The SDK implementation has been tested to support quality check, match, extraction, and conversion of biometrics. Test cases have been tested with MOSIP mock SDK.

Out of scope: Segmentation testing and Real SDK testing.

Known Issues

After login to CTK Android app, the previous browser tab is not killed. Workaround: Once the popup appears, the user can manually close the tabs.
Newly registered user not landing on the CTK android home page (an intermittent issue observed on Samsung A03 mobile device).
In CTK Android app, UI elements are overlapping with each other (issue observed on Samsung A03 and Oneplus nord AC2001 mobiles because of screen size).
Add project/ collection takes empty spaces as name (validation is missing).
In Android CTK -Encryption Key button is not appearing for Auth projects (Workaround: Partners can download the Encryption Key from the web application.
With Android mock MDS, SBI1067 and SBI1068 testcases for Auth Iris ISO validation failing (issue with Android mock MDS).

Docker version (required for Compliance Tool Kit)

mosipqa/compliance-toolkit-service:1.2.0

mosipqa/compliance-toolkit-ui:1.2.0

mosipqa/postgres-init:1.2.0.1

mosipid/postgres-init:1.2.0.1-B2

mosipid/config-server:1.1.2

mosipid/kernel-auditmanager-service:1.2.0.1-B1

mosipid/kernel-auth-service:1.2.0.1-B2

mosipqa/authentication-service:1.2.0.1

mosipid/kernel-keymanager-service:1.2.0.1-B2

mosipid/keycloak-init:1.2.0.1-B2

mosipqa/partner-management-service:1.2.0.1

mosipqa/partner-onboarder:develop

mosipid/kernel-notification-service:1.2.0.1-B1

mosipid/mosip-keycloak:16.1.1-debian-10-r85

Sonar Report

MOSIP CTK Service

How to add more test cases

Compliance Tool Kit (CTK) is an online portal that can be used by MOSIP partners to test the compliance of their product developed as per the specifications (specs) published by MOSIP. CTK currently supports compliance verification of SBI, SDK and ABIS specifications.

What are the CTK test cases?

To verify the compliance of the partner software with MOSIP specifications, MOSIP has created predefined test cases for the type of specification.

Each test case in CTK runs on a given method of the specs. For example, there will be a test case for the device method of SBI specs.
Each test case in CTK defines the attributes required to create the request to be sent to the partner application.
Each test case also defines the response expected from the partner application.
Each test case also defines the validators to be run in the response received.
Each validator also performs a predefined check on the response.
If all validations are successful, the test case is considered as passed, otherwise, the test case fails.

Partners can use CTK to run these test cases to verify if their implementation adheres to the MOSIP’s specs or not.

These test cases are defined in JSON format and saved in the CTK database.

Sample SBI test case

This test case is for verifying the check device discovery endpoint of an SBI. This test case is available for both Registration and Auth SBI projects and all device type and sub type combinations.

{
   "testCaseType": "SBI",
   "testName": "Discover device",
   "testId": "SBI1000",
   "specVersion": "0.9.5",
   "testDescription": "This test case verifies schema and signature of the device discovery interface",
   "isNegativeTestcase": false,
   "methodName": [
      "device"
   ],
   "requestSchema": [
      "DiscoverRequestSchema"
   ],
   "responseSchema": [
      "DiscoverResponseSchema"
   ],
   "validatorDefs": [
      [
         {
            "name": "SchemaValidator",
            "description": "Validates the response for mandatory attributes and  values"
         },
         {
            "name": "SignatureValidator",
            "description": "Validates the response signature"
         }
      ]
   ],
   "otherAttributes": {
      "purpose": [
         "Registration",
         "Auth"
      ],
      "biometricTypes": [
         "Finger",
         "Iris",
         "Face"
      ],
      "deviceSubTypes": [
         "Slap",
         "Single",
         "Double",
         "Full face"
      ],
      "segments": [
         
      ],
      "exceptions": [
         
      ],
      "requestedScore": "",
      "bioCount": "",
      "deviceSubId": ""
   }
}

Sample SDK test case

This test case is for verifying the quality of face biometrics (if it is above the acceptable threshold). This test case will be available for Face modality only and for the Quality Check project.

{
   "testCaseType": "SDK",
   "testName": "Good face quality",
   "testId": "SDK2001",
   "testDescription": "This test case verifies the biometrics for the face to be of good quality.",
   "specVersion": "0.9.0",
   "isNegativeTestcase": false,
   "methodName": [
      "check-quality"
   ],
   "requestSchema": [
      "CheckQualityRequestSchema"
   ],
   "responseSchema": [
      "CheckQualityResponseSchema"
   ],
   "validatorDefs": [
      [
         {
            "name": "SchemaValidator",
            "description": "Validates if the response has all mandatory attributes and they have allowed values"
         },
         {
            "name": "QualityCheckValidator",
            "description": "Checks the quality score of the modality"
         }
      ]
   ],
   "otherAttributes":{
      "modalities":[
         "face"
      ],
      "sdkPurpose":[
         "Check Quality"
      ]
   }
}

Sample ABIS test case

This test case is for verifying the insert endpoint of an ABIS. This test case is available for all ABIS projects.

{
   "testCaseType": "ABIS",
   "testName": "Insert one person\"s biomterics in ABIS",
   "testId": "ABIS3000",
   "specVersion": "0.9.0",
   "testDescription": "Insert one person\"s biomterics in ABIS",
   "isNegativeTestcase": false,
   "methodName": [
      "insert"
   ],
   "requestSchema": [
      "InsertRequestSchema"
   ],
   "responseSchema": [
      "InsertResponseSchema"
   ],
   "validatorDefs": [
      [
         {
            "name": "SchemaValidator",
            "description": "Validates if response has all mandatory attributes and they have allowed values"
         }
      ]
   ],
   "otherAttributes": {
      "bulkInsert": false,
      "insertCount": "1"
   }
}

Attributes in a test case

As can be seen from the above samples, few attributes are common across the test cases for SBI, SDK and ABIS while few are optional. Below is the list of each attribute and its use.

Name

Type

Description

Allowed Values

testCaseType

Required

Type of test case

SBI / SDK / ABIS

testName

Required

Name of test case

testId

Required

Unique ID for test case

SBI10XX, SDK20XX

specVersion

Required

Spec version being tested

0.9.5/1.0.0 for SBI, 0.9.0 for SDK

testDescription

Required

Test description. It can also include the steps to execute the test case.

isNegativeTestcase

Required

Indicates if the validator is for a positive or a negative scenario.

E.g.: for a bad face quality test, we expect a low score which is a negative scenario, so the validator should mark the test case as passed on receiving low score

inactive

Optional

Indicates that the test case is not active.

E.g.: The testcase SDK2026 is marked as inactive. So the user is unable to obtain this testcase.

inactiveForAndroid

Optional

Indicates that the test case is not active in CTK Android App.

E.g.: The testcase SBI1070 is marked as inactiveForAndroid. So the user is unable to obtain this testcase on android app.

methodName

Required

The name of the method to be invoked for the test case. It accepts an array. For SBI, this array will have only one value. For SDK, in case of a combination test case you can give 2 method names. E.g.: ["extract-template", "check-quality"]

device(SBI), info(SBI), capture(SBI), rcapture(SBI), stream(SBI), insert(ABIS), identify(ABIS), delete(ABIS), init(SDK), check-quality(SDK), match(SDK), extract-template(SDK), convert-format(SDK), segment(SDK)

requestSchema

Required

Name of the JSON schema file which will be used to validate the HTTP request. This HTTP request will be used to invoke the HTTP method defined in the spec. It accepts an array. For SBI, this array will have only one value. For SDK, in case of a combination test case you can give 2 request schema names. E.g: ["ExtractTemplateRequestSchema", "MatchRequestSchema"]

The request schema JSON files are saved in the MINIO in the following folder structure. E.g.: compliance-toolkit/schemas/sbi/0.9.5/ DiscoverRequestSchema.json

responseSchema

Required

Name of the JSON schema file which will be used to validate the HTTP response. This is the HTTP response that we will receive after invoking the HTTP method. It accepts an array. For SBI, this array will have only one value For SDK, in case of a combination test case you can give 2 request schema names. E.g.: ["ExtractTemplateResponseSchema", "MatchResponseSchema"]

The response schema JSON files are saved in the MINIO in the following folder structure. E.g.: compliance-toolkit/schemas/sbi/0.9.5/ DiscoverResponseSchema.json

validatorDefs

Required

Names of Validators that are to be invoked to run various validations on the response. It accepts an array of arrays. Each array is a list of validators to be applied to the response of the corresponding method in the test case. In the case of SBI, it is an array with a single array. In the case of SDK, for a combination test case it can be an array with a list of arrays.

Validators are available in the folder: compliance-toolkit\src\main\java\io\mosip\compliance\toolkit\validators

validatorDefs.name

Required

Name of the Java class which implements the BaseValidator.java interface.

Must implement method ValidationResultDto validateResponse(ValidationInputDto responseDto)

validatorDefs.description

Required

Description of the validations performed. These are shown in UI along with the test case description.

otherAttributes

Optional

Extra attributes about a test case

otherAttributes.purpose

SBI

Valid only for SBI test case. It accepts an array. The project purpose is used to filter the test cases with matching purposes.

Registration, Auth

otherAttributes.biometricTypes

SBI

Valid only for SBI test case. The project device type is used to filter the test cases with matching biometricTypes. It accepts an array.

Finger, Iris, Face

otherAttributes.deviceSubTypes

SBI

Valid only for SBI test case. The project device type is used to filter the test cases with matching deviceSubTypes. It accepts an array.

Slap, Single, Touchless, Single, Double, Full face

otherAttributes.segments

SBI

Valid only for SBI test case. It accepts an array. This array is used to populate “bioSubType” attribute in the request sent to the SBI method. Before the values are sent they are mapped to corresponding values. E.g.: RightIndex will be mapped to Right IndexFinger.

LeftIndex, LeftMiddle, LeftRing, LeftLittle, LeftThumb, RightIndex, RightMiddle, RightRing, RightLittle, RightThumb, UNKNOWN, Left, Right

otherAttributes.exceptions

SBI

Valid only for SBI test case. It accepts an array. This array is used to populate the exception attribute in the request sent to the SBI method. Before the values are sent they are mapped to corresponding values. E.g.: RightIndex will be mapped to Right IndexFinger.

LeftIndex, LeftMiddle, LeftRing, LeftLittle, LeftThumb, RightIndex, RightMiddle, RightRing, RightLittle, RightThumb, UNKNOWN, Left, Right

otherAttributes.requestedScore

SBI

Valid only for SBI test case. It accepts a string or null. This value is used to populate requestedScore attribute in the request sent to the SBI method.

otherAttributes.bioCount

SBI

Valid only for SBI test case. It accepts a string or null. This value is used to populate the bioCount attribute in the request sent to the SBI method.

otherAttributes.deviceSubId

SBI

Valid only for SBI test case. It accepts a string or null. This value is used to populate the deviceSubId attribute in the request sent to the SBI method.

otherAttributes.timeout

SBI

Valid only for SBI test case. It accepts a string or null. This value is used to populate the “timeout” attribute in the request sent to the SBI method.

otherAttributes.resumeBtn

SBI

Valid only for SBI test case. It accepts a string or null. This value is used to display a Resume button in UI before the SBI method is invoked. This pauses the test run and makes it possible for the user to make some changes in the SBI before the test case is executed. Helps in Device Status test cases.

otherAttributes.resumeAgainBtn

SBI

Valid only for SBI test case. It accepts a string or null. This value is used to display a Resume Again button in UI after the SBI method is invoked. This pauses the test run and makes it possible for the user to make some changes in the SBI after the test case is executed. Helps in Device Status test cases.

otherAttributes.hashValidationTestCase

SBI

Valid only for SBI test case. This value is used to determine if the test case is hash-validation testcase or not. The application will perform hash validations for different captures if the testcase is a hash validation testcase.

otherAttributes.transactionId

SBI

Valid only for SBI test case. It accepts a string. This value is used to populate the transactionId attribute in the request sent to the SBI method. For these testcases, SBI will give an error response.

otherAttributes.invalidRequestAttribute

SBI

It accepts a string. This value is used to populate the invalid attribute in the request sent to the SBI method.

otherAttributes.qualityAssessmentTestCase

SBI

Valid only for SBI test case. This value is used to determine if the test case is quality assessment testcase or not. It's used for creating quality assessment collection.

otherAttributes.ageGroup

SBI

Valid only for SBI test case. It accepts a string. This is used to define the different age groups, and it will also be available only for quality assessment test cases.

otherAttributes.gender

SBI

Valid only for SBI test case. It accepts a string. This is used to define the different gender, and it will also be available only for quality assessment test cases.

otherAttributes.occupation

SBI

Valid only for SBI test case. It accepts a string. This is used to define the different occupations, and it will also be available only for quality assessment test cases.

otherAttributes.race

SBI

Valid only for SBI test case. It accepts a string. This is used to define the different races, and it will also be available only for quality assessment test cases.

otherAttributes.testCaseRepeatCount

SBI

Valid only for SBI test case. It accepts a string. This value is used to repeat the testcase based on the count.

otherAttributes.modalities

SDK

This is applicable only for SDK testcases. It accepts an array.

finger, face, iris

otherAttributes.sdkPurpose

SDK

Valid only for SDK test case. It accepts an array. The project purpose is used to filter the test cases with matching sdkPurpose.

Check Quality, Matcher, Extract Template, Convert Format, Segment

otherAttributes.convertSourceFormat

SDK

Valid only for SDK test case. It accepts a string. For convert-format test cases this value is used as the input source format.

ISO19794_4_2011, ISO19794_5_2011, ISO19794_6_2011

otherAttributes.convertTargetFormat

SDK

Valid only for SDK test case. It accepts a string. For convert-format test cases this value is used as the output source format.

IMAGE/JPEG, IMAGE/PNG, ISO19794_4_2011/JPEG, ISO19794_5_2011/JPEG, ISO19794_4_2011/PNG, ISO19794_5_2011/PNG, ISO19794_6_2011/PNG

otherAttributes.bulkInsert

ABIS

Valid only for ABIS test case. This value is used to check the bulk insert condition. If we add more than one person's record, then it will be true.

otherAttributes.insertCount

ABIS

Valid only for ABIS test case. It accepts a string. This value is used to determine how many times the insert should happen.

otherAttributes.insertReferenceId

ABIS

Valid only for ABIS test case. It accepts a string. This value is used to determine if the given reference ID already exists or not.

otherAttributes.identifyReferenceId

ABIS

Valid only for ABIS test case. It accepts a string. It is used to identify the duplicant count of a given reference ID.

otherAttributes.identifyGalleryIds

ABIS

Valid only for ABIS test case. It accepts a string. It is used to find the duplicant for the reference ID against the given gallery ID.

otherAttributes.expectedDuplicateCount

ABIS

Valid only for ABIS test case. It accepts a string. It is used to define the expected duplicant count.

otherAttributes.expectedFailureReason

ABIS

Valid only for ABIS test case. It accepts a string. It is used to define the expected failure reason.

How to add a test case to the Database

Any new test case is to be uploaded to the database. Editing the testcases is not possible, the only actions you can take are to activate or deactivate them using the same steps.

1. Open postman and create a POST request.

2. URL endpoint https://{base_URL}/v1/toolkit/saveTestCases

3. Copy the Authorization token in the request header by logging into the Compliance Toolkit in your env with a user having a CTK_ADMIN role. Open the developer tools and copy the Authorization token from the headers section under the Networks tab. Add the Authorization token in postman, copy the token and place it in the headers section of the request (Cookie=Authorization:eyAjksa...)

4. Copy the test cases array JSON and prepare a request as shown below.

5. Request body for saveTestCases request

{
    "version": "1.0",
    "requesttime": "2022-10-29T06:06:51.174Z",
    "metadata": null,
    "request": {
        "testCases": [
<Paste the testcases here>
        ]
    }
}

6. Change the requesttime to the current day and send the request.

Where can you find the existing CTK test cases?

In the location below, you can find all the existing test cases: https://github.com/mosip/compliance-toolkit-testcases/tree/release-1.4.0

compliance_test_definitions_sbi.json: has all existing SBI test cases
compliance_test_definitions_sdk.json: has all existing SDK test cases
compliance_test_definitions_abis.json: has all existing ABIS test cases

CTK Configurations

Configuration

Description

Default Value

mosip.toolkit.sbi.ports

Default range of SBI (Secure Biometric Interface) ports scanned to connect to the devices.

4501,4502,4503,4504,4505,4506,4507,4508,4509,4510

mosip.toolkit.sbi.timeout

This specifies the default timeout value for all SBI testcases which do not include 'timeout' in 'otherAttributes'.

10000

mosip.toolkit.sbi.keyrotation.iterations

This specifies the number of times the device key has to be rotated for execution of SBI test cases: SBI1022, SBI1023, SBI1024, SBI1025, SBI1060, SBI1061.

mosip.toolkit.sbi.timestamp-interval

Specifies the time interval in minutes, In which the SBI device should send back the response and verified through testing with the following SBI test cases: SBI1083, SBI1084, SBI1085, SBI1086, SBI1087, SBI1088, SBI1089, SBI1090.

mosip.toolkit.languages.rtl

This specifies the languages that use a script direction that reads from right to left (RTL).

ara

mosip.toolkit.rcapture.encryption.enabled

Enables encryption of 'bioValue' field of the SBI rcapture response before saving data into the database for RCapture SBI testcases.

true

mosip.toolkit.sdk.finger.qualitycheck.threshold.value

Specifies the minimum quality acceptance threshold value. Used for quality checking when processing finger biometric data using SDK.

mosip.toolkit.sdk.face.qualitycheck.threshold.value

Specifies the minimum quality acceptance threshold value. Used for quality checking when processing face biometric data using SDK.

mosip.toolkit.sdk.iris.qualitycheck.threshold.value

Specifies the minimum quality acceptance threshold value. Used for quality checking when processing iris biometric data using SDK.

mosip.toolkit.sbi.quality.assessment.failsafe

Enabling this feature ensures that all Quality Assessment test cases pass, even if the biometric score falls below the predefined threshold.

true

mosip.toolkit.document.scan

Enables or disables the virus scanner for file upload in the compliance toolkit.

false

mosip.toolkit.compliance.collection.name

Defines the name assigned to the 'Compliance Collection' for a new project. Applicable across all project types (SBI, SDK, ABIS).

Compliance Collection - All TestCases

mosip.toolkit.quality.assessment.collection.name

Defines the name assigned to the 'Quality Assessment Collection' for a new project. Applicable exclusively to the SBI project type.

Quality Assessment Collection - All TestCases

mosip.toolkit.compliance.collection.ignore.testcases

Specifies the test cases to be excluded during the creation of the 'Compliance Collection'. These ignored test cases will not be included in the compliance collection.

mosip.toolkit.quality.assessment.collection.ignore.testcase

Specifies the test cases to be excluded during the creation of the 'Quality Assessment Collection'. These ignored test cases will not be included in the quality assessment collection.

mosip.toolkit.documentupload.allowed.file.type

Specifies the supported file formats for uploading biometric test data files in the compliance toolkit.

application/zip

mosip.toolkit.documentupload.allowed.file.nameLength

Specifies the maximum length allowed for file names during document uploads.

mosip.toolkit.documentupload.allowed.file.size

Sets the maximum allowed size in bytes, for files uploaded within compliance toolkit.

20000000

mosip.toolkit.report.expiryperiod.in.months

Specifies the expiry period in months, for reports generated within compliance toolkit.

mosip.toolkit.sbi.qualitycheck.finger.sdk.urls

Specifies the SDK URLs used for quality check of finger biometric data in the compliance toolkit.

[{"name": "BQAT SDK","url": "https://api-internal.net/bqatsdk-service","healthUrl": "https://api-internal.net/bqatsdk-service/actuator/health", "includeInResults":false}]

mosip.toolkit.sbi.qualitycheck.face.sdk.urls

Specifies the SDK URLs used for quality check of face biometric data in the compliance toolkit.

[{"name": "BQAT SDK","url": "https://api-internal.net/bqatsdk-service","healthUrl": "https://api-internal.net/bqatsdk-service/actuator/health", "includeInResults":false}]

mosip.toolkit.sbi.qualitycheck.iris.sdk.urls

Specifies the SDK URLs used for quality check of iris biometric data in the compliance toolkit.

[{"name": "BQAT SDK","url": "https://api-internal.net/bqatsdk-service","healthUrl": "https://api-internal.net/bqatsdk-service/actuator/health", "includeInResults":false}]

mosip.toolkit.quality.assessment.age.groups

Specifies the age groups used in Quality Assessment (QA) reports and is categorized by age ranges.

child(5-12), adult(12-40), mature(40-59), senior(60+)

mosip.toolkit.quality.assessment.occupations

Defines occupations categories used in Quality Assessment (QA) reports to assess variations in biometric quality due to occupational factors for Finger modality.

labourer, non-labourer

mosip.toolkit.quality.assessment.races

Specifies racial demographic categories used in Quality Assessment (QA) reports for Face modality.

asian, african, european

mosip.toolkit.batchjob.enable.testrun.archival

Activates the test run archival process when set to 'true' and reverses the archiving, restoring previously archived test runs, when set to 'false'.

true

mosip.toolkit.batchjob.testrun.archive.offset

Specifies the number of recent test runs to keep, after which the older test runs will be moved to the archives and saved in the Compliance Toolkit.

mosip.toolkit.batchjob.archival.revert.collectionids

Specifies the collection IDs of a project for which the test run archival should be reverted for a specific partner.

mosip.toolkit.batchjob.schedule.cron.testRunArchivalJob

Sets the automated schedule (CRON job) for archiving old test runs. By default, this runs daily at midnight (UTC).

0 0 0 * * ?

List of ISO validations performed by CTK

SBI captures biometrics by receiving raw data from biometric devices, processing and converting it into standardized templates, and securely storing them for identification and verification purposes.
In CTK, validations are performed on these biometrics to check if they follow the defined ISO standards.
ISO – International Organization for Standardization refers to an international standard development organization that develops standards to ensure the safety, quality and effectiveness of products and services.
In CTK, ISO validations are performed in three modalities- Finger, Face and Iris.
There are two types of ISO validations.
- General Header
- Representation Header
There are many validations for each type. The tables below contain a list of these validations.
ISOStandardsValidator is a validator that has been developed for CTK. All the validations mentioned above have been done in this validator.
A total of 8 test cases (SBI1062 to SBI1069) have been added to CTK for ISO validation.

The figure below represents the testcase result of ISO validation.

The list of validations performed for each of the modalities is given below.

Finger

Refer ISO 19794-4:2011 Specifications.

Sl.No

Name

Type

Description

Length

Valid values

Is this attribute mandatory?

Image verification

Format Identifier

General Header

FIR – Finger Image Record

4 bytes

464952Hex (F I R 00Hex)

yes

Version number

General Header

020 in ASCII

4 bytes

30323000Hex (0 2 0 00Hex)

yes

Length of record

General Header

Includes all finger/palm representations, quality blocks and certification blocks1

4 bytes

57 to (232-1)

yes

Number of Finger/Palm representations

General Header

[ (14 finger positions) + (11 multiple finger positions) + (17 palm codes) ]* 16 = 672 possible representations

2 bytes

1 to 672

yes

Certification flag

General Header

Indicates the presence of any device certification blocks within the representation headers

1 byte

0, 1

yes

No of Distinct finger/Palm Position

General Header

Number of fingers or palms represented

1 byte

>=1

yes

Representation Length

Representation Header

The representation-length field denotes the length in bytes of the representation including the representation header field.

4 bytes

yes

Capture date and time

Representation Header

The capture date and time field shall indicate when the capture of this representation started in Coordinated Universal Time (UTC). The capture date and time field shall consist of 9 bytes. Its value shall be encoded in the form given in ISO/IEC 19794-1.

9 bytes

yes

No of Quality block

Representation Header

1 byte

10.

Quality block

Representation Header

Quality Score 1 byte Quality algorithm vendorIdentifier 2 bytes Quality algorithm Identifier 2 bytes

11.

No of Certification Blocks

Representation Header

1 byte

yes

12.

Finger/Palm Position

Representation Header

Unknown 0 Right thumb 1 Right index finger 2 Right middle finger 3 Right ring finger 4 Right little finger 5 Left thumb 6 Left index finger 7 Left middle finger 8 Left ring finger 9 Left little finger 10

1 byte

yes

13.

Representation No

Representation Header

1 byte

yes

14.

Image Data Length

Representation Header

Number of bytes for the compressed/uncompressed image data

4 bytes

0 to (232-58)

yes

15.

Image Data

Representation Header

yes

Face

Refer ISO 19794-6:2011 Specifications.

Sl.No

Name

Type

Description

Length

Valid values

Is this attribute mandatory?

Image verification

Format Identifier

General Header

Indicates Face representation data

4 bytes

46414300HEX (F A C 0HEX)

yes

Version number

General Header

030 in ASCII

4 bytes

30333000HEX (0 3 0 00HEX)

yes

Length of record

General Header

Includes Face Record Header and Facial Record Data. The minimum of 68 bytes includes the smallest JPEG image

4 bytes

68 ≤ Length of Record ≤ 232 - 1

yes

Number of iris representations

General Header

The total number of iris representations in this record. This shall be recorded in two bytes. A minimum of one representation is required.

2 bytes

1 ... 65,535

yes

Certification flag

General Header

No certification schemes are available for this part of ISO/IEC 19794

1 byte

00HEX

yes

Temperol Sematics

General Header

One representation is present

2 bytes

0000HEX

yes

Representation Length

Representation Header

The representation-length field denotes the length in bytes of the representation including the representation header field.

4 bytes

yes

Capture date and time

Representation Header

9 bytes

yes

No of Quality block

Representation Header

1 byte

10.

Quality block

Representation Header

Quality Score 1 byte Quality algorithm vendor Identifier 2 bytes Quality algorithm Identifier 2 bytes

11.

Face Image Type

Image Information

01HEX Full Frontal

1 byte

12.

Image Data Type

Image Information

01HEX JPEG 2000 (lossy)[AUTH] 02HEX JPEG 2000 (lossless) [REG]

1 byte

yes

13.

Width

Image Information

2 bytes

yes

14.

Height

Image Information

2 bytes

yes

15.

Image Colour Space

Image Information

1 byte

yes

16.

Image Data Length

Image Information

4 bytes

1 to 4 294 967 226

yes

17.

Image Data

Image Information

yes

Iris

Refer ISO 19794-6:2011 Specifications.

Sl.No

Name

Type

Description

Length

Valid values

Is this attribute mandatory?

Image verification

Format Identifier

General Header

The format identifier shall be recorded in four bytes. The format identifier shall consist of three characters IIR, standing for iris image record, followed by a zero byte as a NULL string terminator.

4 bytes

49495200Hex (I I R 00Hex)

yes

Version number

General Header

This number indicates the second version of this part of ISO/IEC 19794 used for constructing the iris image data record and shall be placed in four bytes. This version number shall consist of three ASCII numerals followed by a zero byte as a NULL string terminator

4 bytes

30323000Hex (0 2 0 00Hex)

yes

Length of record

General Header

The length (in bytes) of the entire iris image data record shall be recorded in four bytes. This count shall be the total length of the data block including the iris general header and one or more representation records.

4 bytes

69 to (232-1)

yes

Number of iris representations

General Header

The total number of iris representations in this record. This shall be recorded in two bytes. A minimum of one representation is required.

2 bytes

1 ... 65,535

yes

Certification flag

General Header

No certification schemes are available for this part of ISO/IEC 19794

1 byte

00Hex

yes

Representation Length

Representation Header

The representation-length field denotes the length in bytes of the representation including the representation header field.

4 bytes

yes

Capture date and time

Representation Header

9 bytes

yes

Quality block

Representation Header

A quality record shall consist of a length field followed by zero or more quality blocks. The length field shall consist of one byte. It shall represent the number of quality blocks as an unsigned integer. Each quality block shall consist of – a quality score, – a quality algorithm vendor identifier, and – a quality algorithm identifier. A quality score should express the predicted comparison performance of a representation. A quality score shall be encoded in one byte as an unsigned integer. Allowed values are – 0 to 100 with higher values indicating better quality, – IMAGE_QUAL_FAILED = 255 (FFHex), indicating that an attempt to calculate a quality score failed. The quality algorithm vendor identifier shall identify the provider of the quality algorithm. The quality algorithm vendor identifier shall be encoded in two bytes carrying a CBEFF biometric organization identifier (registered by IBIA or other approved registration authority). A value of all zeros shall indicate that the quality algorithm vendor is unreported. The quality algorithm identifier shall identify the vendor’s quality algorithm that created the quality score. It shall be assigned by the provider of the quality algorithm or an approved registration authority. The quality algorithm identifier shall be encoded in two bytes. A value of all zeros shall indicate that the quality algorithm is unreported.

1 to n bytes

yes

Representation number

RepresentationHeader

Representation sequence number

2 Bytes

yes

10.

Eye label

Representation Header

These refer to the subject's own eyes.

1 byte

yes

11.

Image type

Representation Header

An uncropped rectilinear iris image. A rectilinear iris image in VGA (640x480) format. A cropped, centred, iris image with (0,6R 0,2R) margins. A cropped and region-of-interest masked, centred, iris image with (0,6R 0,2R) margins

1 byte

IMAGE_TYPE_UNCROPPED = 1 (01Hex) IMAGE_TYPE_VGA = 2 (02Hex) IMAGE_TYPE_CROPPED = 3 (03Hex) MAGE_TYPE_CROPPED_AND_MASKED = 7 (07Hex)

yes

12.

Image format

Representation Header

Format of image data

1 byte

IMAGEFORMAT_MONO_RAW = 2 (02Hex) IMAGEFORMAT_MONO_JPEG2000 = 10 (0AHex) IMAGEFORMAT_MONO_PNG = 14 (0EHex)

yes

13.

Image width

Representation Header

Width in pixels

2 bytes

> 0

yes

14.

Image height

Representation Header

Height in pixels

2 bytes

> 0

yes

15.

Bit depth

Representation Header

Bit depth in bits per pixel. (Images having > 8 bpp shall be encoded using PNG or JPEG2000.)

1 byte

At least 8

yes

16.

Image Data Length

Representation Header

Size of the image data (Representation body), in bytes

4 bytes

1 to 4 294 967 226

yes

17.

Image Data

Representation Header

yes

Test Report

Testing Scope

The scope of testing revolved around verifying the compliance of the product as per the specifications published by MOSIP using the below devices:

Registration devices for iris, face and fingerprint
Authentication devices for iris, face and fingerprint

The compliance tool kit was tested with the below biometric specifications:

SBI
SDK
Quality Check
1:N Match
Extraction
Conversion

Test Execution Statistics

88%

50%

Pass Rate (%)

47%

36%

Sonar Report

Test Report

Testing Scope

The scope of testing revolved around verifying the compliance of the product as per the specifications published by MOSIP using the below devices: Registration devices for iris, face and fingerprint Authentication devices for the iris, face and fingerprint The compliance tool kit was tested with the below biometric specifications:

SBI a. Registration b. Authentication
SDK a. Quality Check b. 1: N Match c. Extraction d. Conversion

Test Execution Statistics

Test Rate (%)

88%

50%

88%

Pass Rate (%)

87%

36%

67%

Sonar Report

Test Report

Scope

The scope of testing revolved around verifying the compliance of the product as per the specifications published by MOSIP using the below devices:

The Windows Compliance tool kit was tested with the below specifications:

ABIS (Automated Biometric Identification System) Specifications were tested with Fingerprint, Iris and Face modalities as per MOSIP ABIS API specifications.
Secure Biometric Interface (SBI) with Compliance testcases collection and Quality Assessment testcases collection on below modalities
- Registration devices for Iris, Face and Fingerprint
- Authentication devices for Iris, Face and Fingerprint
Biometric SDK
- Quality Check
- Match
- Extraction
- Conversion

The Android Compliance tool kit app v1.3.0 was tested with the below specifications:

Secure Biometric Interface (SBI) with Compliance testcases collection and Quality Assessment testcases collection on below modalities
- Registration devices for Iris, Face and Fingerprint
- Authentication devices for Iris, Face and Fingerprint

Test Execution Statistics

ABIS Testing

Test cases have been tested with MOSIP mock ABIS for compliance with the MOSIP specifications across 29 test cases.

Scenarios

Mock ABIS

Total

Passed

Pending

Failed

Test Rate (%)

100%

Pass Rate (%)

100%

Out of scope: Real ABIS testing in CTK 1.3.0

SBI Testing

For Android Authentication Devices using MOSIP's Android mock SBI

The Android CTK app v1.3.0 with MOSIP Android Mock SBI has been tested for compliance with the specifications across 55 test cases. Test cases specific to quality and user interactions have been tested with MOSIP Android mock SBI.

Scenarios

Finger

Iris

Face

Total

Passed

Pending

Failed

Test Rate (%)

100%

Pass Rate (%)

100%

90%

100%

For Android Registration Devices using MOSIP's Android mock SBI

The Android CTK app v1.3.0 with MOSIP Android Mock SBI has been tested for compliance with the specifications across 64 test cases. Test cases specific to quality and user interactions have been tested with MOSIP Android mock SBI and real registration face SBI.

Scenarios

Finger

Iris

Face

Total

Passed

Pending

Failed

Test Rate (%)

100%

Pass Rate (%)

100%

For Windows Authentication Devices using MOSIP's Windows mock SBI

The Windows CTK 1.3.0 with MOSIP windows Mock SBI has been tested for compliance with the specifications across 55 authentication spec test cases.

Scenarios

Finger

Iris

Face

Total

Passed

Pending

Failed

Test Rate (%)

100%

Pass Rate (%)

100%

For Windows Registration Devices using MOSIP's windows mock SBI

The Windows CTK 1.3.0 with MOSIP windows Mock SBI has been tested for compliance with the specifications across 76 registration spec test cases.

Scenarios

Finger

Iris

Face

Total

Passed

Pending

Failed

Test Rate (%)

100%

Pass Rate (%)

100%

Out of scope: Real devices testing on Windows and android CTK v1.3.0.

SDK Testing

The SDK implementation has been tested to support quality check, match, extraction, and conversion of biometrics. Test cases have been tested with MOSIP mock SDK.

Scenarios

With Mock SDK

Total

Passed

Pending

Failed

Test Rate (%)

100%

Pass Rate (%)

100%

Out of scope: Segmentation testing and Real SDK testing.

Known Issues

CTK-Keycloak login field names in Arabic are not appearing in RTL.
Forgot Password option is not working in CTK login page.
Error message should be user friendly in CTK sign-in page.
Column name is showing as 'View report'
Getting 500 error for endpoint /v1/authmanager/authorize/invalidateToken in development environment.

Docker version (required for Compliance Tool Kit)

mosipqa/compliance-toolkit-service:1.3.0

mosipqa/compliance-toolkit-ui:1.3.0

mosipqa/postgres-init:1.2.0.1

mosipqa/postgres-init:develop

mosipid/config-server:1.1.2

mosipid/kernel-auditmanager-service:1.2.0.1-B1

mosipid/kernel-auth-service:1.2.0.1-B2

mosipqa/authentication-service:1.2.0.1

mosipid/kernel-keymanager-service:1.2.0.1-B2

mosipid/keycloak-init:1.2.0.1-B2

mosipid/partner-management-service:1.2.0.1-B3

mosipqa/partner-onboarder:develop

mosipid/kernel-notification-service:1.2.0.1-B1

mosipqa/keycloak-init:1.2.0.1

mosipqa/minio-client-util:latest

Sonar Report

MOSIP - Compliance-toolkit-service

MOSIP - compliance-toolkit-ui

1.4.0

Pre-requisites

CTK should be deployed along with the required dockers as mentioned below.

compliance-toolkit-service: 1.4.0
compliance-toolkit-ui: 1.4.0
compliance-toolkit-batch-job: 1.4.0

To successfully deploy Compliance Toolkit, below mentioned services are mandatorily required.

Dependent Service (dockers)

Artifactory: mosipid/artifactory-ref-impl: 1.2.0.1-B2
Audit manager: mosipid/kernel-auditmanager-service: 1.2.0.1-B1
Auth Manager: mosipid/kernel-authmanager: 1.2.0.1-B1
Key Manager: modipid/kernel-keymanager-service: 1.2.0.1-B1
Partner Management: mosipid/partner-management-service: 1.2.0.1-B1
KeyCloak: mosipid/keycloak-init: 1.2.0.1-B1
Postgres: mosipid/postgres-init: 1.2.0.1-B1
Config Server: config-server: mosipid/config-server: 1.1.2
Notification Service: mosipid/kernel-notification-service: 1.2.0.1-B1
ClamAV: clamav/clamav: latest
MinIO

The Setup guide serves as a checklist for the following three categories.

Configuration checks
Steps to load testdata, schemas, testcases and terms and conditions templates
Steps to generate Android APK

Configuration checks

Make sure that the kernel-default.properties file includes the mosip-toolkit-client and mosip-toolkit-android-client values in the auth.server.admin.allowed.audience setting. If these values are not set by default, configure them and then restart the kernel-auth-service and compliance-toolkit-service.
Ensure that in compliance-toolkit-default.properties, CORS is enabled to allow access to mosip-toolkit-android-client:
```
 mosip.security.cors-enable=true
 mosip.security.origins=http://localhost
 auth.server.admin.allowed.audience=mosip-toolkit-client,mosip-toolkit-android-client
```
If this was not set by default, then set it and restart compliance-toolkit-service.
Check if the roles given to mosip-pms-client match with any of the roles for the following config property: mosip.role.keymanager.postverifycertificatetrust=XXX
This config property is available here.
For Example:
mosip.role.keymanager.postverifycertificatetrust=ZONAL_ADMIN, GLOBAL_ADMIN, PMS_ADMIN, PMS_USER
Ensure that the mosip-pms-client possesses any of the roles mentioned above.
Check that mosip-pms-client has the role REGISTRATION_PROCESSOR, PARTNER_ADMIN, PMS_ADMIN in Key Cloak. If this was not set by default, then set it and restart keymanager and compliance-toolkit-service.
It is also needed to generate an encryption key for CTK.
- Insert the following row to create a new app ID.
  INSERT INTO keymgr.key_policy_def(app_id, key_validity_duration, is_active,pre_expire_days, access_allowed, cr_by, cr_dtimes, upd_by, upd_dtimes, is_deleted, del_dtimes) VALUES ('COMPLIANCE_TOOLKIT', 1095, true, 60, 'NA', 'mosipadmin', '2022-11-28 09:00:40.822625', null, null, false, null);
- Using the auth manager swagger URL, obtain the client token.
  Swagger URL:
  `https://api-internal.${env}.mosip.net/v1/authmanager/swagger-ui/index.html?configUrl=/v1/authmanager/v3/api-docs/swagger-config`
  Endpoint:
  `/authenticate/clientidsecretkey`
  Request:
  { "id": "string", "version": "string", "requesttime": "2022-12-22T07:13:35.010Z", "metadata": {}, "request": { "clientId": " mosip-pms-client ", "secretKey": " XXXXXX ", "appId": " partner " } }
- Now using the key manager swagger URL, generate module level certificate.
  Swagger URL:
  `https://api-internal.${env}.mosip.net/v1/keymanager/swagger-ui/index.html?configUrl=/v1/keymanager/v3/api-docs/swagger-config`
  Endpoint:
  `/generateMasterKey/Certificate`
  Request:
- Directly download the certificate through key manager swagger URL and getCertificate endpoint, with App Id as COMPLIANCE_TOOLKIT and Ref Id as COMP-FIR.
- This certificate serves as the encryption key specifically for SBI devices.
  For Mock MDS, when running in Auth mode: update the below values in the application.properties file.
  mosip.auth.appid=regproc mosip.auth.clientid=mosip-pms-client mosip.auth.secretkey=XXXXXXXXXXXXXXXX mosip.auth.server.url=https://api-internal.${env}.mosip.net/v1/authmanager/authenticate/clientidsecretkey mosip.ida.server.url=https://api-internal.${env}.mosip.net/v1/keymanager/getCertificate?applicationId=COMPLIANCE_TOOLKIT&referenceId=COMP-FIR
  For real MDS/SBI, the vendors can download the new encryption key from the UI and test with the updated SBI which uses this encryption key. It can be downloaded for Auth SBI projects from UI.
Ensure that reporting module is deployed from the develop branch. This is required for the Kibana Dashboard.
Ensure that the kernel-auth-adapter-1.2.0.1 has been successfully deployed in the compliance-toolkit-service, and verify that the identical authentication adapter was utilized to configure the mock ABIS.
Check datashare configurations for ABIS3030 and ABIS3031 testcases.
- Ensure that in data-share-default.properties and compliance-toolkit-default.properties, the value of mosip-abis-client is set in auth.server.admin.allowed.audience. If this was not set by default, then set it and restart data-share-service and compliance-toolkit-service.
- For handle CTK datashare token flow, add the below values in data-share-default.properties.
  auth.handle.ctk.flow=true mosip.api.internal.toolkit.url=https://${mosip.api.internal.host}/v1/toolkit mosip.compliance.toolkit.saveDataShareToken.url=${mosip.api.internal.toolkit.url}/saveDataShareToken mosip.compliance.toolkit.invalidateDataShareToken.url=${mosip.api.internal.toolkit.url}/invalidateDataShareToken mosip.compliance.toolkit.invalidateDataShareToken.testCaseId=ABIS3031

Steps to load testdata, schemas in MINIO

1. Browse mosip-compliance-toolkit

2. Project structure will be displayed as mentioned below.

3. The resources folder has schemas and test data that need to be added to MinIO.

Steps to load testdata and schemas directly in MinIO

1. Log in to MinIO from the browser.

2. Create a compliance-toolkit bucket.

3. Create a new folder named testdata in the above bucket.Upload MOSIP_DEFAULT_XXX.zip files from resources to it.

4. Create a new folder named schemas in the above bucket. Upload all SBI, SDK and ABIS schemas along with subfolders in it.

5. Upload testcase_schema.json from resources folder to schemas folder.

6. Please restart the compliance pods after adding new files in minio to refresh the cache.

Alternately, swagger endpoint can also be used to upload data in Minio. In this case there is no need to restart CTK services.

Steps to upload resources to Minio using Swagger

1. The swagger url is:

https://{api-internal-env-url}/v1/toolkit/swagger-ui/index.html?configUrl=/v1/toolkit/v3/api-docs/swagger-config

2. Using keycloak/ register option in CTK UI, create a new user for compliance toolkit.

3. Make sure to add the email ID. Also, give the role CTK_ADMIN.

4. Login to compliance toolkit in your environment from browser with the above Keycloak user.

5. Go to ResourceManagementController in swagger and upload the schema alongwith testdata files.

6. Then, select any one of type mentioned above and also mention the version (SBI/SDK/ABIS Version).

7. Select the type of required file which you want to upload from resources folder in project.

8. After execution you can see the response.

9. Check inside the Minio, in dev environment, whether the files have been uploaded into it.

Steps to upload test cases to the Database

1. Open swagger and go to saveTestCases endpoint in test-cases-controller.

2. Currently, CTK has a separate repository called compliance-toolkit-testcases, which includes the testcases for the SBI, SDK and ABIS.

3. Open compliance-toolkit-testcases repo.

4. compliance_test_definitions_sbi.json file have all the test cases in it.

5. Copy test cases array from this file and prepare a request as shown below.

6. Request body for saveTestCases request.

{
   "id": "mosip.toolkit.projects.retrieve",
   "version": "1.0",
   "requesttime": "2022-10-29T06:06:51.174Z",
   "metadata": null,
   "request": {
      "testCases": [
         <Paste the testcases here>
      ]
   }
}

7. Then, execute it.

8. The same should be done for compliance_test_definitions_sdk.json and compliance_test_definitions_abis.json.

Steps to upload terms and conditions velocity templates to the Database

Open swagger and go to uploadTemplate endpoint in resource-management-controller.
Provide the required parameters:
- Specify the language for the template using ISO 639 standard language codes.
- Enter the version of the template. (the template version should be in format as v1,v2,v3 and so on)
- Enter the template name as terms_and_conditions_template.
The template file extension should be.vm(Velocity Template Language).
Then , execute it

Steps to generate Android APK

Once all the steps mentioned above are completed, you can trigger the Android APK build for your environment. https://github.com/mosip/mosip-compliance-toolkit-ui/actions/workflows/android.yml
You may need GitHub repository write access.
Add values for the URL’s according to your deployment env.

0.0.9

Pre-requisites

CTK should be deployed with the required dockers.

compliance-toolkit-service: 0.0.9-B1
compliance-toolkit-ui: 0.0.9-B1

Dependent Service (dockers)

Artifactory: mosipid/artifactory-ref-impl: 1.2.0.1-B2
Audit manager: mosipid/kernel-auditmanager-service: 1.2.0.1-B1
Auth Manager: mosipid/kernel-authmanager: 1.2.0.1-B1
Key Manager: modipid/kernel-keymanager-service: 1.2.0.1-B1
Partner Management: mosipid/partner-management-service: 1.2.0.1-B1
KeyCloak: mosipid/keycloak-init: 1.2.0.1-B1
Postgres: mosipid/postgres-init: 1.2.0.1-B1
Config Server: config-server: mosipid/config-server: 1.1.2
Notification Service: mosipid/kernel-notification-service: 1.2.0.1-B1
ClamAV: clamav/clamav: latest
MinIO

Note:

Ensure that in the kernel-default.properties, the value of mosip-toolkit-client is set in auth.server.admin.allowed.audience. If this was not set by default, then set it and restart kernel-auth-service and compliance-toolkit-service.
Check if the roles given to mosip-pms-client should match with any of the roles for following config property.
```
    mosip.role.keymanager.postverifycertificatetrust=XXX
```
This config property is available in: https://github.com/mosip/mosip-config/blob/${ENV_NAME}/kernel-default.properties
For Example:
mosip.role.keymanager.postverifycertificatetrust=ZONAL_ADMIN, GLOBAL_ADMIN, PMS_ADMIN, PMS_USER
Then mosip-pms-client should have any of the above roles.

Steps to setup mosip-compliance-toolkit

1. Browse to mosip-compliance-toolkit.

2. The resources folder would contain schemas, test data and test cases that need to be added to MinIO and DB.

Steps to upload resources to MinIO

1. Log in to MinIO from the browser.

2. Create a compliance-toolkit bucket.

3. Create a new folder named testdata in the above bucket and upload all test data zip files from the resources folder to this folder.

4. Create a new folder named schemas in the above bucket and upload all sbi and sdk schemas, testcase schema from the resources folder to this folder.

Note: There is no need to upload compliance_test_definitions_sbi.json and compliance_test_definitions_sdk.json.

5. Restart the pods after adding new files in MinIO.

Using Postman

1. Using Keycloak, create a new user for the compliance toolkit.

2. Make sure to add the email ID. Also, give the user GLOBAL_ADMIN.

3. Log in to the compliance toolkit in your environment with above the Keycloak user.

4. Open the developer tools and copy the Authorization token from the headers section under the Networks tab.

5. Add the Authorization token in postman, copy the token and place it in the headers section of the request (Cookie=Authentication:eyAjksa...) and send the request.

Steps to upload test cases to the Database

1. Open postman and create a POST request.

2. URL endpoint https://{base_URL}/v1/toolkit/saveTestCases

3. Copy the Authorization token in the request header as mentioned in the Using Postman section.

4. Open the resources folder in the project.

5. compliance_test_definitions_sbi.json file has all the test cases in it.

6. Copy the test cases array from this file and prepare a request as shown below.

7. Request body for saveTestCases request

{
    "version": "1.0",
    "requesttime": "2022-10-29T06:06:51.174Z",
    "metadata": null,
    "request": {
        "testCases": [
<Paste the testcases here>
                     ]
               }
}

8. Change the requesttime to the current day and send the request.

9. The same should be done for compliance_test_definitions_sdk.json.

1.3.0

Pre-requisites

CTK should be deployed with the required dockers.

compliance-toolkit-service: 1.3.0
compliance-toolkit-ui: 1.3.0

To deploy Compliance Toolkit, we require the below mandatory services:

Dependent Service (dockers)

Artifactory: mosipid/artifactory-ref-impl: 1.2.0.1-B2
Audit manager: mosipid/kernel-auditmanager-service: 1.2.0.1-B1
Auth Manager: mosipid/kernel-authmanager: 1.2.0.1-B1
Key Manager: modipid/kernel-keymanager-service: 1.2.0.1-B1
Partner Management: mosipid/partner-management-service: 1.2.0.1-B1
KeyCloak: mosipid/keycloak-init: 1.2.0.1-B1
Postgres: mosipid/postgres-init: 1.2.0.1-B1
Config Server: config-server: mosipid/config-server: 1.1.2
Notification Service: mosipid/kernel-notification-service: 1.2.0.1-B1
ClamAV: clamav/clamav: latest
MinIO

The Setup guide is a checklist for the three categories below:

Configuration checks
Steps to load testdata, schemas and testcases
Steps to generate Android APK

Configuration checks

Ensure that in the kernel-default.properties, the value of mosip-toolkit-client and mosip-toolkit-android-client is set in auth.server.admin.allowed.audience. If this was not set by default, then set it and restart kernel-auth-service and compliance-toolkit-service.
Ensure that in compliance-toolkit-default.properties, CORS is enabled to allow access to mosip-toolkit-android-client:
```
 mosip.security.cors-enable=true
 mosip.security.origins=http://localhost
 auth.server.admin.allowed.audience=mosip-toolkit-client,mosip-toolkit-android-client
```
If this was not set by default, then set it and restart compliance-toolkit-service.
Check if the roles given to mosip-pms-client match with any of the roles for the following config property: mosip.role.keymanager.postverifycertificatetrust=XXX
This config property is available here.
For Example:
mosip.role.keymanager.postverifycertificatetrust=ZONAL_ADMIN, GLOBAL_ADMIN, PMS_ADMIN, PMS_USER
Then mosip-pms-client should have any of the above roles.
Check that mosip-pms-client has the role REGISTRATION_PROCESSOR, PARTNER_ADMIN, PMS_ADMIN in Key Cloak. If this was not set by default, then set it and restart keymanager and compliance-toolkit-service.
It is also needed to generate an encryption key for CTK.
- Create a new app id by directly inserting the below row.
  INSERT INTO keymgr.key_policy_def(app_id, key_validity_duration, is_active,pre_expire_days, access_allowed, cr_by, cr_dtimes, upd_by, upd_dtimes, is_deleted, del_dtimes) VALUES ('COMPLIANCE_TOOLKIT', 1095, true, 60, 'NA', 'mosipadmin', '2022-11-28 09:00:40.822625', null, null, false, null);
- Using the auth manager swagger URL, obtain the client token.
  Swagger URL:
  `https://api-internal.${env}.mosip.net/v1/authmanager/swagger-ui/index.html?configUrl=/v1/authmanager/v3/api-docs/swagger-config`
  Endpoint:
  `/authenticate/clientidsecretkey`
  Request:
  { "id": "string", "version": "string", "requesttime": "2022-12-22T07:13:35.010Z", "metadata": {}, "request": { "clientId": " mosip-pms-client ", "secretKey": " XXXXXX ", "appId": " partner " } }
- Now using the key manager swagger URL, generate module level certificate.
  Swagger URL:
  `https://api-internal.${env}.mosip.net/v1/keymanager/swagger-ui/index.html?configUrl=/v1/keymanager/v3/api-docs/swagger-config`
  Endpoint:
  `/generateMasterKey/Certificate`
  Request:
- Directly download the certificate via key manager swagger URL and getCertificate endpoint, with App Id as COMPLIANCE_TOOLKIT and Ref Id as COMP-FIR.
- This certificate is to be used by SBI devices as the encryption key.
  For Mock MDS, when running in Auth mode: update the below values in the application.properties file.
  mosip.auth.appid=regproc mosip.auth.clientid=mosip-pms-client mosip.auth.secretkey=XXXXXXXXXXXXXXXX mosip.auth.server.url=https://api-internal.${env}.mosip.net/v1/authmanager/authenticate/clientidsecretkey mosip.ida.server.url=https://api-internal.${env}.mosip.net/v1/keymanager/getCertificate?applicationId=COMPLIANCE_TOOLKIT&referenceId=COMP-FIR
  For real MDS/SBI, the vendors can download the new encryption key from the UI and test with the updated SBI which uses this encryption key.It can be downloaded for Auth SBI projects from UI.
Ensure that reporting module is deployed from the develop branch. This is required for the Kibana Dashboard.

Steps to load testdata, schemas in MINIO

1. Browse mosip-compliance-toolkit

2. Project structure will be as shown below.

3. The resources folder has schemas, test data and testcases that need to be added to MinIO and DB.

Steps to load testdata and schemas directly in MinIO

1. Log in to MinIO from the browser.

2. Create a compliance-toolkit bucket.

3. Create a new folder named testdata in the above bucket.Upload MOSIP_DEFAULT_XXX.zip files from resources to it.

4. Create a new folder named schemas in the above bucket. Upload all SBI, SDK and ABIS schemas along with subfolders in it.

5. Upload testcase_schema.json from resources folder to schemas folder.

6. There is no need to upload compliance_test_definitions_sbi.json ,compliance_test_definitions_sdk.json and compliance_test_definitions_abis.json

7. Please restart the compliance pods after adding new files in minio to refresh the cache.

Alternately, swagger endpoint can also be used to upload data in Minio. In this case there is no need to restart CTK services.

Steps to upload resources to Minio using Swagger

1. The swagger url is:

https://{api-internal-env-url}/v1/toolkit/swagger-ui/index.html?configUrl=/v1/toolkit/v3/api-docs/swagger-config

2. Using keycloak/ register option in CTK UI, create a new user for compliance toolkit.

3. Make sure to add the email ID. Also, give the role CTK_ADMIN.

4. Login to compliance toolkit in your environment from browser with the above Keycloak user.

5. Go to ResourceManagementController in swagger and upload the schema alongwith testdata files.

6. Then, select any one of type mentioned above and also mention the version (SBI/SDK/ABIS Version).

7. Select the type of required file which you want to upload from resources folder in project.

8. After execution you can see the response.

9. Check inside the Minio, in dev environment, whether the files have been uploaded into it.

Steps to upload test cases to the Database

1. Open swagger and go to saveTestCases in test-cases-controller.

2. Open resources folder in project.

3. compliance_test_definitions_sbi.json file have all the test cases in it.

4. Copy test cases array from this file and prepare a request as shown below.

5. Request body for saveTestCases request.

{
   "id": "mosip.toolkit.projects.retrieve",
   "version": "1.0",
   "requesttime": "2022-10-29T06:06:51.174Z",
   "metadata": null,
   "request": {
      "testCases": [
         <Paste the testcases here>
      ]
   }
}

6. Then, execute it.

7. The same should be done for compliance_test_definitions_sdk.json and compliance_test_definitions_abis.json.

Steps to generate Android APK

Once all the steps mentioned above are completed, you can trigger the Android APK build for your environment. https://github.com/mosip/mosip-compliance-toolkit-ui/actions/workflows/android.yml
You may need GitHub repository write access.
Add values for the URL’s according to your deployment env.

1.1.0

Pre-requisites

CTK should be deployed with the required dockers.

compliance-toolkit-service: 1.1.0
compliance-toolkit-ui: 1.1.0

To deploy Compliance Toolkit, we require only below mandatory services:

Dependent Service (dockers)

Artifactory: mosipid/artifactory-ref-impl: 1.2.0.1-B2
Audit manager: mosipid/kernel-auditmanager-service: 1.2.0.1-B1
Auth Manager: mosipid/kernel-authmanager: 1.2.0.1-B1
Key Manager: modipid/kernel-keymanager-service: 1.2.0.1-B1
Partner Management: mosipid/partner-management-service: 1.2.0.1-B1
KeyCloak: mosipid/keycloak-init: 1.2.0.1-B1
Postgres: mosipid/postgres-init: 1.2.0.1-B1
Config Server: config-server: mosipid/config-server: 1.1.2
Notification Service: mosipid/kernel-notification-service: 1.2.0.1-B1
ClamAV: clamav/clamav: latest
MinIO

The Setup guide is a checklist for the three categories below:

Configuration Checks
Steps to load testdata, schemas and testcases
Steps to generate Android APK

Configuration checks

Ensure that in the kernel-default.properties, the value of mosip-toolkit-client and mosip-toolkit-android-client is set in auth.server.admin.allowed.audience. If this was not set by default, then set it and restart kernel-auth-service and compliance-toolkit-service.
Ensure that in compliance-toolkit-default.properties, CORS is enabled to allow access to mosip-toolkit-android-client:
```
 mosip.security.cors-enable=true
 mosip.security.origins=http://localhost
 auth.server.admin.allowed.audience=mosip-toolkit-client,mosip-toolkit-android-client
```
If this was not set by default, then set it and restart compliance-toolkit-service.
Check if the roles given to mosip-pms-client match with any of the roles for the following config property: mosip.role.keymanager.postverifycertificatetrust=XXX
This config property is available here.
For Example:
mosip.role.keymanager.postverifycertificatetrust=ZONAL_ADMIN, GLOBAL_ADMIN, PMS_ADMIN, PMS_USER
Then mosip-pms-client should have any of the above roles.
Check that mosip-pms-client has the role REGISTRATION_PROCESSOR, PARTNER_ADMIN, PMS_ADMIN in Key Cloak. If this was not set by default, then set it and restart keymanager and compliance-toolkit-service.
From the CTK v 1.0.0 version onwards, we need to generate an encryption key for CTK.
- Create a new app id by directly inserting the below row.
  INSERT INTO keymgr.key_policy_def(app_id, key_validity_duration, is_active,pre_expire_days, access_allowed, cr_by, cr_dtimes, upd_by, upd_dtimes, is_deleted, del_dtimes) VALUES ('COMPLIANCE_TOOLKIT', 1095, true, 60, 'NA', 'mosipadmin', '2022-11-28 09:00:40.822625', null, null, false, null);
- Using the auth manager swagger URL, get the client token.
  Swagger URL:
  `https://api-internal.${env}.mosip.net/v1/authmanager/swagger-ui/index.html?configUrl=/v1/authmanager/v3/api-docs/swagger-config`
  Endpoint:
  `/authenticate/clientidsecretkey`
  Request:
  { "id": "string", "version": "string", "requesttime": "2022-12-22T07:13:35.010Z", "metadata": {}, "request": { "clientId": " mosip-pms-client ", "secretKey": " XXXXXX ", "appId": " partner " } }
- Now using the key manager swagger URL, generate module level certificate.
  Swagger URL:
  `https://api-internal.${env}.mosip.net/v1/keymanager/swagger-ui/index.html?configUrl=/v1/keymanager/v3/api-docs/swagger-config`
  Endpoint:
  `/generateMasterKey/Certificate`
  Request:
- Directly download the certificate via key manager swagger URL and getCertificate endpoint, with App Id as COMPLIANCE_TOOLKIT and Ref Id as COMP-FIR.
- This certificate is to be used by SBI devices as the encryption key.
  For Mock MDS, when running in Auth mode: update the below values in the application.properties file.
  mosip.auth.appid=regproc mosip.auth.clientid=mosip-pms-client mosip.auth.secretkey=XXXXXXXXXXXXXXXX mosip.auth.server.url=https://api-internal.${env}.mosip.net/v1/authmanager/authenticate/clientidsecretkey mosip.ida.server.url=https://api-internal.${env}.mosip.net/v1/keymanager/getCertificate?applicationId=COMPLIANCE_TOOLKIT&referenceId=COMP-FIR
  For real MDS/SBI, the vendors can download the new encryption key from the UI and test with the updated SBI which uses this encryption key.It can be downloaded for Auth SBI projects from UI.

Steps to load testdata, schemas in MINIO

1. Browse mosip-compliance-toolkit

2. Project structure will be as shown below.

3. The resources folder has schemas, test data and testcases that need to be added to MinIO and DB.

Steps to load testdata and schemas directly in MinIO

1. Log in to MinIO from the browser.

2. Create a compliance-toolkit bucket.

3. Create a new folder named testdata in the above bucket.Upload MOSIP_DEFAULT_XXX.zip files from resources to it.

4. Create a new folder named schemas in the above bucket. Upload all SBI and SDK schemas along with subfolders in it.

5. Upload testcase_schema.json from resources folder to `schemas folder.

6. There is no need to upload compliance_test_definitions_sbi.json & compliance_test_definitions_sdk.json

7. Please restart the compliance pods after adding new files in minio to refresh the cache.

Alernately swagger endpoint can also be used to upload data in Minio. In this case there is no need to restart CTK services.

Steps to upload resources to MinIO using Swagger

1. The swagger url is:

https://{api-internal-env-url}/v1/toolkit/swagger-ui/index.html?configUrl=/v1/toolkit/v3/api-docs/swagger-config

2. Using keycloak/ register option in CTK UI create a new user for compliance toolkit.

3. Make sure to add the email ID. Also, give the role GLOBAL_ADMIN.

4. Login to compliance toolkit in your environment from browser with above the Keycloak user.

5. Go to ResourceManagementController in swagger, there you need to upload schema and testdata files.

6. Then you have to choose any one of the types which is mentioned above and also mention the version (SBI/SDK Version).

7. Select the type of required file which you want to upload from resources folder in project.

8. After execution you can see the response.

9. Check inside the MinIo in dev environment whether the files have been uploaded into it.

Steps to upload test cases to the Database

1. Open swagger and go to saveTestCases in test-cases-controller.

2. Open resources folder in project.

3. compliance_test_definitions_sbi.json file have all the test cases in it.

4. Copy test cases array from this file and prepare a request as shown below.

5. Request body for saveTestCases request.

{
   "id": "mosip.toolkit.projects.retrieve",
   "version": "1.0",
   "requesttime": "2022-10-29T06:06:51.174Z",
   "metadata": null,
   "request": {
      "testCases": [
         <Paste the testcases here>
      ]
   }
}

6. Then execute it.

7. Same should be done for compliance_test_definitions_sdk.json.

Steps to generate Android APK

Once all the steps mentioned above are completed, you can trigger the Android APK build for your env https://github.com/mosip/mosip-compliance-toolkit-ui/actions/workflows/android.yml
You may need GitHub repository write access.
Add values for the URL’s according to your deployment env.

CTK Validators

SBI Validators

Name

Description

Test with Mock SBI

SchemaValidator

Validates the response for mandatory attributes and correct values.

SignatureValidator

Validates the response signature.

ResponseMisMatchValidator

Validates the response to check if bioCount, exceptions, segments and transactionId match the ones set in request.

KeyRotationValidator

Validator to validate the device key rotation.

TimeoutValidator

Validates if response is received within the given timeout period or not.

To test Timeout testcases with Mock SBI: Call POST API: http://127.0.0.1:4501/admin/delay With request body, { "type": "Biometric Device", "delay": "10000", "method": [ "RCAPTURE"] } To test Force Capture testcases with Mock SBI: Call POST API: http://127.0.0.1:4501/admin/delay With request body, { "type": "Biometric Device", "delay": "9500", "method": [ "RCAPTURE"] } Please try to increase the delay gradually to execute the testcase successfully.

ISOStandardsValidator

Validates the bioValue in response of rcapture is as per ISO standards ISO19794-4:2011.

ISO standard validation with proper ISO file by using mock MDS: • Under an SBI project, create a collection by selecting ISO standard testcases. • Run the mock MDS/SBI with standard ISO files. Perform a Scan and select the appropriate device. • Run the ISO collection and verify the result status. ISO standard validation should be success. ISO standard validation with Non-ISO files by using mock MDS: • Under an SBI project, create a collection by selecting ISO standard testcases. • Run the mock MDS/SBI with Non-ISO standard files (In Default folder replace standard ISO file with Non-ISO file). Perform a Scan and select the appropriate device. • Run the ISO collection and verify the result status. ISO standard validation should be fail.

BiometricsQualityCheckValidator

Checks the quality of biometrics using all configured SDK services.

Biometrics quality check validation with good quality biometric: • In compliance-toolkit-default.properties, configure Bio SDK service and health check URLs under mosip.toolkit.sbi.qualitycheck.finger.sdk.urls property. Restart CTK pods/services. Example: mosip.toolkit.sbi.qualitycheck.finger.sdk.urls=[{"name": "Mock SDK qa-1201-b2 Env","url": "https://api-internal.qa-1201-b2.mosip.net/biosdk-service","healthUrl": "https://api-internal.qa-1201-b2.mosip.net/biosdk-service/actuator/health", "includeInResults":true}] • Add Biometric quality testcase in CTK for all modalities (FP, Iris and Face for both Reg and Auth). • Run Mock MDS and increase biometric quality score to get more than threshold value. • In CTK scan the biometric devices and run the Biometric quality check testcases. • After testcase execution is done, please check testcase result status. Biometric quality check validator should pass. Biometrics quality check validation with poor qualitybiometric: • Change the biometric quality score to less than the threshold value and run the Biometric quality check testcases. • After testcase execution is done, please check testcase result status. Biometric quality check validator should fail because quality score is less than threshold.

TimeCheckValidator

Validates if response is received within the given timestamp interval or not.

HashValidator

Validates the 'hash value' received in the response matches 'previous hash' in request.

SDK Validators

Name

Description

Test with Mock SDK

SchemaValidator

Validates if response has all mandatory attributes and they have allowed values.

QualityCheckValidator

Checks the quality score of the modality.

QualityCheckInvalidDataValidator

Validates the status code for invalid data.

QualityCheckNoDataValidator

Validates the status code for no data.

MatchValidator

Validates if biomterics match for the modality.

MatchInvalidDataValidator

Validates the status code for invalid data.

MatchNoDataValidator

Validates the status code for no data.

MatchMultipleGalleryValidator

Validates if biomterics match for the modality.

ExtractTemplateValidator

Validates if input BDB data present in the Probe for the modality is valid.

ExtractTemplateInvalidDataValidator

Validates if input BDB data present in the Probe for the modality is valid.

ExtractTemplateNoInputDataValidator

Validates if no input BDB data present in the Probe.

ConvertDataValidator

Validates the input BDB data present in the Probe.

ConvertInvalidDataValidator

Validates if input BDB data present in the Probe for the modality is valid.

ConvertNoInputDataValidator

Validates if no input BDB data present in the Probe.

ABIS Validators

Name

Description

Test with Mock ABIS

SchemaValidator

Validates if response has all mandatory attributes and they have allowed values.

ExpectedFailureReasonValidator

Validates the failure reason to match the expected value

IdentifyDuplicateFoundValidator

Validates the count of duplicates found by ABIS for the given referenceId

ExpectedDuplicateCountValidator

Validates the duplicates found to match the expected value.

ABISTokenValidator

Validates that ABIS is not generating a new token for every insert request, unless token has expired.

Test Report

Scope

The scope of testing revolved around verifying the compliance of the product as per the specifications published by MOSIP using the below devices:

The Windows Compliance tool kit was tested with the below specifications:

ABIS (Automated Biometric Identification System) Specifications were tested with Fingerprint, Iris and Face modalities as per MOSIP ABIS API specifications.
Secure Biometric Interface (SBI) with Compliance testcases collection and Quality Assessment testcases collection on below modalities
- Registration devices for Iris, Face and Fingerprint
- Authentication devices for Iris, Face and Fingerprint
Biometric SDK
- Quality Check
- Match
- Extraction
- Conversion

The Android Compliance tool kit app v1.4.0 was tested with the below specifications:

Secure Biometric Interface (SBI) with Compliance testcases collection and Quality Assessment testcases collection on below modalities
- Registration devices for Iris, Face and Fingerprint
- Authentication devices for Iris, Face and Fingerprint

Test Execution Statistics

ABIS Testing

Test cases have been tested with MOSIP mock ABIS for compliance with the MOSIP specifications across 29 test cases.

Scenarios

Mock ABIS

Total

Passed

Pending

Failed

Test Rate (%)

100%

Pass Rate (%)

100%

Out of scope: Real ABIS testing in CTK 1.4.0

SBI Testing

For Android Authentication Devices using MOSIP's Android mock SBI

The ‘Android CTK app v1.4.0’ with ‘MOSIP Android Mock SBI’ has been tested for compliance with the specifications. Test cases specific to quality and user interactions have been tested with MOSIP Android mock SBI.

Scenarios

Finger

Iris

Face

Total

Passed

Pending

Failed

Test Rate (%)

100%

Pass Rate (%)

100%

90%

100%

For Android Registration Devices using MOSIP's Android mock SBI

The Android CTK app v1.4.0 with MOSIP Android Mock SBI has been tested for compliance with the specifications. Test cases specific to quality and user interactions have been tested with MOSIP Android mock SBI and real registration face SBI.

Scenarios

Finger

Iris

Face

Total

Passed

Pending

Failed

Test Rate (%)

100%

Pass Rate (%)

100%

For Windows Authentication Devices using MOSIP's Windows mock SBI

The Windows CTK 1.4.0 with MOSIP windows Mock SBI has been tested for compliance with the specifications.

Scenarios

Finger

Iris

Face

Total

Passed

Pending

Failed

Test Rate (%)

100%

Pass Rate (%)

100%

For Windows Registration Devices using MOSIP's windows mock SBI

The Windows CTK 1.4.0 with MOSIP windows Mock SBI has been tested for compliance with the specifications.

Scenarios

Finger

Iris

Face

Total

Passed

Pending

Failed

Test Rate (%)

100%

Pass Rate (%)

100%

Out of scope: Real devices testing on Windows and android CTK v1.4.0.

SDK Testing

The SDK implementation has been tested to support quality check, match, extraction, and conversion of biometrics. Test cases have been tested with MOSIP mock SDK.

Scenarios

With Mock SDK

Total

Passed

Pending

Failed

Test Rate (%)

100%

Pass Rate (%)

100%

Out of scope: Segmentation testing and Real SDK testing.

Docker version (required for Compliance Tool Kit)

mosipqa/compliance-toolkit-batch-job:1.4.0

mosipqa/compliance-toolkit-service:1.4.0

mosipqa/compliance-toolkit-ui:1.4.0

mosipqa/postgres-init:develop

mosipid/config-server:1.1.2

mosipid/kernel-auditmanager-service:1.2.0.1-B1

mosipid/kernel-auth-service:1.2.0.1-B2

mosipqa/authentication-internal-service:release-1.2.0.1

mosipqa/authentication-otp-service:release-1.2.0.1

mosipqa/authentication-service:release-1.2.0.1

mosipid/kernel-keymanager-service:1.2.0.1-B2

mosipqa/keycloak-init:develop

mosipid/partner-management-service:1.2.0.1-B3

mosipqa/partner-onboarder:develop

mosipid/kernel-notification-service:1.2.0.1-B1

Known Issues

Currently, ABIS partners can successfully create SBI and SDK projects in CTK 1.4.0, although role-based constraints to restrict this functionality is planned for future release

Sonar Report

MOSIP - Compliance-toolkit-service

MOSIP - compliance-toolkit-ui

User Guide

This guide will help the partners in using the Compliance Took Kit portal.

Below are simple steps to use this portal:

The partners using the compliance tool kit should be registered partners in the system.
Login into CTK with the same credentials.
Partner can also select their preferred language while logging-in.
Create a project of type SBI / SDK / ABIS.
Create a collection by selecting the test cases that you want to test.
Provide the necessary details to connect to your device / SDK / ABIS service.
Execute the Test Run by running the collection.
For executing each test case, follow the instructions on the screen.
Once the entire collection is run, the results of the number of test cases passed or failed will be displayed.
You can see all the Test Run details as well. For example, the request sent to SBI, the response received from SBI, validations performed on the response and the result.
Test runs previously executed will be available in the Test Run history.
More collections can be created as per the test cases required.

Compliance Toolkit Landing Page

On the CTK landing page, partners can view the introduction of the CTK portal and watch a video about CTK. Additionally, they can login or register by clicking the respective buttons. The landing page also provides links to other resources such as the GitHub repository, documentation, and partner details.

Additionally, it showcases several robust features of CTK, including its pre-defined test cases, validation mechanisms, and comprehensive reporting.

The landing page offers details about the SBI, Android SBI, SDK, and ABIS specifications. Furthermore, partners have the option to download the compliance toolkit APK by choosing the download button.

Partners utilizing the compliance toolkit must be registered in the system. Once registered, partners can log in to the compliance toolkit using the same credentials they used for registration in the Partner Management Portal.

The partner needs to enter the registered username or e-mail and password to log in.

The partner can select the language of their preference from the dropdown in the top-right corner of the screen. Thereafter, the application is displayed in the selected language. By default, CTK supports the following languages:

English
French
Arabic

Note: After registering, partners need to login the partner management portal to retrieve partner details.

After logging in, partners will encounter a Terms & Conditions popup window. Partner must accept these terms; otherwise, they will be logged out.

Also, upon logging in, partners will be prompted with a popup if there have been any changes to the Terms & Conditions since their last consent.

Dashboards

After accepting the Terms & Conditions, partners gain access to the Project Dashboard by default. Additionally, they have the option to explore the Biometric Data Dashboard and My Reports Dashboard.

Project: A project is a module that the partner wants to test. For example, if a device partner has developed a new version of their SBI for the fingerprint slap device, then, they can create a project in the compliance tool kit to verify this version of SBI.

Biometric Data: As a part of the CTK, there is an option for the partner to upload their test data which can be used to verify the partner’s software. Currently, in MOSIP, we can upload test data for an SDK and ABIS.

My Reports: Partners of CTK will be able to view the reports that they have submitted for review as well as the status of those reports.

Project dashboard

Below are the possible activities as part of the Project Dashboard.

View all the projects on the dashboard
Create a new project
View a specific project
Archive a project
Move to the biometric data dashboard

Let us go through each of them in detail.

View projects

Once the partner logs into the compliance tool kit, they can view all the existing projects in the dashboard.

The project dashboard will display the following attributes of a project:

Name of the project
Project Type
Total number of collections in the project
Creation date and time of the project
Last time a collection in the project was run
Status of the last run on the project

The filter option in the dashboard will filter based on the name of the project, project type and the creation date and time.

Create a project

On the Projects Dashboard, select the +Add Project button.
The page will redirect the partner to the ‘Add a new Project’ page as shown below.

Enter a unique Project Name and select the Project Type. Currently, MOSIP supports three types of projects: SBI, SDK and ABIS
Based on the project type selected, the partner needs to enter the mandatory configurations before saving the project.
When the project type selected is SBI, the partner needs to provide/select the below configurations:
- Spec Version: MOSIP SBI specification for which the SBI is built
- Purpose: The purpose of the device
- Device Type: The type of device
- Device SubType: The Subtype of the device
- SBI Hash: Encoded hash of SBI installation file
- Website URL: Partner website URL
- Device Images: The image of the device

Purpose

Device Type

Device SubType

Registration

Iris

Double

Registration

Iris

Single

Registration

Face

Full Face

Authentication

Finger

Single

Authentication

Finger

Touchless

Authentication

Iris

Single

Authentication

Iris

Double

Authentication

Face

Full Face

When the project type selected is SDK, the partner needs to provide the below configurations:
- Base URL: URL where the SDK is deployed
- Spec Version: MOSIP SDK specification for which the SDK is built
- Purpose: Purpose of the SDK
- SDK Hash: Encoded hash of SDK installation file
- Website URL: Partner website URL
- Test Data: Input data needed for the run

When the project type selected is ABIS, the partner needs to provide the below configurations:
- Active MQ URL: URL where the ABIS is deployed
- Modality: Combinations of different modality
- Username: Username of Active MQ URL
- Password: Password of Active MQ URL
- Request Queue Name: Outbound Queue Name
- Response Queue Name: Inbound Queue Name
- Spec Version: MOSIP ABIS specification for which the ABIS is built
- ABIS Hash: Encoded hash of ABIS installation file
- Website URL: Partner website URL
- Test Data: Input data needed for the run

Note: ABIS partner can only create ABIS project.

After entering data, partners can click Save Project. Popup ask's partner to confirm the hash value and website URL before proceeding. Click on the Save again to confirm if values are correct.

Once the project is saved, a successful message is displayed and a popup appears on the screen which when closed redirects the partner to the project dashboard (home).

Possible values for the Purpose attribute in SDK are:

Matcher
Check Quality
Extract Template
Convert Format

Download Encryption Key

Once the project is created by the partner, they can download the encryption key.
Partner can download encryption key for Auth devices.

View a specific project

Details of a specific project can be viewed

By clicking on the name of the project, or,
By clicking on the option View in the options section of the project row.

Once you click on the above-mentioned link, you will be redirected to the project details page of the specific project.

Move to the biometric data dashboard

Click on the Biometric Data button on the projects dashboard screen.
The partner will now navigate to the Biometric Test Data screen where they can add multiple biometric test data files.

Biometric data dashboard

Possible activities as a part of the Biometric Data Dashboard are:

View all the biometric data collected on the dashboard
Upload new biometric data
Download biometric data
Delete biometric data
Move to the project dashboard

View all the biometric data

To view the biometric test data collection, click on Biometric Data on the Dashboard.

The biometric data dashboard should display the below attributes of a biometric data

Name of the biometric data
Type of data
Purpose of the data
The file name of the data
Creation date and time of the biometric data

Filter in the dashboard should be able to perform filter based on the name of the biometric data, type, purpose and creation date and time.

Upload new biometric data

On the Biometric Test Data page, click +Add Biometric data, it redirects the partner to the Upload Biometrics Test Data screen.
Provide a unique name for the biometric data
Based on the type selected, the partner needs to enter the respective mandatory details before saving the biometric data.
When the project type SDK is selected, the partner needs to provide the below details:
- Purpose: The purpose of the test (SDK test type)
- Test Data: The test data is to be uploaded as a ZIP
When the project type ABIS is selected, the partner needs to provide the below details:
- Test Data: The test data is to be uploaded as a ZIP
Note: ABIS partner can only upload an ABIS biometric test data.

The Test Data section has two options Browse and Download Sample File.

The Browse button will be the file explorer in the system for the partner to select the test data ZIP to be uploaded.

The Download Sample File button will download a blank ZIP file with instructions in the README of the test case so that the partner can prepare and add biometric test data.

Download test data

Once the test data is uploaded to the server it can be downloaded by the partner,
- Clicking on the name of the biometric data in the biometric data, or,
- Clicking on the Download Zip in the options menu of the biometric data.

My Reports Dashboard

In this dashboard, users have the capability to view reports that have been submitted for review and they can download the submitted reports and check the current status of submiited report, providing a streamlined and efficient way to manage their submissions.

The My Reports Dashboard will display the following attributes of a report:

Project Type
Name of the project
Comments added by user while submitting report
Date when report was submitted
Date when report was approved/rejected
Comments of reviewer
Download or view the report document
Current status of the report

The filter option in the dashboard will filter based on the name of the project, project type and the creation date and time.

Users have the option to click on the Project Name, allowing them to navigate directly to the view project dashboard for the respective project.

Users can simply click on the Download button to retrieve the report submitted for the respective project.

Collections

A collection is a group of test cases selected by the partner for a particular project configuration. Inside a project, they can create multiple collections based on their choice of test cases selected. As part of the collection, they can perform the below activities:

Create a collection
View a collection
Run a collection
View the run history of a collection
Generate Draft Report for Compliance Collection
Archive a collection

Create a Collection

To create a collection for a project:
- Navigate to the project details page by clicking on the project name or View option in the options list.
- By default, application will create a Compliance Collection for the project, and it includes all the test cases that are based on project details.
- Quality Assessment Collection will only be added by default for SBI projects, and it includes only quality assessment testcases.
- Click on the Add Collection button and you will be redirected to the Add Collection screen.
Enter a unique name for the collection.
Select the test cases to be added to the collection
- The test cases will be displayed in a tabular format with ID, Name, Description and Validator details.
- Beside every test case, there will be a check box which needs to be selected by the partner.

After selecting the test cases, the partner can click on the Save Collection button to save the collection.
Once a collection is successfully created, there is a success popup shown and the partner is redirected to the Project details page.
Once a collection is created it is displayed on the Collection Dashboard which is available on the Project details page.

Few points to note:

A collection cannot be saved if no test cases are selected.
A collection name cannot be empty, the partner needs to provide a unique collection name before saving the collection.
Every collection row in the dashboard has the option to view the name of the collection, the number of test cases selected as a part of the collection, the creation date, the View Report, the Last Test Run and the Run history of the collection.

View a Collection

Once the partner creates a collection, they can view the collection details by clicking on the collection name.

Run an SBI Collection

Before running a collection in SBI, the partner needs to connect to a device without which they cannot proceed with testing.
The partner should click on the Scan Device button in the Collection Dashboard as shown below.

This triggers a scan of all the configured ports in the system where the SBI is connected.
If any device connected with an SBI is found, the application asks the partner to select an available port and the device for running the test.

If any device is not found, an error popup is displayed to the partner with an option to Scan Again.

Once the device is selected, the partner can click on the Save button.
After the device is selected and saved in memory, the Run button for the collections is enabled.

If a device is already scanned and selected before running the collection, the partner can choose to re-scan and select another device for running the test case.
If a device is selected, the partner can click on the Run button to run the test case.
If the partner selects a Fingerprint Slap device but the collection is for a Double Iris device, then the test case is not executed. The partner will be shown an error message and asked to re-select the correct device. The combination validated here is for Purpose, Device Type and Sub Type as displayed below.

If the correct device is selected and the partner initiates the test run, the test case execution should start.
During the test run,
- A progress bar will be shown with the percentage of tests execution completed
- A timer to show the time elapsed during the execution
- Option to close or cancel the test run
- Option to initiate capture for a test case or resume run after completing the operation.

The test run also shows,
- The total test cases getting executed for that run
- The current test case name
- Instructions (if any) for the partner to follow
Once the test execution is completed, the partner can see,
- A high-level result with the number of test cases executed- with the number of test cases failed and the number of test cases passed in the run.

The partner can also see the time elapsed
They can also view the detailed test run report

Run an SDK Collection

Before running the SDK collection, the partner can change the Test Data, the Base URL and the SDK Hash in the project settings

Click the Run button of the specific collection.
The application now checks if the URL shared by the partner is accessible or not. If not accessible, the application shows an error message to the partner.

Once the run initiates with the proper URL, the execution should complete on its own and during the run, the partner can see:
- A progress bar with the percentage of test execution completed.
- A timer to show the time elapsed during the execution.
- Option to close or cancel the test run.

Once the test execution is completed, the partner can see:
- A high-level result with the number of test cases executed- with the number of test cases failed and the number of test cases passed in the run.
- They can also see the time elapsed.
- They also have the option to view the detailed Test Run report.

Note: For a test run, the partner can select their data or MOSIP’s default data. But let us assume that the partner chooses their data, but in the ZIP file, they have missed adding data for a particular test case, then the system should take MOSIP’s data for the test case' execution.

Run an ABIS Collection

Before running the ABIS collection, the partner can change the Username, Password, Queue names, Test Data, ABIS Hash and the Actice MQ URL in the project settings

Click the Run button of the specific collection.
Once the run initiates with the proper URL, the execution should complete on its own and during the run, the partner can see:
- A progress bar with the percentage of test execution completed.
- A timer to show the time elapsed during the execution.
- Option to close or cancel the test run.

Once the test execution is completed, the partner can see:
- A high-level result with the number of test cases executed- with the number of test cases failed and the number of test cases passed in the run.
- They can also see the time elapsed.
- They also have the option to view the detailed Test Run report.

View the run history of the Collection

The partner after completing a successful test run can view the detailed run by,

Clicking on the View Test Run button once the test execution is completed.

Clicking on the View Last Test Run option in the options section of the collection as shown below.

Once the partner selects the View Last Test Run option, the application will redirect the partner to display the test run details as shown.

Clicking on the Test Run History option in the options section of the collection and then click on the Details button of the test run that they want to view

Once the partner clicks on Details, it redirects the partner to the test details as shown above.

On the Test Run History page, the partner can view:
- Run date
- Overall run status
- Total test cases in the collection
- Test cases passed
- Test cases failed

The partner will be able to view the details of any test run they wish.

On the Test Run details page, the partner can view,
- List of the test cases in the collection
- Test case ID
- Test case Name
- Status of the test case (Pass or Failed)
- Execution status of the test case (Complete or Incomplete)
- Option to view details of the test case
The details of the test case contain,
- The request that was sent
- The response that was received
- The detailed status of validators that ran in the test case

Generate Draft Report for Compliance Collection

The partner can only generate a Draft Report after running Compliance Collection.

By default, Compliance Collection will be added when the project was created.

Click the Run button of the Compliance Collection.

Once the test execution is completed, the partner can see,
- A high-level result with the number of test cases executed- with the number of test cases failed and the number of test cases passed in the run.
- They also have the option to view the detailed Test Run report.

Partner can create a Draft Report by clicking the Generate Draft Report button.
Once the report is downloaded, the partner can view:
- The downloaded draft report, which uses the project name as its filename.
- A popup will appear to submit the report for review.

Partners need to check the downloaded Draft Report, which contains their details, project specifics, test cases, and the complete test run results. These results include the number of test cases executed, passed, and failed.
After reviewing the downloaded report, the partner can submit it for review by checking the checkbox in the popup window. They can then proceed by clicking the Send For Review button to finalize the submission.

Once submitted the report, the Compliance Collection cannot be rerun for the project. The partner can download the submitted report by clicking on the download icon.

Generate Quality Assessment Draft Report for Quality Assessment Collection

The partner can only generate a QA Draft Report after running Quality Assessment Collection.

By default, Quality Assessment Collection will be added when the SBI project was created.

Click the Run button of the Quality Assessment Collection.

After completing the test execution, the partner will be able to view the below mentioned results
- A high-level result with the number of test cases executed- with the number of test cases failed and the number of test cases passed in the run.
- They also have the option to view the detailed Test Run report.

Partner can create a Quality Assessment Draft Report by clicking the Generate Draft Report button.
Once the report is downloaded, the partner can view:
- The downloaded QA draft report, which uses the project name as its filename.
- A popup will appear to submit the report for review.

After downloading the report, partners can review the QA Draft Report. This report includes their details, project specifics, test cases, and a comprehensive summary of the test run results, including the number of test cases executed, passed, and failed.
This report also includes the biometric scores classification for each SDK and SBI.
After reviewing the downloaded report, the partner can submit it for review by checking the checkbox in the popup window. Following that, they can click the Send For Review button to finalize the submission.
Once the report has been submitted, the ability to re-execute the Quality Assessment Collection for the project is no longer available. Partners can retrieve the submitted report by clicking on the download icon.

Partner Reports Dashboard

When users with the special CTK Admin role access the application, they are granted access to the Partner Reports Dashboard. This dashboard serves as a centralized hub, offering a comprehensive overview of partner reports.

Below are the possible activities as a part of Partner Reports Tab of the Admin Dashboard.

Explore a comprehensive list of all reports that have been submitted.
Efficiently sort and examine reports based on their current status.
Download and view report submitted.
Access a preview of the project's test run associated with the submitted report.
Take decisive action on submitted reports by either approving or rejecting them.

View reports

Upon logging into the compliance toolkit and navigating to the Partner Reports Dashboard, the admin will be presented with a default view showcasing reports submitted for review.

The Partner Reports Dashboard will display the following attributes of a report:

Name of the partner
Organization name to which partner belongs to.
Type of project
Name of the project
Partner's comments about the report
Date when report was submitted
Current status of the report
Download or view the report document.
Access associated test runs and results.
Approve the report.
Reject the report.

The dropdown option in the tab allows you to filter reports based on their current status. There are three available options

Review (Default): Displays reports that are currently under review.
Approved: Shows reports that have been approved.
Rejected: Displays reports that have been rejected.

The filter option in the dashboard will filter based on the name of the project, project type and the creation date and time.

Download reports

When you click on the download icon, the report will be downloaded. Admins can then view the downloaded report and make decisions based on the information it contains.

Preview test run details

Admin can click on the View Test Run link to access detailed information about the test run associated with the report.

Approve/Reject Report

After reviewing the downloaded report and verifying its content, the admin can choose to either approve or reject the report. Optionally, comments can be added to provide additional context or feedback during the decision-making process.

Approve Report: After reviewing the downloaded report, if it meets the criteria and is deemed satisfactory, the admin can proceed to click on the Approve button.

After selecting the Approve button, a confirmation popup will be displayed to verify the approval action. Admins should review the information provided and, if satisfied, proceed by selecting the checkbox within the popup to finalize the approval.

After selecting the checkbox, the admin will be presented with an option to add optional comments, if needed, after that the admin can proceed by clicking the Approve button to officially approve the report.

Reject Report: After reviewing the downloaded report, if it does not meet the criteria, the admin can initiate the rejection process by clicking on the Reject button.

After clicking the Reject button, a popup will appear to confirm the rejection action. After reviewing the information, and once satisfied with the decision, the admin can proceed by checking the checkbox within the popup to finalize the rejection.

After selecting the checkbox, the admin will be presented with a comment box to add mandatory comments, specifying the reason for rejection. After providing the required comments, the admin can proceed by clicking the Reject button to officially reject the report.

Test Runs Archival Batch Job

Compliance Toolkit has a batch job process that archives X number of test runs for each collection.

Consider this scenario: If there are 15 test runs, with an offset of 10, the most recent 10 will be retained, while the remaining 5 will be moved to an archival table. In the test-run-history, only the last 10 test run records are visible to partners.

1.0.0

Pre-requisites

CTK should be deployed with the required dockers.

compliance-toolkit-service: 1.0.0
compliance-toolkit-ui: 1.0.0

Dependent Service (dockers)

Artifactory: mosipid/artifactory-ref-impl: 1.2.0.1-B2
Audit manager: mosipid/kernel-auditmanager-service: 1.2.0.1-B1
Auth Manager: mosipid/kernel-authmanager: 1.2.0.1-B1
Key Manager: modipid/kernel-keymanager-service: 1.2.0.1-B1
Partner Management: mosipid/partner-management-service: 1.2.0.1-B1
KeyCloak: mosipid/keycloak-init: 1.2.0.1-B1
Postgres: mosipid/postgres-init: 1.2.0.1-B1
Config Server: config-server: mosipid/config-server: 1.1.2
Notification Service: mosipid/kernel-notification-service: 1.2.0.1-B1
ClamAV: clamav/clamav: latest
MinIO

Note:

Ensure that in the kernel-default.properties, the value of mosip-toolkit-client is set in auth.server.admin.allowed.audience.If this was not set by default, then set it and restart kernel-auth-service and compliance-toolkit-service.
Check if the roles given to mosip-pms-client should match with any of the roles for following config property.
This config property is available in: https://github.com/mosip/mosip-config/blob/${ENV_NAME}/kernel-default.properties
For Example:
mosip.role.keymanager.postverifycertificatetrust=ZONAL_ADMIN, GLOBAL_ADMIN, PMS_ADMIN, PMS_USER
Then mosip-pms-client should have any of the above roles.
Check that mosip-pms-client has the role REGISTRATION_PROCESSOR, PARTNER_ADMIN, PMS_ADMIN in Key Cloak.If this was not set by default, then set it and restart key manager and compliance-toolkit-service.
From the 1.0.0 version onwards, we need to generate an encryption key for CTK.
- Create a new app id by directly inserting the below row.
- Get the client token using auth manager swagger by calling endpoint.
  https://api-internal.dev.mosip.net/v1/authmanager/authenticate/clientidsecretkey
- Use generateMasterKey endpoint to generate module-level certificate.
- Directly download the certificate via key manager swagger getCertificate with App Id as COMPLIANCE_TOOLKIT and Ref Id as COMP-FIR.
- This certificate is to be used by SBI devices as the encryption key.
- For Mock MDS, when running in Auth mode, update the below values in the application.properties file.
For REAL MDS/SBI.
- You must communicate to the vendors to download the new encryption key from UI and give us an updated SBI which uses this encryption key.
- It can be downloaded for Auth SBI projects from UI.

Steps to load testdata and schemas

2. The resources folder would contain schemas, test data and test cases that need to be added to MinIO and DB.

Steps to upload resources to MinIO

1. Log in to MinIO from the browser.

2. Create a compliance-toolkit bucket.

3. Create a new folder named testdata in the above bucket and upload all test data zip files from the resources folder to this folder.

4. Create a new folder named schemas in the above bucket and upload all sbi and sdk schemas, test case schema from the resources folder to this folder.

Note: There is no need to upload compliance_test_definitions_sbi.json and compliance_test_definitions_sdk.json.

5. Restart the pods after adding new files in MinIO.

Steps to upload resources to MinIO using Swagger

1. Using Keycloak, create a new user for the compliance toolkit.

2. Make sure to add the email ID. Also, give the user GLOBAL_ADMIN.

3. Log in to the compliance toolkit in your environment with above the Keycloak user.

5. Go to uploadResourceFile the endpoint in ResourceManagementController.

6. Select any one of the types which are mentioned in swagger and version (SBI or SDK).

7. Upload the schema and test data files from the resources folder in the project.

8. You can see the uploaded schema and test data files in the MinIO dev environment.

Steps to upload test cases to the Database

2. Open the resources folder in the project.

3. compliance_test_definitions_sbi.json file has all the test cases in it.

4. Copy the test cases array from this file and prepare a request as shown below.

5. Request body for saveTestCases request.

9. The same should be done for compliance_test_definitions_sdk.json.

1.2.0

Pre-requisites

CTK should be deployed with the required dockers.

compliance-toolkit-service: 1.2.0
compliance-toolkit-ui: 1.2.0

To deploy Compliance Toolkit, we require the below mandatory services:

Dependent Service (dockers)

Artifactory: mosipid/artifactory-ref-impl: 1.2.0.1-B2
Audit manager: mosipid/kernel-auditmanager-service: 1.2.0.1-B1
Auth Manager: mosipid/kernel-authmanager: 1.2.0.1-B1
Key Manager: modipid/kernel-keymanager-service: 1.2.0.1-B1
Partner Management: mosipid/partner-management-service: 1.2.0.1-B1
KeyCloak: mosipid/keycloak-init: 1.2.0.1-B1
Postgres: mosipid/postgres-init: 1.2.0.1-B1
Config Server: config-server: mosipid/config-server: 1.1.2
Notification Service: mosipid/kernel-notification-service: 1.2.0.1-B1
ClamAV: clamav/clamav: latest
MinIO

The Setup guide is a checklist for the three categories below:

Configuration Checks
Steps to load testdata, schemas and testcases
Steps to generate Android APK

Configuration checks

Ensure that in the kernel-default.properties, the value of mosip-toolkit-client and mosip-toolkit-android-client is set in auth.server.admin.allowed.audience. If this was not set by default, then set it and restart kernel-auth-service and compliance-toolkit-service.
Ensure that in compliance-toolkit-default.properties, CORS is enabled to allow access to mosip-toolkit-android-client:
If this was not set by default, then set it and restart compliance-toolkit-service.
Check if the roles given to mosip-pms-client match with any of the roles for the following config property: mosip.role.keymanager.postverifycertificatetrust=XXX
For Example:
mosip.role.keymanager.postverifycertificatetrust=ZONAL_ADMIN, GLOBAL_ADMIN, PMS_ADMIN, PMS_USER
Then mosip-pms-client should have any of the above roles.
Check that mosip-pms-client has the role REGISTRATION_PROCESSOR, PARTNER_ADMIN, PMS_ADMIN in Key Cloak. If this was not set by default, then set it and restart keymanager and compliance-toolkit-service.
From the CTK v 1.0.0 version onwards, we need to generate an encryption key for CTK.
- Create a new app id by directly inserting the below row.
  INSERT INTO keymgr.key_policy_def(app_id, key_validity_duration, is_active,pre_expire_days, access_allowed, cr_by, cr_dtimes, upd_by, upd_dtimes, is_deleted, del_dtimes) VALUES ('COMPLIANCE_TOOLKIT', 1095, true, 60, 'NA', 'mosipadmin', '2022-11-28 09:00:40.822625', null, null, false, null);
- Using the auth manager swagger URL, get the client token.
  Swagger URL:
  Endpoint:
  Request:
- Now using the key manager swagger URL, generate module level certificate.
  Swagger URL:
  Endpoint:
  Request:
- Directly download the certificate via key manager swagger URL and getCertificate endpoint, with App Id as COMPLIANCE_TOOLKIT and Ref Id as COMP-FIR.
- This certificate is to be used by SBI devices as the encryption key.
  For Mock MDS, when running in Auth mode: update the below values in the application.properties file.
  For real MDS/SBI, the vendors can download the new encryption key from the UI and test with the updated SBI which uses this encryption key.It can be downloaded for Auth SBI projects from UI.

Steps to load testdata, schemas in MINIO

2. Project structure will be as shown below.

3. The resources folder has schemas, test data and testcases that need to be added to MinIO and DB.

Steps to load testdata and schemas directly in MinIO

1. Log in to MinIO from the browser.

2. Create a compliance-toolkit bucket.

3. Create a new folder named testdata in the above bucket.Upload MOSIP_DEFAULT_XXX.zip files from resources to it.

4. Create a new folder named schemas in the above bucket. Upload all SBI, SDK and ABIS schemas along with subfolders in it.

5. Upload testcase_schema.json from resources folder to `schemas folder.

6. There is no need to upload compliance_test_definitions_sbi.json ,compliance_test_definitions_sdk.json and compliance_test_definitions_abis.json

7. Please restart the compliance pods after adding new files in minio to refresh the cache.

Alernately swagger endpoint can also be used to upload data in Minio. In this case there is no need to restart CTK services.

Steps to upload resources to MinIO using Swagger

1. The swagger url is:

https://{api-internal-env-url}/v1/toolkit/swagger-ui/index.html?configUrl=/v1/toolkit/v3/api-docs/swagger-config

2. Using keycloak/ register option in CTK UI, create a new user for compliance toolkit.

3. Make sure to add the email ID. Also, give the role GLOBAL_ADMIN.

4. Login to compliance toolkit in your environment from browser with the above Keycloak user.

5. Go to ResourceManagementController in swagger and upload the schema alongwith testdata files.

6. Then, select any one of type mentioned above and also mention the version (SBI/SDK/ABIS Version).

7. Select the type of required file which you want to upload from resources folder in project.

8. After execution you can see the response.

9. Check inside the MinIo in dev environment whether the files have been uploaded into it.

Steps to upload test cases to the Database

2. Open resources folder in project.

3. compliance_test_definitions_sbi.json file have all the test cases in it.

4. Copy test cases array from this file and prepare a request as shown below.

5. Request body for saveTestCases request.

6. Then, execute it.

7. The same should be done for compliance_test_definitions_sdk.json and compliance_test_definitions_abis.json.

Steps to generate Android APK

Once all the steps mentioned above are completed, you can trigger the Android APK build for your environment. https://github.com/mosip/mosip-compliance-toolkit-ui/actions/workflows/android.yml
You may need GitHub repository write access.
Add values for the URL’s according to your deployment env.