Identity Lifecycle Management refers to the process of issuing and managing user identities in a given system. An individual can visit a registration centre to get a new ID or update their ID details. A registration officer would typically capture the individual’s demographic (name, date of birth, gender, etc.) and biometric (face, iris, and fingerprint image) details.
The various life cycle events are briefly explained below:
New ID issuance (for adults and infants)
ID data update or update individual’s information
De-activate or re-activate the individual’s ID
Lost ID
Correction process
Pre-registration is a resident-facing web-based portal that allows a resident to provide registration data, upload document proofs and book an appointment with a registration centre to complete the rest of the registration process. This data can be accessed by the registration officers who could then complete the registration process such as collecting biometrics, verifying the documents and other formalities thus saving time and effort at the registration centre.
A resident can access the pre-registration portal and do the following:
Enter demographic data and upload supporting documents
Book an appointment for one or many users for registration by choosing a suitable registration centre and a convenient time slot
Receive appointment notifications
Reschedule, update and cancel appointments
Registration is a process that allows a resident to provide demographic information and biometrics by visiting a registration centre. The Registration Client operated by a registration officer is used to securely capture the details and send them to Registration Processor for processing and issuance of an ID. If a resident has pre-registered, the registration officer can retrieve the registration data by giving the pre-registration ID to the Registration Client.
The resident visits a registration centre.
The registration officer captures demographic details, biometrics and documents and uploads the same for processing.
Upon successful registration, a registration ID (RID) is allocated to the resident and an acknowledgement slip containing the captured details and the RID is issued (printed) to the resident as proof of registration.
The registration processor processes the registration details perform quality checks and checks for duplicate entries (de-duplication).
Upon successful processing, a Unique Identification Number (UIN) is allocated to the resident and a notification is sent to the resident on the registered phone number and/or email.
Upon a failure in processing, the registration process is discarded and a notification is sent to the resident on the registered phone number and/or email.
A child visits the registration centre along with a guardian/parent.
The registration officer captures the demographic details along with the face photo.
Note: For infants/children less than 5 years old, the Registration Client does not capture the biometrics as they are still evolving. However, the country may choose to override the same by modifying the rules accordingly.
Parent/guardian' UIN or RID and the biometrics needed for authentication are captured.
Additionally, a proof of relationship document is uploaded.
Upon successful registration, an acknowledgement receipt containing the registration ID is issued to the parent/guardian.
Residents can update their information in two ways:
By visiting the registration centre: The demographic and biometric information can be updated at the centres.
Update only the demographic information using Resident Services.
Registration receipt containing the Registration Identity(RID), labels and data in the configured language, and QR code (of the RID) provided to the resident at the centre.
Updated ID credentials were sent to the resident via the country’s configured printing and postal service.
Notifications were sent to the resident using the email ID and mobile number provided as a part of demographic data collection.
De-activate ID means an individual will not be able to authenticate themselves by using the UIN or VID.
If a country wants to deactivate an individual’s ID for any specific reason, the system deactivates the individual’s ID after certain validations are performed in the Registration Processor.
Likewise, a country can also re-activate an individual’s ID as need be.
In the event of loss of the ID, the resident can go to the nearest registration centre and provide his/her biometrics and optionally provide demographic details. The details are sent to the MOSIP server which performs a biometric and demographic match. Upon a successful match, MOSIP provides mechanisms to retrieve the UIN of the resident which may be printed and delivered to the resident. Notifications are sent to the resident's registered email and/or phone.
In case the system finds an error in the demographic data, documents or biometric data provided by an individual, the correction flow is triggered.
Before issuing the UIN for the individual, the incorrect or incomplete information provided by the individual is intimated to them.
Once the corrected information is received by the system, a correction procedure is triggered.
Updated ID credentials are sent to the resident via the country’s configured printing and postal service.
In the context of MOSIP, identifiers are alphanumeric digital handles for identities in the system. While a person's identity is represented as a collection of biographic and biometric attributes that can uniquely identify the person, the identity is referred to using identifiers.
Unique Identification Number (UIN), as the name suggests, is a unique number assigned to a resident. UIN never changes and is non-revocable. UIN is randomized such that one should not be able to derive any Personal Identifiable Information (PII) from the number itself.
The rules that govern generation of a UIN are listed .
The VID / Virtual ID is an alias identifier that can be used for authentication transactions. The key characteristic of such an identifier is that it expires. This allows for free disclosure and usage of this identifier in various contexts. It is privacy friendly in a way such that it can be revoked, configured for one time usage and is not linkable. Since these are used for authentication transactions, such identifiers are to be known to the user only or generated with their participation.
The Application ID (AID) refers to the unique identifier given to a resident during any ID lifecycle event, such as ID Issuance, ID Update, or Lost ID retrieval, at the registration center. It serves as a distinguishing factor for each specific event and can later be utilized by the resident to check the progress or status of the event. Previously, in MOSIP, the Application ID was referred to as the RID (Registration ID) and/or PRID (Pre-registration ID).
The PRID is a specialized RID used in the pre-registration system.
The Token identifier/PSUT is a system provided customer reference number for relying parties to uniquely identify the users in their system. The token identifier is an alias meant for the partner/relying party typically unique (Configured through PMS policy, in case uniqueness is not the need then partner policy can be set to provide random number) to them. This identifier is included in the response of the authentication transactions. One key differentiator is that the PSUT is not accepted as an identifier for authentication transactions. This ensures that the partner who has the PSUT can not reauthneticate.
ID Schema is a standard JSON schema that defines dataset that can be stored in the Identity repository for a resident. The schema allows the adopters to customize the fields that's needed for running the identity program.
Defining the ID Schema is the first step towards creating a foundational ID system. Once defined, all applications built on top of the MOSIP platform must conform to the same.
One should not confuse ID Schema with what is seen on the screen of the Registration client/ Pre-registration. ID Schema is the final data that you would like to store against each user in the final ID Repository. Quite often we collect more data than listed in ID Schema. This is essential to validate the user's claim. We should consider these data as transactional and it will never reach the final ID Repository.
This guide is intended for adopters who would customize the default ID Schema to suit the needs of a specific deployment.
Field: Unit of data collected from residents (eg. fullName, dateOfBirth, proofOfIdentity etc).
Field attribute: Qualification of Field (e.g.: fieldCategory, fieldType, etc).
Definition: Custom data types are defined for collecting different types of data:
simpleType: Multiple languages.
documentType: Document metadata.
biometricType: Biometric file CBEFF XML metadata
bioAttributes:
leftEye, rightEye, leftIndex, leftRing, leftLittle, leftMiddle, rightIndex, rightRing, rightMiddle, rightLittle, rightThumb, leftThumb, face,
fieldCategory
none: Cannot be used for any purpose. But will be stored in id.json (default subpacket). These are used in exceptional cases when we need to store some data for future reference in case of investigating an ID fraud or if law mandates the storage of such data.
pvt: Private information, can be used in authentication. A limited data that can be used for authentication & kyc.
kyc: Information that can be disclosed to partners either as a credential or through the ekyc API's.
evidence: Field is treated as proof and may be subjected to removal. In certain countries law mandates deletion of such data once the Identity of the user is verified. Marking some of the fields as evidence helps in deleting them without violating the source of truth signatures.
optional: Field is treated as proof and will be removed after a predefined interval (defined as policy).
format
lowercased: Value stored in lower case format
uppercased: Value stored in upper case format
none: No format applied to the data
validators
type: Validation engine type. Supported type as of now is regex.
validator: Based on the type the actual script is placed here. In case the type is regex then the actual regex pattern is used here.
arguments: Array to hold parameter or dependent field IDs required for validation.
subType
For every documentType field, document category code must be the value of this key. This document category code is used to validate the provided document types in the ID object.
Refer to the sample ID Schema. A guide to customising the same is given below.
ID schema is loaded as a part of master data to identity_schema table in mosip_masterdata DB.
If any changes are made to the default ID Schema, make sure the following dependencies are updated as well:
UI Specifications
ID Schema is identified based on it's version in the MOSIP system. On publishing of an ID Schema, the schema is versioned. Every ID Object stores the ID Schema version which is validated during ID Object validation.
The following is the list of good practices that MOSIP recommends for creating your ID Schema.
As a privacy by design practice, it is recommended that the number of fields is kept to a usable minimum in order to avoid profiling.
Larger number of data results in serious data quality issues.
Keeping the fields minimum ensures everyone is inclusively added to the foundational identity.
As a best guide, limit the total number of fields to be less than 10.
Stick to one version of ID Schema for better compatibility.
When a country is implementing and running the ID program, people at the forefront, like policymakers and other executives, will need to monitor the progress. Progress can be measured with the help of various attributes, like:
total enrollment count
gender profile for enrollment
age group profile
enrollment numbers and profiles per registration centre
quality of biometric data captured
Information like this will allow policymakers to take corrective measures as and when required.
Some examples are given below:
Example 1: If registration centres are setup for enrolling residents and if they see that the number of women enrolling in a particular area is less because of cultural factors, they can introduce a door-to-door enrollment process to increase coverage.
Example 2: The quality of biometrics captured for a particular registration centre or region can be monitored. And if it is found to be unacceptable, they can proceed to replace the biometric devices in that centre.
Example 3: They can compare the total number of enrollments against the total number of UINs issued. If there is a big gap, they can then address this by increasing the capacity of the registration processor module to handle and process more packets.
In order to achieve this, we have published a fixed anonymized profile of the users and ensured the same is accessible to a search engine such as elastic search so that it can be used for analytics. The basic guideline followed to create these profiles is that the limited dataset should not violate the privacy of the person or point to specific individuals. These JSON profiles are not configurable in the current design and a code change is required to change them.
This dataset is called an anonymous profile and is captured at various stages in the ID lifecycle like pre-registration, registration processing, ID issuance and authentication.
As a part of this implementation, a new anonymous_profile table is created in each of these modules and is populated as per the JSON structure given below for each profile.
Note: New DB tables are added for the anonymous profile because data in existing tables (except the pre-registration module) are encrypted and cannot be used to create reports and dashboards.
This profile will be used to capture data about enrollment. This suggests that the user has started the registration process.
This data is captured at two stages, i.e., during pre-registration and registration processing.
The same registration profile JSON is re-used to capture data in these two modules.
This profile data is captured in anonymous_profile tables under the mosip_prereg mosip_regprc schemas.
We can configure the stage at which the anonymous profile data in the registration processor needs to be captured. This can be configured as a part of the registration processor camel routes in the mosip-config repository as shown below.
The profile will be available from version 1.2.0 and above.
JSON structure of the registration profile is given below
Below is the image for the Anonymous profile table created in the Pre-registration schema
Below is the image for the Anonymous profile table created in the Registration processor schema
This profile data will be captured during the identity issuance process when an entry is made in the ID repository.
The profile data is captured in a anonymous_profile table under the mosip_idrepo schema.
The profile will be available from 1.1.5.5 and above.
JSON structure of the identity issuance profile is given below:
Below is the image for the Anonymous profile table created in the ID repository schema
This profile data will be captured when the resident performs authentication.
The profile data is captured in an anonymous_profile table under the mosip_IDA schema.
The profile will be available from 1.2.0 and above.
JSON structure of the Authentication profile is given below:
Below is the image for the Anonymous profile table created in the IDA schema
Reports and dashboards can be created using anonymous profile data. The reporting framework used for the platform can be used to push this data into elastic search and dashboards can be configured using Kibana. A dashboard created using ID Issuance Anonymous profile data is available as a part of the reference implementation. The same is shown below.
More details about reporting module and dashboards can be found here.
| Module | Table name | Profile name |
|---|---|---|
Pre-registration
anonymous_profile
Anonymous Registration profile
Registration Processor
anonymous_profile
Anonymous Registration profile
ID Repository
anonymous_profile
Anonymous Identity Issuance profile
Authentication
anonymous_profile
Anonymous Authentication profile
