The MOSIP philosophy is to provide a "Good ID". As part of this MOSIP embraces a core set of design and architecture principles that allow the platform to offer best practices for a Good ID system. MOSIP is built on the following architectural principles

• MOSIP must follow a platform-based approach so that all common features are abstracted as reusable components and frameworks into a common layer

• MOSIP must follow API first approach and expose the business functions as RESTful services

• MOSIP must not use proprietary or commercial license frameworks. Where deemed essential, such components must be encapsulated to enable their replacement if necessary (to avoid vendor lock-in)

• MOSIP must use open standards to expose its functionality (to avoid technology lock-in)

• Each MOSIP component must be independently scalable (scale out) to meet varying load requirements

• MOSIP must use commodity computing hardware & software to build the platform

• Data must be encrypted in flight and at rest. All requests must be authenticated and authorized. Privacy of Identity Data is an absolute must in MOSIP

• MOSIP must follow the following manageability principles – Auditability & monitor ability of every event in the system, testability of every feature of the platform & easy upgradeability of the platform

• MOSIP must follow the principles of Zero-Knowledge which means that the services know nothing about the Personally Identifiable Information (PII) data stored.

• MOSIP components must be loosely coupled so that they can be composed to build the identity solution as per the requirements of a country

• MOSIP should work with different locales so that ID systems can be localized for languages and cultures easily.

• All modules of MOSIP should be resilient such that the solution as a whole is fault tolerant

• The key sub-systems of MOSIP should be designed for extensibility. For example, if an external system has to be integrated for fingerprint data, it should be easy to do so.

The key design aspects considered for MOSIP are

Ecosystem approach

The MOSIP platform is a framework and an end-to-end solution that needs additional components. For example, biometric devices and ABIS solutions are key to processing an individual's data and proving uniqueness. Through a well-defined set of standard interfaces, MOSIP allows for the integration of such components and offers a choice of providers for the same. MOSIP also needs to cater to a diverse set of institutions wanting to authenticate an Individual against the data stored in MOSIP. So, the key parameters are

• All public/external facing interfaces of MOSIP must be standards-based for interoperability.

• 3rd party components should be integrated via standard interfaces and offer a provider model where needed.

Configurability

MOSIP should be flexible for countries to configure the base platform according to their specific requirements. Some examples of configurations in MOSIP are

• A country should be able to choose the features required. For example, it must be possible for a country to turn off Finger Print capture

• A country should be able to configure the attributes of an ID Object

• A country should be able to define the length of the UIN number

Extensibility

MOSIP should be flexible to extend functionality on top of the basic platform. Some examples of extensibility are

• A country should be able to introduce a new step in processing data

• Integrate MOSIP with other ID systems and include it as part of the MOSIP data processing flow

Modularity

All components in MOSIP should be modular and their features exposed via interfaces such that the implementation behind the interface can be changed without affecting other modules. Some examples of modularity are

• The UIN generator algorithm provided by the platform can be replaced by a country with their own implementation

• The default demographic de-duplication algorithm provided by MOSIP can be changed to a different one without impacting the process flow

Note on documentation: Information on the MOSIP architecture and design is distributed between and the design folders of the various .

As the world races towards a fully digital economy, foundational IDs and ID systems become an essential building block in establishing digital trust. They are also an essential part of Government to People (G2P) initiatives. MOSIP as a foundational ID platform delivers a key ingredient of the fabric of digital governance systems.

Pillars of a Digital Future

• Digital Identity and Trust

The MOSIP Program

The MOSIP program was conceived to help build global digital public goods in the space of digital governance. The flagship of the program is the MOSIP platform which provides the core for a foundational identity system that can be used by countries to build their national identity programs. Anchored at the International Institute of Information Technology, Bangalore (IIIT-B), MOSIP harnesses the power of open source and embraces the best practices of scalability, security and privacy. Learn more >>

About MOSIP

The Modular Open Source Identity Platform is an open-source, open standards-based foundational identity platform. MOSIP is an API-first platform that can be used by countries to build their own national id platform. MOSIP offers id life-cycle management features and identity verification capabilities out of the box.

The key objectives of MOSIP are to:

• Provide the basic framework to create a fully functional foundational identity system

• Provide flexibility for a country to choose and customize the features from the basic framework according to their requirements

• Maintain privacy, security and confidentiality of an individual's data

Releases

The latest release of MOSIP, version 1.1.5 is here! We have added many interesting features as part of this release and also incorporated some software infrastructure changes as part of paring the technical debt. Check out the exciting new services and enhancements in the documentation.

Current Release Version: 1.1.5 Release Date: March 23, 2021 You can find the release notes .

Previous Release Version: 1.1.4 Release Date: February 12, 2021 You can find the release notes .

To view the summary of our releases, click .

MOSIP Resources

Source Code: Containers: Maven Repository: Presentations: Learning Videos: Community:

Roadmap

The MOSIP roadmap in the short term is the release of our Long Term Support Version. Our medium-term focus is to enable reference implementations of identity usage, integrations and interoperability. The long-term focus is to offer a set of core components for digital governance. Check out our and to see how you can be part of the MOSIP journey.

Overview

This module enables a resident to:

• Enter demographic data & upload supporting documents

Overview

Resident services are the self services which is used by the resident themselves via a portal. Functionalities such as lock/unlock authentication types, reprint UIN, view authentication history etc. are available. The services use OTP method of authentication.

