MOSIP Docs 1.1.5
GitHubCommunityTech Blogs
  • Home
  • Architecture
    • Guiding Principles
    • MOSIP Architecture
      • Technology Stack
    • MOSIP and Data
      • Naming Standards
      • Data-Model
    • Privacy & Security
      • Cryptography in MOSIP
    • Anonymous Profiling Support
  • Modules
    • Pre-Registration
      • Pre-Registration Functionality
      • UI Specification for Pre-registration
      • Pre-Registration Configuration
    • Registration
      • Registration Functionality
      • Registration Packet
      • Registration Client Setup
      • First User Registration and Onboarding
      • Guide to Configure MOSIP for Biometrics
      • Guide to On-board Biometric Devices
      • Device Integration Specifications
      • UI Specification for Registration Client
    • Registration Processor
      • Registration Processor Functionality
      • Deduplication and Manual Adjudication
      • MOSIP ID Object Definition
    • ID Repository
    • ID Authentication
      • ID Authentication Functionality
    • Resident Services
      • Resident Services Functionality
    • Partner Management
      • Partner Management Functionality
      • MOSIP Partner Secure Communication
      • Partner Self Service Portal
    • Administration
      • Admin Services Functionality
      • Download Card
    • Kernel
      • Audit Manager Functionality
        • Admin Service Audits
        • Resident Service Audits
        • Partner Management Audits
        • Registration Client Audits
        • Registration Processor Audits
        • ID Repository Audits
        • ID Authentication Audits
        • Pre-registration Audits
      • Authentication and Authorization Functionality
      • Auth Adapter
      • Auth Implementation
      • Common Services Functionality
      • Data Services Functionality
      • Master Data Services Functionality
      • UIN and VID Generation Service Functionality
      • VID Generator
  • Biometrics
    • ABIS
    • Biometric SDK
    • MDS Specification
    • Biometric Specification
    • CBEFF XML
    • Compliance Tool Kit
  • Build & Deploy
    • Sandbox Installer
    • Deployment Architectures
    • Cell Based Deployment Architecture
    • Hardware Security Module HSM Specifications
    • Hardware Sizing
    • Customizations for a Country
    • Other Installation Guides
      • Steps to Install and Configure HDFS
      • Steps to Install and use PostgreSQL Version 10.2 on RHEL 7.5
      • Steps to Install Clam AntiVirus Version 0.101.0
      • Steps to Install Keycloak Standalone Server
    • Services in MOSIP
  • Glossary
  • Contribute
    • Call for Contribution
    • Contributor's Guide
    • Code of Conduct
    • Issue Reporting Guideline
    • Coding Standards
      • Auth Angular User Guide
      • Auth SpringBoot User Guide
      • Gitub Workflow
      • MOSIP Java Coding Standards
      • MOSIP REST API guidelines
      • Registration Client UI Developer Document
      • Registration Client Developer Documentation
      • Security Tools
    • Testing
      • Test Rig Design
      • Tester Documentation
      • Testing Attachments Kernel
  • APIs
    • ABIS APIs
    • Admin APIs
    • AuthN and AuthZ APIs
    • Biometric SDK APIs
    • BlacklistedWords APIs
    • Common APIs
    • Device APIs
    • Device Type and Subtype APIs
    • Device Management APIs
    • Document APIs
    • Dynamic Fields APIs
    • Holiday APIs
    • ID Authentication APIs
    • ID Repository APIs
    • ID Schema APIs
    • Kernel APIs
    • Machine APIs
    • Master Data Biometric APIs
    • Packet APIs
    • Packet Manager APIs
    • Partner Management Service APIs
    • Pre Registration APIs
    • Registration Center APIs
    • Registration Processor APIs
    • Resident Service APIs
    • Sync Data APIs
    • Template APIs
    • Zone APIs
  • Older Releases
    • Release Notes 1.1.5
      • Enhancements
      • Defect Fixes
      • Patches
        • Patch 1.1.5.5
        • Patch 1.1.5.5-P1
    • Release Notes 1.1.4
      • Enhancements
      • Defect Fixes
    • Release Notes 1.1.3
      • Features
      • Bug Fixes
    • Release Notes 1.1.2
      • Features
      • Bug Fixes
    • Release Notes 1.1.1
      • Bug Fixes
      • Artifact Version
    • Release Notes 1.1.0
      • Features
      • Bug Fixes
      • 1.2.0 Features
      • Artifact Version
    • Release Notes 1.0.6
    • Release Notes 1.0.5
    • Release Notes 1.0.0
      • Features
    • Release Notes 0.9.0
  • Roadmap
    • Roadmap Activities
  • Revision History
  • License
Powered by GitBook
On this page
  • De-Duplication
  • Demographic De-Duplication
  • Biometric De-Duplication
  • Manual Adjudication
  • Request sent to Manual Adjudication System
  • Response received from Manual Adjudication System
  • Process Flow for Biometric Deduplication

Was this helpful?

Export as PDF
  1. Modules
  2. Registration Processor

Deduplication and Manual Adjudication

PreviousRegistration Processor FunctionalityNextMOSIP ID Object Definition

Last updated 3 years ago

Was this helpful?

Providing unique identity for a resident is one of key features of any identity platform. Hence, in MOSIP, we provide features like demographic and biometric de-duplication followed by manual adjudication to identify the uniqueness of a resident's demographic and biometric details.

De-Duplication

De-duplication is the process to find a duplicate by comparing the individual’s details (biometric and demographic data) with the data stored in the system.

Demographic De-Duplication

