Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
This section comprises instructional documents that can provide valuable insights into CTK for a diverse audience. It can be regarded as a knowledge hub that contains all the necessary additional information for effectively utilizing CTK.
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.
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.
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.
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
.
This test case is for verifying the insert endpoint of an ABIS. This test case is available for all ABIS projects.
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.
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
6. Change the requesttime
to the current day and send the request.
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
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.
Generation and Verification of Hash for SBI and SDK:
In order to maintain the integrity of the SBI/SDK software solution, a cryptographic hash function has been implemented. This function has been thoroughly tested by CTK and found to be compliant with the MOSIP specification.
It is a requirement for partners to calculate the HASH of the software solution using the SHA256 hash function, regardless of the technology environment in which the devices will be utilized.
Furthermore, the calculated HASH of the solution should remain unchanged, allowing countries or relying parties to recalculate the HASH and validate the software's integrity prior to deployment.
In the event that the software undergoes any changes, the partner must calculate a new HASH and retest the solution using CTK in order to maintain their compliance status.
The Blake2b or SHA256 algorithms can be utilized to calculate the hash value of an APK file.
Blake2b produces digests with a byte size ranging from 1 to 64 and is specifically designed for 64-bit systems.
SHA256 is an unkeyed cryptographic hashing method that generates a 256-bit hash outcome from an input of variable length.
The hash value of an APK file can be determined using Windows PowerShell, which defaults to employing the SHA256 algorithm.
The hash value will be altered in the event of any modifications made to the APK file. Conversely, the hash value will remain constant if no changes are made.
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.
Refer ISO 19794-4:2011 Specifications.
Refer ISO 19794-6:2011 Specifications.
Refer ISO 19794-6:2011 Specifications.
Partners can select their preferred language while logging into CTK. By default, CTK supports three languages namely- English, French and Arabic.
To add support for an additional language, below are the steps to be followed:
Step 1: Add an additional language to the CTK login page.
Step 2: Add a new resource bundle (i18n JSON) file for the new language.
Step 3: Translate each page label.
Step 4: Translate validator description.
Step 5: Translate every testcase in the resource bundle.
Step 6: Translate all the service-generated validator messages.
Step 7: Translate all the service errors.
Step 8: Build and deploy the code.
Let us understand the steps mentioned above with more details.
The user can add a new language support to CTK via Keycloak.
to do so, create a locale for a new language in localization.
Add a new locale in the supported locales field.
For example: New locale es
for Spanish language.
It will be added to the CTK login page once the changes have been saved.
The i18n folder is available under assets folder in UI codebase.
Create a new JSON file in the folder.
For example: In Spanish language, the file name should be es.json
.
Copy the eng.json
data and paste it in es.json
.
When translating into a new language, we should solely translate only the right-side values using a translation service (such as Google Translate).
For example: Take the first page (Project Dashboard)
In each page, the labels are on the left and values are on the right.
The figure below highlights the page labels along with their values.
Also translate the labels on all pages.
All Validator descriptions have been added to the resource bundle. The names of validators are their labels, and their descriptions are their values.
Here is an example of validator description added in resource bundle.
Translate only the right-side values.
If a new validator is added, a resource bundle must be added as well.
Translate the values of testName, testDescription, and androidDescription. The code will use the testcase data in accordance with the testId.
If you add any new testcases in the future, you must include them in the resource bundle.
Here is an example of testcase added in resource bundle.
All the service-generated validator messages have been added based on the below cases.
For example:
case 1:
There are no arguments in this case.
Example of validator message in a resource bundle:
The validationResultDto
now contains an additional attribute called setDescriptionKey
. This will help to take validator messages from resource bundle.
Example code for setDescriptionKey:
case 3:
This case contains more than one argument in the validator message.
Example of validator message in a resource bundle:
{} – This will represents the arguments value.
Example code for setDescriptionKey:
Here ARGUMENTS_DELIMITER is ::
and ARGUMENTS_SEPARATOR is ;
Example of service errors added in a resource bundle given below.
Error codes are on the left and error messages are on the right.
You need to build code after completing the steps listed above.
After building, you can deploy the code.
Kibana houses ten CTK Dashboards, which aid in presenting data in a comprehensible and significant manner.
These dashboards facilitate continuous monitoring of data and system metrics. Users are able to establish visualizations that automatically update as new data is received.
Kibana needs environmental access.
Within the dashboard, search and filtering functionalities can be utilized.
It should be noted that the data stored in Kibana may not be completely secure. To mitigate risks, we have taken precautions such as excluding sensitive data columns and allowing only necessary information for dashboard visualization.
Let us see list of CTK dashboards.
CTK - Onboarded Partners
This dashboard shows the pie chart regarding the partners onboarded in CTK, based on the type of project, list of partner id along with count of projects created and SBI projects by purpose.
CTK - Active Partners, Testcase Trends
This dashboard describes most active partners in CTK, most successful top 20 testcases and most failed top 20 testcases.
CTK – Testcases
It displays all the CTK testcase details.
CTK - Top 5 Partners Successful Test Runs
It shows CTK - top 5 partners with successful test runs across all collections (including compliance collections).
CTK - Top 5 Partners Successful Test Runs for Compliance Collections
The dashboard describes top 5 partners with successful test runs for only compliance collections.
CTK - Biometrics Quality Report of BQAT SDK
It shows Biometrics Quality Report for scores given by BQAT SDK.
Here, to add more panels like above, click the Edit button. This will enable you to edit the dashboard. Then, click the Create Visualization button to create a new panel.
Select Index Pattern and set horizontal and vertical axis.
CTK - Biometrics Quality Report of SBI
The dashboard shows Biometrics Quality Report for scores given by SBI.
CTK - Biometrics Quality Report Scores Comparison
It compares the scores between different SDK and SBI.
CTK – Compliance Test Run Reports
The number of reports submitted for review and their status are displayed on this dashboard.
CTK- View Partner’s Test Run
Here we can view a partner's test run status based on partner id and test run ID.
Sl.No | Name | Type | Description | Length | Valid values | Is this attribute mandatory? | Image verification |
---|---|---|---|---|---|---|---|
Sl.No | Name | Type | Description | Length | Valid values | Is this attribute mandatory? | Image verification |
---|---|---|---|---|---|---|---|
Sl.No | Name | Type | Description | Length | Valid values | Is this attribute mandatory? | Image verification |
---|---|---|---|---|---|---|---|
Configuration | Description | Default Value |
---|---|---|
Name | Description | Test with Mock SBI |
---|---|---|
Name | Description | Test with Mock SDK |
---|---|---|
Name | Description | Test with Mock ABIS |
---|---|---|
1.
Format Identifier
General Header
FIR
– Finger Image Record
4 bytes
464952Hex (F
I
R
00Hex)
yes
2.
Version number
General Header
020
in ASCII
4 bytes
30323000Hex (0
2
0
00Hex)
yes
3.
Length of record
General Header
Includes all finger/palm representations, quality blocks and certification blocks1
4 bytes
57 to (232-1)
yes
4.
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
5.
Certification flag
General Header
Indicates the presence of any device certification blocks within the representation headers
1 byte
0, 1
yes
6.
No of Distinct finger/Palm Position
General Header
Number of fingers or palms represented
1 byte
>=1
yes
7.
Representation Length
Representation Header
The representation-length field denotes the length in bytes of the representation including the representation header field.
4 bytes
yes
8.
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
9.
No of Quality block
Representation Header
1 byte
10.
Quality block
Representation Header
5x
Quality Score 1 byte Quality algorithm vendorIdentifier 2 bytes Quality algorithm Identifier 2 bytes
no
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
yes
1.
Format Identifier
General Header
Indicates Face representation data
4 bytes
46414300HEX (F
A
C
0HEX)
yes
2.
Version number
General Header
030
in ASCII
4 bytes
30333000HEX (0
3
0
00HEX)
yes
3.
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
4.
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
5.
Certification flag
General Header
No certification schemes are available for this part of ISO/IEC 19794
1 byte
00HEX
yes
6.
Temperol Sematics
General Header
One representation is present
2 bytes
0000HEX
yes
7.
Representation Length
Representation Header
The representation-length field denotes the length in bytes of the representation including the representation header field.
4 bytes
yes
8.
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
9.
No of Quality block
Representation Header
1 byte
10.
Quality block
Representation Header
5x
Quality Score 1 byte Quality algorithm vendor Identifier 2 bytes Quality algorithm Identifier 2 bytes
no
11.
Face Image Type
Image Information
01HEX Full Frontal
1 byte
no
12.
Image Data Type
Image Information
01HEX JPEG 2000 (lossy)[AUTH] 02HEX JPEG 2000 (lossless) [REG]
1 byte
yes
yes
13.
Width
Image Information
2 bytes
yes
yes
14.
Height
Image Information
2 bytes
yes
yes
15.
Image Colour Space
Image Information
1 byte
yes
yes
16.
Image Data Length
Image Information
4 bytes
1 to 4 294 967 226
yes
17.
Image Data
Image Information
yes
yes
1.
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
2.
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
3.
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
4.
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
5.
Certification flag
General Header
No certification schemes are available for this part of ISO/IEC 19794
1 byte
00Hex
yes
6.
Representation Length
Representation Header
The representation-length field denotes the length in bytes of the representation including the representation header field.
4 bytes
yes
7.
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
8.
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
9.
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
yes
13.
Image width
Representation Header
Width in pixels
2 bytes
> 0
yes
yes
14.
Image height
Representation Header
Height in pixels
2 bytes
> 0
yes
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
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
yes
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.
2
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.
3
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.
60
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.
30
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.
30
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.
50
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.
6
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.
10
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 * * ?
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.
To verify Key Rotation testcases, we have to generate 3 set of device certificates device.p12
.
• To generate device.p12 certificate, please follow the instructions given in link
• In Compliance Tool kit, create a collection only with Key Rotation test case and Run Mock MDS.
• In CTK select respective device by performing Scan Device
operation and run key rotation
testcase.
• Stop the Mock MDS and rotate/change second Device.p12 in Keys folder.
• Relaunch mock MDS and select Continue
on CTK. Now CKT saved second device key information.
• When CTK asks to rotate the device key, then Stop the Mock MDS and rotate/change third Device.p12 in Keys folder.
• Relaunch mock MDS and select Continue
on CTK. Now CKT saved third device key information.
Note: Rotate the device key in the MDS/SBI as many times as setup in project configuration
CTK will provide a result of the overall key rotation testcase once the testcase has been run.
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.
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.
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.