The back-end is a set of services with REST API interface (provided by MOSIP) and front end is a portal to be developed by the adopter according to their requirements.

This section contains details related to MOSIP data model design.The section also provides the data dictionary of the tables and columns defined by MOSIP databases.

Data Model Considerations

• Meaningful Naming: DB objects that are being created will have a meaningful naming.

• Flexible model: No business rules are set at the database level other than few mapping data. Most of the business logic is applied at application layer.

• Database specific features: Use of DB specific features like defaults, DB sequences, identify fields are not used

• No business logic at DB: No business logic implemented at database level other than PK, UK, FKs.

• Data Security: Individual and security related information is encrypted

Data Model

Databases inventory in MOSIP.

MOSIP can be configured to work with proxy implementation and multiple biometric modalities (fingerprint, iris and face). Below are configurations to enable biometrics in MOSIP.

Registration Client

Adding SDK in classpath

Biometric Windows SDK (jar file) should be placed in lib folder after extracting Registration-Client zip file, and then execute run.bat file.

Enabling MDS integration

The below property should updated to enable MDS integration. This property is present in file.

Registering biometric devices for registration

• Register Device Provider - Device Provider can be registered with MOSIP using

• Register MDS - MDS can be registered with MOSIP using

Enabling biometric for officer and supervisor

Biometric authentication for officer and supervisor can be enabled by updating the is_active column to true in mosip_master.app_authentication_method table. List of processes for which biometric authentication can be enabled in registration client

• packet_auth (Authentication when packet is created)

• login_auth (Login to registration client)

• exception_auth (Authentication when an exception packet is created)

By default, username password based authentication is enabled for all the above processes.

Enabling local de-duplication

Below properties should be enabled for performing local de-duplication. These properties are present in config file

Registration Processor

Configuring ABIS queue

ABIS queue can be configured in file. registration-processor-abis-middleware-stage communicates to ABIS through queue configured. It sends request to inbound queue address and receives response from outbound queue address. If there are multiple ABIS, then it can be added in same file.

ID Authentication

Adding SDK in classpath

Below properties should be set in id-authentication-{env}.properties. The classes configured below will be loaded in classpath during application initialization.

Registering biometric devices for authentication

• Register Device Provider - Device Provider can be registered with MOSIP using

• Register MDS - MDS can be registered with MOSIP using

Encrypting biometric data from MDS

In order to capture encrypted biometrics from MDS, MDS should use Mosip Public Key. This key should be generated in MOSIP with IDA-FIR as reference-ID for Parter-based Individual Authentication and 'INTERNAL' as reference-ID for Internal Authentication.

Background

The data level encryption is handled in the DTO layer in the application.

Solution

The key solution considerations are

• Following are the key considerations of the encryption in the DTO layer,

  • The data are classified into,

    • Sensitive

Encryption

• Decryption:

  • When a request is received, the DTO fields are checked for sensitivity, from the config server.

  • If the DTO field is sensitive, the decryption() method is called.

Decryption

• Key rotation

  • On-Demand:

    • The keys are stored with the expiry date.

Design choices

The MOSIP architecture decisions have been based on the Guiding Principles defined in the charter. The design choices are in line with the need for modularity, loose coupling and scalability of its components, and being API first.

• Micro-service based architecture for all platform services for modularity and scalability.

• Staged Event Driven Architecture (SEDA) for processing Registration data for extensibility.

• Thick client architecture for the registration client to support offline operations as well as process security.

The sections below provide different views of the logical architecture of MOSIP.

Functional Architecture

From a MOSIP perspective, several actors are involved in the ID system.

• The Individual or the Resident is at the centre of it all. It is their identity that the system deals with.

• The Officer is a representative of the ID issuer. There are several specialized roles for the officer.

  • The Operator

The diagram shows the functional architecture of mosip with the actors.

Modular Architecture

Mosip has several modules that offer related functionality. These include the core modules of

• Pre-registration

• Registration client

• Registration processor

and the support modules

• Partner Management

• Administration

• Reporting

Note: All user interface modules are reference implementations and can be used as is, refactored or customized or replaced with alternative implementations in the actual deployment.

The diagram below shows the various modules of mosip with their respective service bouquets and their interaction.

Overview

The registration client is a thick Java-based client where the resident's demographic and biometric details are captured along with the supporting documents in online or offline mode. The captured information is packaged in a secure tamper-proof way and send to the server for processing.

Registration client must provide the following :

• Secure way of capturing an individual's demographic and biometric data. The captured data must be cryptographically secure such that the data cannot be tampered with. This is called a registration packet.

• Interfaces to biometric devices that comply to industry standards. This ensure that any device manufactured as per standards will work with MOSIP.

• Works in online and offline mode. In remote areas where internet connectivity is a challenge, the registration client must work in offline mode.

• Remote software update capability. There must be a way to self-update to latest patches/upgrades (bug fixes/enhancements) in a remote way. There could be hundreds of client instances running on laptops/desktops. Updates on all of them must be controlled a central server.

• Tamper-proof client software. The registration client must have an ability to validate the structure of the information captured so that it could detect any anomoly due to a possible manual tampering and reject the captured packet.

Detailed functionality

Process flow

Registration officer Onboarding

Registration preparation

Individual registration

Packet upload

End of day (EOD) process

UIN update

Lost UIN

Software update

Logical view

Component architecture

Registration packet structure