In demographic de-duplication the MOSIP system compares some of the demographic data (i.e. Name, Date of Birth and Gender) of the resident against the data present in MOSIP System (the resident's those who have already registered in MOSIP). If any potential match is found, the MOSIP system sends the resident's biometrics to the ABIS system to confirm if the biometrics are also matching.

Process Flow

  1. MOSIP System receives a request to perform demographic de-duplication for Person A.

  2. MOSIP System performs demographic de-duplication for Person A by, i. Adding Person A's hashed demographic details (i.e. name, date of birth and gender) in the database. ii. Comparing Person's details against all the records in the database.

  3. Let's say the MOSIP System find duplicates against three records - Person B, Person C and Person D. i. If Person B's registration has failed we consider Person B not to be a potential match for Person A. ii. If Person C's registration process in not complete, i.e. UIN is not generated for person C yet, we do not consider Person C to be a potential match for Person A in Demo Deduplication. iii. If Person D's registration is completed and a UIN is associated then we consider Person D to be a potential match for Person A.

  4. Now the list of Potential Matches for Person A (here, we only have Person D as the only potential match, there can be a scenario where there are multiple potential matches for Person A) are sent to ABIS to perform de-duplication against the potential matches.

  5. Here, we ask ABIS to just perform match of Person A's biometrics with Person D's biometrics, we call this process a Gallery Match in ABIS. As we are asking ABIS to perform biometric de-duplication of Person A against the gallery that we have sent. i. If the ABIS confirms that Person D's biometrics matches with Person A's biometrics, MOSIP would REJECT Person A's packet. ii. If the ABIS says that Person A's and Person D's biometrics are different, we move the packet for biometric deduplication.

Biometric De-Duplication

In biometric de-duplication the MOSIP system sends the biometrics of the resident to an ABIS System (Automated Biometrics Identification System). Here, the expectation from the ABIS system is to perform biometric de-duplication (1:N match) against all the records that it has stored earlier.

Any Packet irrespective of it has gone through demographic de-duplication or ABIS gallery match, will have to go through the biometric de-duplication stage.

Process Flow

  1. MOSIP system receives a request to perform biometric de-duplication for Person A.

  2. MOSIP system sends an insert request to the ABIS system to insert Person A's biometrics in ABIS via. MOSIP-to-ABIS queue.

  3. ABIS system processes the request sent by MOSIP and sends a response back to MOSIP via. ABIS-to-MOSIP queue.

  4. MOSIP system now sends a identify request to the ABIS system to perform de-duplication for Person A in ABIS via. MOSIP-to-ABIS queue.

  5. ABIS System processes the request and sends the list of potential matches back to MOSIP via. a ABIS-to-MOSIP queue.

  6. Let's say the ABIS system has found duplicates against three records - Person B, Person C and Person D. i. If Person B's registration has been REJECTED, we consider Person B not to be a potential match for Person A. ii. If Person C's registration is under processing, we consider Person C to be a potential match for Person A. iii. If Person D's registration is completed and a UIN is associated, we consider Person D to be a potential match for Person A.

  7. Now the list of Potential Matches for Person A (here, we have Person C and Person D as the potential matches) are sent to Manual Adjudication System to take the final decision.

Manual Adjudication

When biometric duplicates are found in ABIS, MOSIP system sends a request for Manual Adjudication to the Manual Adjudication System via. a queue. The system integrator can build the Manual Adjudication System, which would be listening to the MOSIP-to-ManualAdjudication queue for any Manual Adjudication requests and send a response back in the ManualAdjudication-to-MOSIP system after verifying the data.

The data sent to the Manual Adjudication system is driven by a policy defined in MOSIP and the specification is similar to ABIS identify request.

Request sent to Manual Adjudication System

{
  "id": "mosip.manual.adjudication.adjudicate",
  "version": "1.0",
  "requestId": "4d4f27d3-ec73-41c4-a384-bf87fce4969e",
  "referenceId": "10002100741000320210107125533",
  "requesttime": "2021-01-19T07:16:22.930Z",
  "referenceURL": "http://datashare-service/v1/datashare/get/mpolicy-default-adjudication/mpartner-default-adjudication/mpartner-default-adjudicationmpolicy-default-adjudication202011110619201EpLEjvD",
  "addtional": null,
  "gallery": {
    "referenceIds": [
      {
        "referenceId": "10002100741000120210107111325",
        "referenceURL": "http://datashare-service/v1/datashare/get/mpolicy-default-adjudication/mpartner-default-adjudication/mpartner-default-adjudicationmpolicy-default-adjudication202137493575474iefnvvsD"
      }
    ]
  }
}

Response received from Manual Adjudication System

{
  "id": "mosip.manual.adjudication.adjudicate",
  "requestId": "4d4f27d3-ec73-41c4-a384-bf87fce4969e",
  "responsetime": "2021-01-19T13:16:22.930Z",
  "returnValue": "1",
  "candidateList": {
    "count": "1",
    "candidates": [
      {
        "referenceId": "10002100741000120210107111325",
        "analytics": { //This section is optional and can be decided by the System Integrator.
          "primaryOperatorID": "110011",
          "primaryOperatorComments": "<comments provided by operator>",
          "secondaryOperatorID": "110012",
          "secondaryOperatorComments": "<comments provided by operator>",
          "key1": "value1",
          "key2": "value2"
        }
      }
    ],
    "analytics": { //This section is optional and can be decided by the System Integrator. This is used when there is no match found.
      "key1": "value1",
      "key2": "value2"
    }
  }
}

Process Flow for Biometric Deduplication