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 is the process to find a duplicate by comparing the individual’s details (biometric and demographic data) with the data stored in the system.
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.
MOSIP System receives a request to perform demographic de-duplication for Person A.
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.
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.
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.
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.
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.
MOSIP system receives a request to perform biometric de-duplication for Person A.
MOSIP system sends an insert request to the ABIS system to insert Person A's biometrics in ABIS via. MOSIP-to-ABIS queue.
ABIS system processes the request sent by MOSIP and sends a response back to MOSIP via. ABIS-to-MOSIP queue.
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.
ABIS System processes the request and sends the list of potential matches back to MOSIP via. a ABIS-to-MOSIP queue.
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.
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.
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.
Registration Processor processes the data (demographic and biometric) of an Individual for quality and uniqueness and then issues a Unique Identification Number (UIN). It also provides functionality to update demographic and biometric data and issue a new UIN if lost. The source of data are primarily from
MOSIP Registration Client
Existing ID system(s) of a country
Important considerations are as follows:
Once the packet is received on the server packets should not be lost.
MOSIP defines and implement the basic registration packet processing flow. However, every country will have their own processing requirements like integration with their existing ID system and fetch data for validation. Registration processor provides options to add such stages.
Registration processor has the capability to integrate with multiple ABIS providers.
Each processing stage is scalable independently based on the load.
Each stage in the processor is independent of other stages such that logic of a stage can be changed to improve efficiency without affecting the overall flow.
Registration Processor Functionality
For detailed description of Registration Processor Services refer to registration processor repo.
For high level and low level design refer to registration processor repo
Refer to build and deploy instructions in registration processor repo.
When an individual visits a registration center to get an ID or update his/her ID details, a registration officer captures the individual’s demographic (name, date of birth, gender, etc.) and biometric (face, iris, fingerprint image) details in a Registration Client. The Registration Client packages the captured information in a secure way (in the form of encrypted packets) and sends it to Registration Processor for further processing.
The packet received from the Registration Client goes through various sanity checks and validations to perform various life cycle events. The various life cycle events that can be processed by Registration Processor are:
New ID Issuance
Update individual’s Information
De-activate individual’s ID
Re-activate individual’s ID
Find an individual’s ID
A new ID issuance requires an individual to visit a registration center and provide the required information to register himself/herself in MOSIP for the first time.
When a registration officer captures an individual’s information, the Registration Client packages the captured information in the form of encrypted packets and sends it to Registration Processor. After the encrypted packet reaches the Registration Processor, the system tries to find a duplicate using the individual’s information (i.e. demographic and biometric information) in the system (this process is known as De-duplication). If the system does not find any duplicates of the individual’s information, then the system registers the individual and allocates a unique ID and sends his/her ID credential through the country's configured printing and postal service .
During the allocation of the Unique Identification Number (UIN), the system also allocates a Virtual Identification Number (VID) to the individual. VID is an alternative to UIN and is a temporary number that can be used for authentications of an individual. The individual can provide the VID instead of UIN to authenticate themselves and protect their UIN from being accessed by someone else.
MOSIP generates two types of VID such as Perpetual VID and Temporary VID.
Perpetual VID: Registration Processor will create a new perpetual VID once UIN is generated successfully.
Temporary VID: As the name goes, it is shortlived which expired after a pre-defined period after which a new temporary VID has to be re-generated. Temporary VIDs are generated by residents using resident services.
After an ID is created for an individual, then he/she can choose to update his/her demographic or biometric information. The system provides two different channels by which an individual can update his/her information - by visiting a registration center and by using the resident services.
In both the cases, the individual’s information is securely packaged and sent to Registration Processor. After all successful validations, the system updates the individual’s information and sends his/her updated ID credential through the country’s configured printing and postal service.
Information that can(not) be updated that includes both biometric and demographic data can be customized. In the current implementation,
An individual can update his/her demographic and biometric information when he/she visits the registration center.
An individual can update his/her demographic information when he/she uses the resident services.
This feature is used to de-activate an individual’s ID. When an individual’s ID is deactivated, then he/she will not be able to authenticate himself/herself by using UIN or VID.
If a country wants to deactivate an individual’s ID due to any specific reason, the system deactivates the individual’s ID after certain validations are performed in Registration Processor.
This feature is used to re-activate an individual’s deactivated ID. When the individual is re-activated then he/she will be able to authenticate himself/herself by using UIN or VID.
If a country wants to reactivate an individual’s deactivated ID due to any specific reason, the system reactivates the individual’s deactivated ID after certain validations are performed in Registration Processor.
When an individual forgets their ID information he/she can find it by providing their biometric information in the Registration Center. Registration processor then uses the captured biometrics to find the individual’s ID and sends his/her ID credential to their registered address through the country's configured printing and postal service.
Orchestration is the process of configuring various independent services, which will coordinate and manage to achieve a business goal.
In Registration Processor, there are various independent stages (such as Packet Receiver Stage, Packet Validator Stage, Operator Supervisor and Introducer Validator Stage, Demographic Deduplication Stage, Biometric Deduplication Stage, UIN Allocator Stage, Notification Stage, Printing and Postal Stage, etc.), which will perform their own set of validations or operations.
These stages are connected to each other using a workflow manager to perform various ID lifecycles events for an individual.
Registration Processor interacts with multiple external systems where there is a certain probability of failures due to various reasons such as network issues, unavaibility of external systems etc.
Registration Processor retries processing of the stage after a configurable period of time.
MOSIP system has the capability to recover and continue packet processing if any incident happens which stops processing of some of the packets. These incidents can be: an external/internal stage is not responding, database connection is lost, dependent packets have not been processed, etc.
In case of such incidents, the system have a mechanism in place which identifies any packets that are stuck at a particular stage for a long period of time and resume processing at a configured time.
Packet processing is divided broadly into three sections such as pre-processing, processing and post processing. Each section has a set of stages which are orchestrated together to create workflow. A System Integrator can customize workflow by adding or by removing stages.
If a country wants to integrate MOSIP with their system to share information to/from MOSIP then MOSIP has provision for system integrator to plugin external system to pull or push data very easily with some customization in the workflow.
Registration processor architecture gives flexibility to customize the workflow to plug-in additional stages and exclude existing stages as per the business need.
An ID goes through various lifecycles (ID issuance, update of ID information, activating or deactivating an ID) and each lifecycle has its own set of stages to achieve the end goal.
These stages are glued together to form a workflow. Hence, based on the ID lifecycle, Registration Processor has multiple workflows.
Having multiple workflow increase reusability of stages, readability of workflow configured for each event and maintainability of each workflow which also involve customizing workflow based on the country’s need.
MOSIP is scalable so that it can handle any kind of processing load or request in the future without disturbing the base architecture. MOSIP infrastructure can handle additional processing request based on the requirement of a country. The architecture is designed in such a way that it is flexible to support scalability and holds the request until the end goal is achieved.
When Registration Processor receives a packet, the system performs various sanity checks on the packet, such as:
Authentication of the request: If the request is coming from a verified source.
Virus scan: In-memory virus scan of the packet received.
Packet integrity check: If the packet received was not tampered during transit by performing checksum validation.
Packet size check: If the packet received was not tampered during transit by validating the size of the packet.
Packet format check: If the packet format is per the configured format.
Duplicate check: If the request received is not a duplicate request.
Virus Scanning is an important process, which helps to detect and move the virus infected packets to the quarantine zone. With a good virus scanner integrated in MOSIP will prevent virus interference.
Whenever virus scanning is performed in Registration Processor, the encrypted packets are first scanned and then the packets are decrypted in-memory and scanned.
Virus scanning is performed twice in Registration Processor:
When a packet is received by Registration Processor.
When Registration Processor stores the packet in its internal secure file system.
When a packet is created in Registration Client, the packet will be created using a registered machine, devices, registration officer, registration supervisor, and registration center.
To make sure that the packets are created as per the defined rules, the system performs the following validations:
Registration Center must be active when the packet was created.
User (registration officer/registration supervisor) must be active when the packet was created.
Machine and devices, in which packet was created must be active when the packet was created.
User, machine and center must be mapped when the packet was created.
Packet must be created in working days and not in holidays.
The GPS must be captured when a packet is created.
When a packet is created in Registration Client, the officer or supervisor will authenticate himself/herself, and the same is captured in the packet. There are three modes by which an officer or supervisor can authenticate himself/herself, which are listed below:
Biometric authentication
Password based authentication
OTP based authentication
In the case of biometric authentication, the Registration Processor authenticates the officer/supervisor again after receiving the packet from the Registration Client.
Data quality check
The system provides a feature to integrate with an SDK to identify and validate the age and gender captured by the registration officer against the photo of the resident.
This validation helps the system to identify the mistakes, that are performed by the registration officer.
This is factored for future releases and is not part of the current implementation.
Biometrics quality check
The biometrics captured (face, fingerprint, or iris) for an individual is used to authenticate the individual. If the quality of the biometric image captured during registration is low, then authentication for the individual using biometrics will not be accurate.
Hence, the system provides a feature to integrate with an SDK to validate if the quality of biometrics captured of an individual is above the configured threshold. If the quality of the biometric captured is lower than the threshold configured, then the Registration Processor does not allow ID generation for the individual.
Doc validation - OCR*
When an individual visits the Registration Center to get an ID or update his/her information, the officer manually enters various demographic information for the individual, which might cause a human error. To avoid such issues, the system provides the feature to integrate with an SDK, which validates the fields that are manually entered against the corresponding documents.
This is factored for future releases and is not part of the current implementation.
File & document validation
When the Registration Packets are received from the Registration Client, the system checks if all the files listed in the packet are available. If available, the system verifies if the documents required for an individual are present in the packet as per the data captured. To perform this validation, the mapping of the data captured and the mandatory document required can be configured by the country.
For Example:
If the name is captured, the country can add a validation for Proof of Identity.
If the address is captured, the country can add a validation for Proof of Address.
Introducer validation
An Introducer in MOSIP introduces someone attempting to register without any valid document or proof of identity. In the current implementation, in the context of Minor's registration, the Introducer is the parent or guardian of the minor (child) who approaches the center for registration.
A minor is not mature enough to provide biometrics (like fingerprints or iris) as they are underdeveloped during the time of registration, hence, the parent or guardian acts as the Introducer to register the minor in MOSIP.
When a minor is registered, the Registration Client mandates the capture of the ID and biometrics of the parent or guardian, which is used for authenticating the parent or guardian in the Registration Processor.
To support the Principle of Inclusion, an Introducer can be any individual whose biometrics are registered in MOSIP.
Deduplication – demographic, biometrics
Deduplication is the process of finding a duplicate by comparing the individual’s details (biometric and demographic data) with the data stored in the system.
Demographic deduplication
The system compares the demographic details (name, gender, and date of birth) of the individual with the data available in the system to find a potential match.
If a potential match is found, then the system sends the packet to ABIS to perform a 1:1 biometric match (it is an additional check to confirm that it is a duplicate).
If a potential match is not found in ABIS or demographic deduplication, then the system sends the packet to perform biometric deduplication.
Biometric deduplication
The system performs biometric deduplication (1:N, where N indicates the whole set of biometric available in the system) by sending the data to ABIS
ABIS compares the biometric data received with the whole set of data to find a potential match based on a configured threshold.
If a potential match is found in the ABIS, then the system sends the packet for manual adjudication.
If a manual adjudicator (experts who know more about biometrics) finds a duplicate, then the system rejects the packet.
If the manual adjudicator or ABIS does not find a duplicate, then the system sends the packet for UIN generation.
All the below functions can be plugged in by a System Integrator into the MOSIP system. MOSIP provides interfaces for integration.
Data verification
Data verification is a process in which the system can verify the data captured during registration with the data received from an external system to ensure accuracy and consistency. It helps to determine whether data was accurately translated, is complete, and supports the interoperability standards.
The System Integrator can plug-in a stage in the workflow, where the stage can communicate with any external system to receive some information and validate it with the information captured at the Registration Center.
Data Enrichment
Data enrichment is a value-adding process, where external data from multiple sources is added to the existing data sets in MOSIP to enhance the quality and richness of the data. MOSIP receives some data from the external system in the form of a Packet (as per MOSIP Standards). The system can receive this updated packet from external sources and process it with the packet received from the Registration Client.
Manual verification for external system data update
When there are any discrepancies between the data received from the external system vs. the data captured during registration, a country may opt to manually verify the data. The System Integrator in such case may build a Manual Verification Module for external system data mismatch.
Manual adjudication
When biometric duplicates are found in ABIS, the System Integrator can plug in the Manual Adjudication Stage, which would send the biometric and demographic data of the duplicates to a Manual Adjudicator. The Manual Adjudicator now can perform various validations on the duplicate data and inform the MOSIP system if the two records are duplicates or not.
ABIS integration
The MOSIP System, to perform biometric de-duplication (validate if there are no biometric duplicates in the system), integrates with an ABIS.
ABIS Middleware which is designed by MOSIP and MOSIP Middleware designed by ABIS is used to communicate between the MOSIP system and ABIS.
Identity generation - UIN generation and association
After all the business validations are completed, the system gets a Unique Identification Number (UIN) from the UIN generation API and allocates the UIN by sending the new UIN number and the individual's information to the ID Repository.
Store/update ID Repository
After all the business validations are performed for a new ID issuance or updating an individual’s information, this information is sent to the ID Repository for storing or updating the information respectively.
Data extractor for ID authentication
The system extracts the latest copy of an individual’s data after the individual has registered in MOSIP or has updated their data in MOSIP and sends it to ID Authentication. Now, ID Authentication can use the latest copy of the individual’s data for authentication.
When any transaction is performed in the MOSIP system or the packet fails any validations or any system-level exception happens, then the same is captured as part of MOSIP audit trails, which can be further used for reporting/analytics as required.
Notification (SMS/Email as configured), which is received by an individual is the final step of all the life cycle processes. The system sends a notification to the individual for various life cycle scenarios such as successful or unsuccessful issuance of UIN, update of UIN data, activate or deactivate UIN, finding a lost UIN, etc. using templates defined in the system.
When an individual’s ID is created or an individual’s data is updated, the system sends the individual’s physical ID credential to the individual’s registered address.
This feature is the post processing integration point for the Registration Processor, where a country can generate the PDF of the individual’s ID and sends it to the country’s configured printing and postal service provider. The printing and postal service provider in turn would print the physical ID credential and deliver it to the individual’s registered address.
After the Registration Client sends the packet to Registration Processor, it starts processing the packet. Registration Processor enables the Registration Client to know the processing status of such packets. The probable packet statuses are as follows:
PROCESSING: The packet is under processing.
PROCESSED: The packet has been processed and Registration Client deletes the packet from its storage location.
RESEND: Initial validation like virus scan and packet integrity check have failed for the packet for a configured number of times and Registration Client needs to resend the packet for processing.
RE-REGISTER: The packet has failed a business validation like center-machine check, supervisor and officer validation, etc., due to which the system will not be able to process the packet. The registration officer will intimate the individual to come back to the center and re-register, post which registration client can delete the packet from its storage location.
REJECTED: A duplicate packet was found against the individual’s biometrics. As processing of the packet is completed, Registration Client can delete the packet from it storage location.
ID Object describes attributes that a country or entity will capture from an Individual. Since MOSIP is a generic identity platform the attributes of an ID cannot be predefined by MOSIP. One country may capture, say, 5 attributes and another 10. So to accommodate this flexibility MOSIP provides a feature to define ID Object. This will be the first step in using MOSIP. Once an ID Object is defined all applications built on top of MOSIP platform must conform to the same.
In order to define the ID object, MOSIP adopters need to analyze the attributes that they need in their ID object. We have provided a sample excel which might be helpful for adopter to analyze their ID attributes. The items that the adopter needs to analyze as part of tis exercise are:
ID attributes that would be collected to identify a resident uniquely. Example: Attributes such as, Name, Gender, DateOfBirth, Address, Biometrics etc.
Additional evidence attributes that would be collected as evidence. Example: Attributes such as proof documents (Identity, Address, Date of Birth, Relationship, etc) or Introducer.
Optional attributes that would be collected for processing purpose but might need to discarded later.
Validations for the above attributes. Example: Basic reg-ex validations for text fields, flow validations for capturing evidence data.
Various work flows for various types of applicants (say, a minor or a resident without any evidence, etc.)
Once an adopter has proper clarity on the above topics, it is very easy for them to construct an ID schema.
ID schema is a JSON schema which would be used for defining the structure, content, and (to some extent) semantics of an ID object. It lets us specify metadata (data about data) about what an ID object’s attributes mean and what values are valid for those attributes.
We use the ID schema JSON to validate the ID object when,
ID object is created in Pre-registration
ID object is created in Registration Client
Packet is opened in Registration Processor
ID data is stored in ID Repository
Below is a sample ID schema JSON.
ID JSON is an instance of the ID Schema (derived from ID Schema). It contains the basic details of an individual so that we can uniquely identify them in MOSIP.
Below is a sample ID JSON for private packet as per the schema defined above:
UI specification helps us identify how the data in an ID attribute (attributes of an ID object) is going to be retrieved from the UI. The UI screens in registration client application and pre-registration application are rendered using their respective UI specification JSON. We have different UI Specifications for Registration Client & Pre-registration which is derived from the ID Schema.
For details about the UI specification of registration client & pre-registration please visit the respective pages,