All the registration information is zipped and encrypted in a packet and sent to the server. The structure of the packet is given .

Registration client reference application

MOSIP provides an Windows-based reference implementation of the client that has a UI and the business logic to perform the above process flows. The code, design, App setup, build documentation is available in . The App may be modified according to a country's need.

First user on-boarding

TBD

Please find below the sequence diagrams for auth flows.

Login flow:

Resource request flow:

Service to Service communication:

Documentations for the Auth Implementations

This document detailed out the design approach to integrate with the list of devices used in the MOSIP platform.

Interface approach has been taken to implement the integration with external devices. The interface should have the required method to communicate with the external devices. An Abstract class has been defined to implement the common functionality and it should be extended by Vendor specific implementation class. The device vendor's specific implementation class should extend the Abstract class and implement the required methods using available libraries.

Devices:

1. Scanner

2. Printer

3. GPS

Scanner:

Interface: IMosipDocumentScannerService

1. public Boolean isConnected() - to check the scanner connection availability.

2. public BufferedImage scan() - to scan the document from the scanner device.

Abstract Class: DocumentScannerService

1. public byte[] asPDF(List bufferedImages) - to convert the captured scanned document files into pdf format.

2. public byte[] asImage(List bufferedImages) - to convert the captured scanned document files into image format.

3. public byte[] getImageBytesFromBufferedImage(BufferedImage bufferedImage) - to get the byte[] from BuffredImage object.

Printer:

Use the JavaFx provided print functionality to interact with printer directly from UI layer. No additional interface is required. javafx.scene.web.WebView.getEngine().print(PrinterJob)

GPS:

Interface:IMosipGPSService

1. public String getComPortGPSData (String comPortNo, int portReadWaitTime) - it returns GPS signal in standard format.

Abstract Class:IMosipGPSServiceImpl

1. public GPSPosition sigalParser(String line) Inputs: gps signal (Ex: $GPRMC,055218.000,A,1259.4845,N,08014.7602,E,0.07,120.70,171018,,,A*64)

   • returns the latitude and longitude from the GPS signal.

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.

This document describes the registration packet structure and the packet encryption procedure.

Registration Packet

Once a resident visits the registration center and provides their demographic & biometric details an encrypted zip file is created which is called a "Packet". This packet can only be decrypted by the registration processor using a private key available in the Kernel Key Manager.

The below diagram depicts the packet creation flow using the packet manager.

Overview

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

Overview

ID Repository contains the record of identity for an individual, and provides API based mechanism to store, retrieve and update identity details by other MOSIP modules. ID Repository is used by:

• Registration Processor

Overview

ID Authentication (ID Auth) provides an API based authentication mechanism for entities to validate individuals. ID Authentication is the primary mode for entities to validate an individual before providing any service.

Following are the pre-requisites for an entity to do authentication of an individual

Overview

Kernel is on which MOSIP services are built. Kernel is a platform to build higher-level services as well as a secure sandbox within which the higher-level service functions. Kernel provides a bedrock to build and run the services by providing several significant necessary technical functions so that individual services are concerned with specific business functions.

Kernel is not a distinct module but a bunch of services and libraries that are shared across different modules.

Steps to generate the first User in MOSIP eco-system, refer below for the process:

1. Creating the First User in KeyCloak

• First the role "Default" need to be created in KeyCloak with all other roles.

Context

Scalability of complex systems is non-trivial especially when there are multiple running components like microservices, databases, storage clusters etc. with complex interactions. End-to-end performance modelling of such a system poses significant challenges as the performance of the 'whole' does not have a straight-forward linear relationship to its 'parts'.

MOSIP recommends a cell architecture where hardware and software within a cell is fixed (canned), and the cell is benchmarked for input/output capacity. Such cells, then, may be replicated to scale up capacity in a production depolyment with traffic diverted to them via a load balancer. Ideally, each cell must be islolated from each other without any cross-dependencies. Practically, however, they may share certain resources. Scalabilty of such common resources needs to addressed separately.

In MOSIP, Authentication largely falls into the below categories:

• Authentication via web channel (for Pre-Registration web application, Admin web application and Resident portal)

• Authentication via local system i.e., offline authentication (for Registration client)

In MOSIP, Authorization falls into the below categories:

The MOSIP narrative and documentation uses terminology which can be hackneyed, cryptic or loaded at times. The ID industry also uses this terminology in different contexts will different shades of meaning. Here we provide a set of such terms and their interpretation in the context of mosip.

Note: This document is work in progress.

A Assurance Level

Authentication

AuthN and AuthZ

B

C Consent

Pre-requisite

MOSIP issues are maintained in . File the issue against the right repository.

The Resident Service module will provide a host of services to an individual which can be availed after the creation of their Unique Identity Number (UIN). The list of services are as follows:

• Update of Demographic Data (UIN update)

• Track Request Status

• Lock/Unlock AUTH types

• Download e-UIN

• Retrieve Lost Request ID(RID)/UIN

• Reprint UIN

• View Authentication Transaction History

• Generate/revoke Virtual ID (VID).

All these features are detailed in the following features section.

Features

Track status of UIN Generation

This feature will allow an individual to track status of his/her UIN generation. The individual needs to provide the RID (Request ID received during UIN registration) as input. The system will validate this RID. On successful validation, the system will send the status of UIN generation to the individual's registered mobile number and/or email ID. The system will also send a notification message to individual’s mobile number and/or email ID after a successful transaction or appropriate error message if the transaction was not successful.

