As an Operator, my biometrics should not be accepted when I am registering an applicant.
Activity
Maheswara Sarma March 12, 2025 at 5:14 AM
There are issues associated with the story hence closing the story. Verified this story with two mock apks verify rejection and matching of the biometrics. Attacing other apk for future ref
Humair Kankudti Md August 5, 2024 at 5:46 AM
Task Update:
Completed and available in PR - RCF-351 Integration of Match-SDK by Md-Humair-KK · Pull Request #416 · mosip/android-registration-client (github.com)
Humair Kankudti Md June 26, 2024 at 4:54 AM
Task Update:
Changed the biometrics-util
version in Android reg client and added the jackson-core, fastdoubleparser
in the ignore list of gradle properties
android.jetifier.ignorelist = jackson-core, fastdoubleparser
Note: Observed that, for IRIS the biometric type are varying in User Bometric as left and in BiometricDto for current applicant as Left.
The match functionality working fine now, need to integrate the alert pop up to inform about the match
Humair Kankudti Md June 21, 2024 at 4:46 AM
Task Update:
Done:
Regarding the Match-SDK integration with Android reg client
Added the match biometric logic to get the biometric record of sample/current applicant and gallery/saved operator biometrics.
Changed the subtypes logic to have biometric subtype same in both UserBiometric and BiometricDto.
for ex: it was ringRight in UserBiometric and Right RingFinger in BiometricDto of current applicant.
Todo:
<Iris/Finger/Face>Decoder is having a problem in conversion again, issue is predicted to be because versions of io.mosip.biometric.util:biometrics-util:1.2.0
is used in Android reg client and io.mosip.biometric.util:biometrics-util:1.2.0.2
is used in Desktop reg client.
When changed in Android reg client it will start throwing the Failed to transform jackson-core-2.15.0.jar error again - need to look into this.
Biometrics captured during registration should not match with operator’s biometrics
Components: Match SDK (Local deduplication)
Purpose: develop a reference match sdk comparable in implementation logic with IBioAPIv2 Interface being implemented.
Requirements:
The Match SDK should be a build time dependency of the project.
A country should be able to replace the reference match sdk with a vendor provided one and be able to use it with no code change.
Purpose: As an Operator, my biometrics should not be accepted when I am registering an applicant.
Pre-requisites:
Android Reg Client should be installed.
The operator should be onboarded and should be logged in using valid credentials.
Basic flow:
As an Operator when I am registering an applicant, my biometrics should not be accepted in the applicant’s biometric capture field.
A local deduplication should be performed to identify if the biometrics of the applicant is matching with the Operator’s biometrics. If it does, the user should not be able to proceed further.
Acceptance criteria:
This is configurable and can be on and off. If it is on, local deduplication should be performed, if it is not active, local deduplication should not be performed.
When Match SDK is enabled
If a biometric match is found, the biometric data should not be saved and operator shouldn’t be able to proceed to screens next to biometric capture screen.
If biometric match is found, display the error “Biometrics Matched With Operator Biometrics, Please Try Again".
This should work in offline and online mode.
If the biometric matches, we will get a message- The biometrics entered matches with Operators’s biometrics.
When Match SDK is disabled:
The flow should continue as usual.
Scenario #1: When the Operator logs in using his credential and gives his biometrics instead of the residents biometrics (local dedupe)
Scenario #2: When another Operator logs in using his credential and gives his biometrics instead of the residents biometrics (local dedupe)
Scenario #3: Happy flow, When residents biometrics are captured, the flow should continue.
Since it is mock Match SDK in our case, we will have to manually dictate if we want the match to pass/fail.
Potential Approaches: Two builds of Matcg SDK, one which gives failure responses in all scenarios and the second which gives success in all scenarios. This will help in validating all flows properly.