MOSIP as it stands is a modular microservice based architecture. It's modularity helps in adoption of MOSIP at complex situations. Most of the MOSIP modules are designed to be a strong foundation infrastructure modules and can be adopted in several projects.

MOSIP is designed with the following architecture principles. These architecture principles are core to the development of the system's feature and has a great influence on how and why specific software design patterns are used within.

• Data Privacy

• No Vendor Lock-in

• Open Standards

• Async/ Offline First

• Commodity Computing

• Fault tolerant

• Manageable

• Secure By Default

Overview

To know how MOSIP can be deployed, refer Getting Started. The different installation models are detailed out in the Deployment section.

High-Level Reference Functional Architecture

The High-Level Reference Functional Architecture serves as a blueprint outlining the system's high-level functioning and interactions, providing a structured framework.

Overview

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.

UIN

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 here.

VID

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.

RID / AID

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).

PRID

The PRID is a specialized RID used in the pre-registration system.

Token ID (PSUT - Partner Specific User Token)

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.

Overview

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.

Understanding ID Schema

This guide is intended for adopters who would customize the default ID Schema to suit the needs of a specific deployment.

Terminology

• 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

JSON keys

• 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.

Dependencies

If any changes are made to the default ID Schema, make sure the following dependencies are updated as well:

1. UI Specifications

   • Pre-registration

   • Registration Client

2. Identity Mapping JSON

3. ID Authentication Mapping JSON

4. Applicanttype MVEL

Versions of ID Schema

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.

Good Practice

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.