Download e-UIN

This feature will allow an individual to download his/her electronic UIN. The individual needs to provide the UIN/VID, full name, postal code, and security code as input. The system will validate the provided data, trigger an OTP to individual's registered mobile number and/or email ID, validate the OTP and then authenticate the individual. On successful authentication, system will send a link to the individual's registered mobile number and/or email ID to download his/her password-protected e-UIN in PDF format. The system will also trigger a notification message to the individual's registered mobile number and/or email id after the transaction or appropriate error message if the transaction was not successful.

Retrieve Lost RID

After the UIN application is submitted by an individual providing the required demographic, biometrics and supporting documents and filling up the enrollment form by visiting a registration center, the system generates a unique RID (Request ID) as an acknowledgment number. If the individual misplaces this RID, this feature will allow an individual to retrieve his/her lost RID to subsequently trace the associated UIN. The individual needs to provide his/her Full Name, Mobile Number and/or E-Mail ID, Postal Code that was provided during registration as input. The system will first validate the individual's provided data, trigger an OTP, and perform OTP validation on the given mobile number and/or email ID. On successful validation, the system will send a link to password protected PDF containing the RID to individual's registered mobile number and/or email ID. The system will also trigger a notification message to the registered mobile number/email ID after a successful transaction or appropriate error message if the transaction was not successful.

This feature is not yet developed in MOSIP.

Retrieve Lost UIN

This feature will allow an individual to retrieve his/her lost UIN. The individual needs to provide the Full Name, Mobile Number and/or E-Mail ID, Postal Code as input. The system will first validate the individual's provided data, trigger an OTP, and perform OTP validation on the given mobile number and/or email ID. On successful validation, the system will send a link to the individual's registered mobile number and/or email ID to download his/her password-protected UIN in pdf format. The system will also trigger a notification message to the registered mobile number and/or email ID after a successful transaction or appropriate error message if the transaction was not successful.

This feature is not yet developed in MOSIP.

Re-print Request of UIN

This feature will allow an individual to raise reprint request of his/her UIN. The individual needs to provide the UIN/VID as input. The system will first validate the individual's UIN/VID, trigger an OTP to individual's registered mobile number and/or email ID, validate the OTP and then authenticate the individual. On successful authentication, the system will take the UIN reprint request and acknowledge the request with a Request ID (RID) to the individual. The system will also trigger a notification message to the registered mobile number and/or email ID after a successful transaction or appropriate error message if the transaction was not successful.

Initiate UIN Update

This feature will allow an individual to initiate update of his/her demographic details. Currently, an individual can initiate an update of the address associated to the provided UIN/VID. However, this service can be extended to further update any other aspect of the demographic data (EG: Mobile, Email, etc). The individual needs to provide the UIN/VID as input. The system will first validate the individual's UIN/VID, trigger an OTP to individual's registered mobile number and/or email ID, validate the OTP and then authenticate the individual. On successful authentication, the system will generate and send a Request ID (RID) for UIN update to individual's registered mobile number and/or email ID. The system will also trigger a notification message to the registered mobile number and/or email ID after a successful transaction or appropriate error message if the transaction was not successful.

Track Status of UIN Update

This feature will allow an individual to track status of his/her UIN update. The individual needs to provide the RID ( Request ID for UIN Update) as input. The system will first validate the RID, trigger an OTP to individual's registered mobile number and/or email ID, validate the OTP and then authenticate the individual. On successful authentication, the system will send the status of UIN Update to individual's registered mobile number and/or email ID. The system will also send a notification message to individual’s mobile number and/or email ID after a successful transaction or appropriate error message if the transaction was not successful.

View History of Authentication Requests

This feature will allow an individual to view history of the authentication request(s) associated to his/her UIN. The individual needs to provide the UIN/VID as input. The system will first validate the UIN/VID, trigger an OTP to individual's registered mobile number and/or email ID, validate the OTP and then authenticate the individual. On successful authentication, the system will send unarchived Authentication History data of the individual associated to the provided UIN and all its associated VIDs. The system will also send a notification message to individual’s mobile number and/or email ID after a successful transaction or appropriate error message if the transaction was not successful.

Lock/Unlock Authentication

An individual can decide to lock specific Authentication Types (Demographic/Biometrics) of his/her UIN/VID for security reasons. It can be for one or more Authentication types. The locked Authentication Type(s) cannot be used for any future authentication request. Similarly at any point he/she may also request to unlock one or more locked Authentication types which was locked earlier.

Lock the UIN

This feature will allow an individual to lock the requested Authentication Type (Demographic, Biometrics (FP/Iris/Face/All)) associated with his/her UIN/VID. The individual needs to provide the UIN/VID as input. The system will first validate the individual's UIN/VID, trigger an OTP to individual's registered mobile number and/or email ID, validate the OTP and then authenticate the individual. On successful authentication, the system will first send the details of all Authentication Types to the individual. The individual will then select which Authentication Type(s) will need to be locked. The system takes the request, locks the specified Authentication Type(s) and then notifies the individual. The system will also send a notification message to individual’s mobile number and/or email ID after a successful transaction or appropriate error message if the transaction was not successful.

Unlock the UIN

This feature will allow an individual to unlock requested Authentication Types (Demographic, Biometrics (FP/Iris/Face/All)) which is/are in locked status associated with his/her UIN/VID. Once unlocked, the individual can again use these Authentication Type(s) for any future authentication purpose. The individual needs to provide the UIN/VID as input. The system will first validate the individual's UIN/VID, trigger an OTP to individual's registered mobile number and/or email ID, validate the OTP and then authenticate the individual. On successful authentication, the system will first send the details of all Authentication Type(s) to the individual which is/are in locked status. The individual will then select which Authentication Type(s) need to be unlocked. The system takes the request and accordingly unlocks the Authentication Type(s) and notifies the individual. The system will also send a notification message to individual’s mobile number and/or email ID after a successful transaction or appropriate error message if the transaction was not successful.

VID Service

To safeguard the confidentiality of a UIN and for its security, Virtual ID (VID) service is provided. Based on the VID policy (defined by Country), an individual will be provided a VID during UIN registration and also he/she can create this using 'Resident Services'. The VID policy attributes defines the type of the VID, Country can name the VID as desired. VID policy constitutes time validity, no of instances, no of transactions, regeneration mode.

VID services comprise of the below.

Generate a VID

An individual can request to generate a Virtual ID via Resident Service by providing his/her UIN. The system will first validate the individual's UIN, trigger an OTP to individual's registered mobile number and/or email ID, validate the OTP and then authenticate the individual. On successful authentication the VID is generated based on the VID policy of the respective Country. The system will also send a notification message to individual’s mobile number and/or email ID after a successful transaction or appropriate error message if the transaction was not successful.

Maintain the status of a VID

This feature allows the system to maintain the status of all VIDs from the perspective of Time Validity, Transactions, and VID Revocation. The feature will be used by system's authentication module (called IDA - ID Authentication) whenever a VID is used for an authentication transaction (VID status will change to ‘USED’). Also when Resident Services is used for VID Revoke feature the status of VID changes to ‘REVOKED'.

Revoke a VID

To prevent misuse of VID, an individual can request to revoke his/her VID using Resident Service if the individual feels his/her VID has been compromised. The individual provides the VID as input. The system will then validate the individual's VID, trigger an OTP to individual's registered mobile number and/or email ID, validate the OTP and then authenticate the individual. On successful authentication, the system revokes the provided VID. Based on the VID policy of the Country a new VID will be generated during revocation and provided to the individual on the registered mobile number and/or email ID. If validation fails, the system triggers the appropriate error message.

Auto-restore a VID on Revocation and with Auto-restore Policy

This feature allows for a VID to be auto regenerated and given to an individual after he/she requests for an existing VID to be revoked. The VID regeneration happens based on the VID policy defined by Country (the regeneration policy for the revoked VID should be "Auto-restore").

.

List of Configurable Parameters and Processes

All the configurations related to resident services are available

Resident Services API

Process View

Authentication is the process of verifying an identity claim against the registered identity information. Such information could be a personal identification information (PII) such as demographic details, biometric data such as a fingerprint, iris or face and OTP on the registered email or phone number. MOSIP provides APIs using which an individual can perform such authentications after registering in MOSIP.

Authentication can be performed in MOSIP by a registered authentication partner over a secure network provided by MOSIP Infrastructure Service Provider (MISP). You can know more about these MOSIP partners on MOISP's Partner Management.

Authentication Service

MOSIP's authentication service allows a registered MOSIP authentication partner to perform various types of authentications. The types of authentications that can are currently allowed are mentioned below and the API specification for services is available in document.

Biometric Authentication

Using the MOSIP's authentication service a registered authentication partner can request for biometric authentication. Currently, we support biometrics authentication using face, finger and iris. MOSIP adopters can choose to add more biometric types to perform biometric authentication.

MOSIP connects with a biometric SDK, to perform biometric authentication. Refer our page on for various interfaces using which adopters can connect their biometric SDKs with MOSIP.

Demographic Authentication

Using the MOSIP's authentication service a registered authentication partner can request for demographic authentication. Currently, we support demographic authentication for the following id attributes - Name, DOB, Age, Gender, Address and FullAddress.

1. Name - the name received in authentication request is compared with the individual's name saved in the authentication database

2. DOB - the DOB received in authentication request is compared with the individual's date of birth saved in the authentication database

3. Age - the age received in authentication request is compared with the age of the individual which is derived from the date of birth stored in the authentication database

MOSIP supports only exact match for the demographic authentication of the individual and does not perform any validations related to partial match and phonetics match. No error messages related to partial match and phonetics match are triggered.

OTP Based Authentication

Using the MOSIP's authentication service a registered authentication partner can request for OTP authentication. Before performing OTP based authentication the Partner needs to request for an OTP using the individual's ID and use it for OTP based authentication.

For details about the OTP request service go through the .

Multi-factor Authentication

Using various combination of above authentication modalities (fingerprint, face, iris, demographics or OTP based authentication) we can also perform authentication using the same authentication service.

The partner who is requesting for these authentications must make sure that all the below mentioned rules are taken into account before sending an authentication request to MOSIP.

Rules for using MOSIP's Authentication API

1. The authentication request should have a defined set of parameters as mentioned in the .

2. The authentication request should have signature of the request in the header signed by the authentication partner.

3. The biometric data should be sent in as a JWT token where the payload and the signature is signed using the device key. More details of the biometric data block is available in the document.

e-KYC Service

Based on the policy linked to a MOSIP authentication partner, a partner can be eligible to perform e-KYC. In an e-KYC request, the MOSIP authentication partner can request to fetch the KYC details of the individual based on a pre-defined policy. KYC details in MOSIP is only provided to the partners after the individual's consent using OTP or biometric authentication.

The request for e-KYC service is similar to that of authentication service, you can view the details about the API specification in our document.

Internal Authentication Service

Various internal MOSIP modules for need to use the authentication services. The scenarios where authentication of biometrics are needed are,

1. Authenticating an officer or supervisor when they on-board into the registration client.

2. Processing of packets in registration processor where,

   1. The officer or supervisor has performed biometric authentication.

The internal authentication service supports authentication for all the modalities mentioned as part of authentication service but is only accessible bby the internal modules post authorization. The details about the internal authentication API specification is available in our document.

Common Features in Authentication

Validations in MOSIP's Authentication API

Below are the various validations that are performed in the authentication server when MOSIP's authentication service receives an authentication or e-KYC request from a Partner.

1. Verify if the Partner ID, MISP ID and Partner API Key is valid

2. Verify if the signature of the request is valid

3. Verify if the request has reached the authentication server with in the time period configured

Generation of Authentication Token

After every authentication performed in MOSIP, an authentication token is generated in MOSIP. This token is generated based on policy defined for the partner. The token is basically a random id which can be unique per authentication transaction, unique per partner and individual or unique per partner policy group and individual.

Trigger of Notification

After every authentication a notification is trigger to the registered email id or phone number of the individual based on the configuration defined for mode of communication. The notification to be sent to the individual can also be single or bi-lingual based on the configurations and template used.

Overview

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 profile 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 set up 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.

Design

• 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 during the ID issuance stage.

• As a part of this implementation, a new

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.

Anonymous Identity issuance profile

• 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

Introduction

MOSIP and Partners communicate with each other when indviduals avail services of Partners. The communication must to be executed safely and securely.

• Confidential: The communication should be confidential and no other parties should be able to eaves drop the communicated details.

• Integrity: The integrity of the communication should be maintained.

Security at various levels

Network Layer

• All communication from Partners to MOSIP is routed via the MISP.

• The communication is protected via the secured network protocol suite of IPSec.

Presentation Layer

Process flow for communication at Presentation Layer:

1. Partner pings MOSIP.

2. Partner gets the MOSIP certificate which is signed by the Root CA.

3. Partner then verifies the MOSIP certificate with the Root CA.

Application Layer - Encryption

1. The data is encrypted in the Application Layer itself before it gets into the Presentation Layer.

2. The Encryption certificate is shared across by both the parties (MOSIP & Partners) to decrypt the content.

Application Layer - Digital signature

1. Both the parties (MOSIP and Partner) have to sign the request and response in the communication.

2. Partner signs request and response using Partner's signature certificate. MOSIP can verify the signature using Partner's public key.

3. MOSIP signs request and response using MOSIP signature certificate. Partner can verify signature using MOSIP's public key.

Certificates used

Altogether, 3 certificates are used in the communication:

1. SSL certificate: Used in the Presentation Layer

2. Encryption certificate: Used in the Application Layer

3. Signature certificate: Used in the Application Layer

Overview

The MOSIP platform is configured via the Admin application. This application can be accessed only by the privileged group of administration personnel. When the MOSIP platform gets initialized, there are default configurations and seed data are setup. Post installation, following operations can be done using the Admin application:

• Master data management

• User management

• Mapping of the master data to various resources

The module provides a single user interface to administer the MOSIP platform. On initial platform installation, data and configurations may be uploaded from CSV files.

Admin application contains UI layer and Service layer. All the components in both Services and UI are secure and authenticated. Every component should be defined with the authorization module plugged in. For example, if a component's data is not supposed to be viewed except authorized personnel, no user will be able to view it. So is for creating, editing and deleting functionalities.

Detailed functionality

Logical view

Backend Services

The administrator uses many services available as part of Kernel in . There are a few administrator specific services available in . The code and design documentation is available in the repositories.

Frontend - Admin portal

Reference implementation of Admin portal is available in

Build and Deploy

Build and deploy instructions available in the above repositories.

APIs

APIs from multiple services are used for Admin as follows:

Purpose

The recommended Github work flow here is for developers to submit code and documentation contributions to MOSIP open source repositories.

Setup

1. Fork MOSIP repository of interest from https://github.com/mosip/

2. Clone the fork to your local machine. Eg:

3. Set upstream project as the original from where you forked. Eg:

Code changes

1. Create a new issue in .

2. You may work on master, switch to a branch (like Release branch) or create a new branch.

3. Make sure you are up-to-date with upstream repo.

Overview

Providing unique identity for a resident is one of key features of any identity platform. To achieve this, MOSIP interfaces with an Automated Biometric Identification System (ABIS) to perform de-duplication of a resident's biometric data.

MOSIP is designed to integrate with multiple ABISs to leverage expertise of different ABIS providers. A country may use one ABIS for fingerprint and another for Iris or use multiple ABISs for the same biometric data and evaluate the best ABIS based on de-duplication quality.

The ABIS system never comes to know about resident's identity. Any Personally Identifiable Information (PII) such as demographic details or RID (Request ID for Registration) is not shared with the ABIS system. Internally, MOSIP maintains a mapping between the ABIS specific referenceID and RID of the resident.

ABIS middle-ware

MOSIP's ABIS middle-ware has the following components

• MOSIP ABIS request handler

• Request router (based on routing policy, an ABIS request is routed to the correct ABIS system)

• ABIS response handler

Below is the MOSIP ABIS middle-ware process flow,

MOSIP-ABIS interface

MOSIP interacts with ABIS only via message queues. JSON format is used for all control messages in the queue. MOSIP ABIS middle-ware sends requests to inbound queue address and receives responses from outbound queue address. For details refer to the .

ABIS must support the following types of biometric images:

• Individual fingerprint images (segmented)

• Iris images (left, right)

• Face image

Biometrics data in MOSIP is exchanged as per formats defined in .

ABIS deployment

• ABIS must comply to .

• The queues can be configured in file.

• ABIS system connects to the queues using a pre-defined user id and password.

Introduction

MOSIP uses biometrics - fingerprint, iris, face - in registration and authentication processes. This requires specialized processing of biometrics data for biometric quality check and matching two biometric images. Biometric SDK consists of software libaries that provide these functions. Note that MOSIP platform does not include such an SDK.

Biometric SDK Functions

SDK Initialization

Shares information about the SDK and performs any one time activities including initialization of internal variables and algorithms.

Quality Checker

Checks the quality of input biometrics and returns quality score for the same.

Use Cases

• When a biometric image is received by MOSIP in the registration client using a forced capture, this method is used to check the quality of the image

• Server side validation of quality of biometric images uses this method

• When external biometric images are received to be put on record this method is used to determine the quality of the received biometric image

Matcher

Matches the captured biometric record or a list of biometric records (based on single match or composite match), matches it against list of stored biometric records. It then returns a matching score against each stored biometric record or a composite matching score for the list of input biometric records.

Use Cases

• Used for matching one or multiple modes of biometric received in an auth transaction with a list of biometrics record

• Used for authentication of operators in offline mode

• Used for prevention of erroneous submission of operator biometrics in place of registrant’s biometric on registration client

Extractor

Extracts salient features and patterns of input biometric record to use in fast comparison. It returns the extracted biometric record.

Use Cases

• Used to extract salient features and patterns of a biometric to use in fast comparison

• In case of fingerprints this is called Minutiae and a standard representation of minutiae is an ISO template for FMR

Segmenter

Segments single biometric record into multiple biometric records and returns list of segmented biometric records. Eg: Split thumb slab into multiple fingers and eyes into left and right eye.

Use Cases

• Used to split images into individual biometric segments when received from external sources

Converter

Converts images in all segments in the biometric record.

Biometric SDK integration points

Biometric SDK API Specification

The SDK needs to comply to

Biometric Specification

For details about biometric specifications in MOSIP please view the page .

Configurations in Pre-Registration Properties files

File Name:

Introduction

Running a national ID system is no mean task and involves numerous challenging aspects. The software system at the core is a critical infrastructure and needs to address high availability, reliability, scalability, security, resilience, and manageability. Choosing the right deployment architecture plays an important role in helping achieving architectural goals while also catering to the law of the land. Cost of implementing such an architecture also matters.

Mosip has a micro-services architecture that organizes functionality into myriad small services and execution units. Each of these can be scaled separately as well as replaced / upgraded. This makes the platform powerful and provides plenty of flexibility and configurability in the hands of the implementor. There is also the corresponding complexity of dealing with a higher number of components in the system in the areas of configuration, security, deployment, dependency management, monitoring and testing.

Our Pledge

In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to making participation in our project and our community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, sex characteristics, gender identity and expression, level of experience, education, socio-economic status, nationality, personal appearance, race, religion, or sexual identity and orientation.

UIN Generation

MOSIP generates a pool of UINs before the registration process and stores them. The UIN generation policies can be defined or modified by country as per their requirement.

The UINs generated for the current implementation, follow the following policies:

HSM stands for Hardware Security Module and is an incredibly secure physical device specifically designed and used for crypto processing and strong authentication. It can encrypt, decrypt, create, store and manage digital keys, and be used for signing and authentication. The purpose is to safeguard and protect keys.

MOSIP highly recommends the following specifications for HSM:

1. Must support cryptographic offloading and acceleration.

2. Should provide Authenticated multi-role access control.

3. Must have strong separation of administration and operator roles.

4. Capability to support client authentication.

5. Must have secure key wrapping, backup, replication and recovery.

6. Must support 2048, 4096 bit RSA Private Keys, 256 bit AES keys on FIPS 140-2 Level 3 Certified Memory of Cryptographic Module.

7. Must support at least 10000+ 2048 RSA Private Keys on FIPS 140-2 Level 3 Certified Memory of Cryptographic Module.

8. Must support clustering and load balancing.

9. Should support cryptographic separation of application keys using logical Partitions.

10. Must support M of N multi-factor authentication.

11. PKCS#11, OpenSSL, Java (JCE), Microsoft CAPI and CNG.

12. Minimum Dual Gigabit Ethernet ports (to service two network segments) and 10G Fibre port should be available.

13. Asymmetric public key algorithms: RSA, DiffieHellman, DSA, KCDSA, ECDSA, ECDH, ECIES.

14. Symmetric algorithms: AES, ARIA, CAST, HMAC, SEED, Triple DES, DUKPT, BIP32.

15. Hash/message digest: SHA-1, SHA-2 (224, 256, 384, 512 bit).

16. Full Suite B implementation with fully licensed ECC including Brainpool, custom curves and safe curves.

17. Safety and environmental compliance

18. Compliance to UL, CE, FCC part 15 class B.

19. Compliance to RoHS2, WEEE.

20. Management and monitoring

21. Support Remote Administration —including adding applications, updating firmware, and checking the status— from NoC.

22. Syslog diagnostics support.

23. Command line interface (CLI)/graphical user interface (GUI).

24. Support SNMP monitoring agent.

25. Physical characteristics

26. Standard 1U 19in. rack mount with integrated PIN ENTRY Device.

27. Performance

28. RSA 2048 Signing performance – 10000 per second.

29. RSA 2048 Key generation performance – 10+ per second.

30. RSA 2048 encryption/decryption performance - 20000+.

31. RSA 4096 Signing performance - 5000 per second.

32. RSA 4096 Key generation performance - 2+ per second.

33. RSA 4096 encryption/decryption performance - 20000+.

34. Should have the ability to backup keys, replicate keys, store keys in offline locker facilities for DR. The total capacity is inline with the total number of keys prescribed.

35. Clustering minimum of 20 HSMs.

36. Less than 30 seconds for key replication across the cluster.

37. A minimum of 30 logical partitions and their license should be included in the cost.

Common Functionality

Self Registration

Partners in MOSIP are created in a self-service mode. The partner visit the MOSIP partner management portal and requests for collaborating with MOSIP by providing basic details such as organization name & email id, purpose of registration (how they want to collaborate with MOSIP - as a device provider, authentication partner, print partner, etc), basic credentials and performing an OTP based verification.

Once these details are filled by the partner and a request is sent to MOSIP, the Partner Admin verifies the details of the partners and allows the partner to integrate with MOSIP.

User Management

Once the partner is registered in MOSIP and is able to login to the partner management portal, MOSIP provides basic features such as,

1. Adding more contact information

2. Viewing user details

3. Managing credentials

Device Provider

The device providers is one who partners with MOSIP to provide MOSIP complaint devices for authentication and registration.

Upload & Download of Device Certificate

A device provider needs to upload his/her certificate using which he/she would be generating their device keys. These certificates are verified by MOSIP. Once the verification is done the root for these certificates are changed to MOSIP and can be downloaded back by the partner.

A device provider needs to upload a single certificate for all his/her devices.

This certificate needs to be upto date in MOSIP system before anyone performs any authentication using the device. During authentication, MOSIP would verify the device certificate using which the device info in authentication request is signed.

Manage Device Make and Model

Using the partner management portal a device provider can add, update or view their device model details. Once the device provider registers the model details a request is sent to the partner admin for approval of the model.

During device registration MOSIP verifies the make and model detials. If a model details for a device is not available or approved by the partner admin, then registration for that device would fail.

Manage Secure Biometric Interface

Using the partner management portal a device provider can add, update or view their device model details. Once the device provider registers the SBI details a request is sent to the partner admin for approval of the SBI.

Foundational Trust Provider

The foundational trust providers is one who partners with MOSIP to provide MOSIP complaint foundational trust modules (chips) for authentication devices.

Manage Chip Make and Model

Using the partner management portal a foundational trust provider can add, update or view their chip model details. Once the partner registers the model details a request is sent to the partner admin for approval of the model. As part of registration of the chip model, the partner needs to upload an associated certificate which would be used to generate keys for the particular type of chip.

The chip key will be used to sign the digital id in the authentication request. So, when the auth request reaches MOSIP, MOSIP would verify the certificate using which the digital id is signed.

Authentication Partner

The authentication partner is one who partners with MOSIP to provide authentication services to individuals.

Upload & Download of Signature & Encryption Certificates

An authentication partner need to upload an encryption & a signatire certificates using the partner management poratl. The signature certificate will be used in MOSIP to verify the signature when any request is received from the partner; where as, the encryption certificate would be used when any PII data is sent to the partner during e-KYC.

Manage API Keys

The authentication partner can view associated API keys and request for an API key for against a policy which is available for his/her policy group. Once a requeste is initiated a request is generated but a request is also sent for approval to the partner admin. The partner admin needs to approve the request before it can be used in MOSIP. This API key is one of the manadatory attributes in the authentication request using which MOSIP verifies the partner and policy mapping.

Credential Partners

Upload & Download of Signature & Encryption Certificates

An credential partner need to upload an encryption & a signatire certificates using the partner management poratl. The signature certificate will be used in MOSIP to verify the signature when any request is received from the partner; where as, the encryption certificate would be used when any PII data is sent to the partner based on policy to issue a credential.

Manage API Keys

The authentication partner can view associated API keys and request for an API key for against a policy which is available for his/her policy group. Once a requeste is initiated a request is generated but a request is also sent for approval to the partner admin. The partner admin needs to approve the request before it can be used in MOSIP. This API key is one of the manadatory attributes in the authentication request using which MOSIP verifies the partner and policy mapping.

MISP (MOSIP Infrastructure Provider)

View Transaction Logs

A MISP would be providing services to multiple authentication partners. The audit trails on which partner & when used MISP's licence key to perform authentication would be avaialable for the MISP to monitor.

Partner Admin

Approvals

The partner admin receives approval requests for various scenarios. The list of scenarios are mentioned below:

1. When a partner registers in MOSIP.

2. When a device model is registered by a device provider.

3. When a secure biometric interface is registered by a device provider.