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 MOSIP Documentation and the design folders of the various repositories.

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

• Interoperability and Standards

• Transparency and Audit-ability The above allows systems to enact digital transactions which are essentially a flow of all forms of data or money. These transactions will need to factor in identity assurance, consent, user privacy, and information security. MOSIP offers identity assurance to such transactions.

Building a National ID System using MOSIP

National ID systems can leverage MOSIP as the base platform and configure, customize, and extend it to build their systems just the way they need it. The picture below depicts how mosip is visualized as a national id platform.

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

• Provide a scalable and accessible solution to cater to a wide range of population (a few thousand to several hundreds of millions)

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

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

To view the summary of our releases, click here.

MOSIP Resources

Source Code: GitHub Repositories Containers: Docker Repository Maven Repository: Nexus Repository Presentations: mosip.io Learning Videos: YouTube Channel Community: Gitter Channel

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 roadmap and call for contribution to see how you can be part of the MOSIP journey.

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.

4. public List pdfToImages(byte[] pdfBytes) - to convert the pdf document to image format in order to show in the document preview.

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.

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

D Demographic Auth

E

F

G

H

I Identity Verification

J

K

L

M

N

O

P

Q

R

S

T

U

V

W

X

Y

Z

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 assists the individual during registration.

  • The Supervisor verifies and attests exceptional cases in registration.

  • The Adjudicator carries out manual verification or comparison of an individual's data in the ID issue process.

  • The Auditor performs an audit or forensic analysis of specific enrollments.

  • The Administrator is a super user who manages the configuration data of the system.

• The Partner represents a 3rd party service or application that interacts with MOSIP. There are specialized partners in the ecosystem.

  • The Relying Party is an Authentication Partner who relies on the ID system for their business transaction. This could be a social scheme for benefits disbursement or a bank for opening accounts.

  • The Credential Provider is a print service provider for the credential issue.

  • The Device Provider is a partner who provides biometric devices.

  • The FTM Provider is a partner that provides foundational trust modules for devices.

  • The Partner Application is a system that relies on mosip or one that mosip relies on. This could be a CRVS system or a Functional ID system such as a Passport or a driver's License.

  • The ID System is a system that mosip integrates with for inter-operable ID

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

• ID Repository

• Authentication

• Resident Services

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

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.

Detailed functionality

Process flow

Logical view

Services

For detailed description of Resident Services, code and design refer to .

Build and deploy

Refer to build and deploy instructions in .

APIs

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:

• Authorization of API's accessed via web channel

• Authorization to access specific data

A country will have its own hierarchy of system users especially the Registration staff and system administration staff. So, instead of defining a fixed hierarchy, by default MOSIP will depend on an LDAP implementation to manage users, organizational hierarchy and roles for users in the hierarchy. MOSIP will use an open source LDAP server as the LDAP implementation. Administrators can create hierarchy and users using Apache Directory Studio.

MOSIP system can handle Authorization across core services and restricts access to Web-services as per the roles defined.

For details on the APIs for authentication and authorization please view our documentation on .

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.

Components

Refer to commons repo/kernel for all components of Kernel.

Detailed functionality

Kernel has many services and functions. Details of some of them are mentioned below:

• Common Services

• UIN & VID Generation Service

• Data Services

• Master Data Services

• Key Manager

• Audit Manager

• Authentication and Authorization

• Packet Manager

• Web Sub

Services and libraries

Details of all services and libraries along with code, design are available in commons repo/kernel.

Build and deploy

Refer to build and deploy instructions in commons repo/kernel.

APIs

Kernel APIs

Pre-requisite

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

Reporting Issues

1. Check if the issue is already reported.

2. Check if the issue is already fixed.

3. If not, just go and file the issue

4. Template for filing new issues

Describe the issue A clear and concise description of what the bug is.

To Reproduce Steps to reproduce the behavior:

Expected behavior A clear and concise description of what you expected to happen.

Actual behavior A clear and concise description of what you see.

Screenshots If applicable, add screenshots to help explain your problem.

Environment (please complete the following information): Hardware and software details such as client OS, Server OS, Browser details etc

Attach logs Helps in faster resolution of data

Additional context Add any other context about the problem here.

Features/Enhancement request guidelines

1. Check if the feature is already reported.

2. Check if the feature is already fixed.

3. If not, just go and file the feature request

4. Template for filing new feature request

What is the current limitation without the feature

Describe the feature request

What would the key benefits of this feature

Do you have any recommendations and solutions that are existing in the field

Any technology/solution recommendation would be highly appreciated

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:

   Copy

   $ git clone https://github.com/<your_github_id>/commons.git

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

   Copy

   $ cd commons
   $ git remote add upstream https://github.com/mosip/commons.git

4. Make sure you never directly push to upstream.

   Copy

   $ git remote set-url --push upstream no_push

5. Confirm the origin and upstream.

   Copy

   $ git remote -v

Code changes

1. Create a new issue in MOSIP Jira.

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.

   Copy

   $ git pull upstream <branch> 

4. Once you are done with the work, commit your changes referring to Jira number in the commit message. Eg:

   Copy

   $ git commit -m "[MOS-2346] Adding new upload feature in Pre registration module for POA documents"

5. Once again ensure that you are up-to-date with upstream repo as it may have moved forward.

   Copy

   $ git pull upstream <branch> 

6. Build and test your code. Make sure it follows the coding guidelines.

7. Push to your forked repo (origin).

   Copy

   $ git push 

8. Create a pull-request on your forked repo. Direct the pull-request to master or any specific branch on upstream (like a Release branch).

9. Make sure the automatic tests on Github for your pull-request pass.

10. The pull-request shall be reviewed by reviewers.

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:

1. UIN should not contain any alphanumeric characters

2. UIN should not contain any repeating numbers for 2 or more than 2 digits

3. UIN should not contain any sequential number for 3 or more than 3 digits

4. UIN should not be generated sequentially

5. UIN should not have repeated block of numbers for 2 or more than 2 digits

6. The last digit in the number should be reserved for a checksum

7. The number should not contain '0' or '1' as the first digit.

8. First 5 digits should be different from the last 5 digits (example - 4345643456)

9. First 5 digits should be different to the last 5 digits reversed (example - 4345665434)

10. UIN should not be a cyclic figure (example - 4567890123, 6543210987)

11. UIN should be different from the repetition of the first two digits 5 times (example - 3434343434)

12. UIN should not contain three even adjacent digits (example - 3948613752)

13. UIN should not contain admin defined restricted number

Note: The number of UINs to be generated in a pool depends on a configuration to be done by the country depending on the peak registration requirements. UIN generation service will receive a request by Registration Processor to get a UIN. The service responds with an un-allocated UIN from the generated pool. When the pool reaches a configured number of minimum UINs, MOSIP generates another pool of UIN.

VID Generation

MOSIP will generate a pool of VIDs through a Batch Job. The number of VIDs generated will be configurable by the country. All the VIDs generated will be assigned a status “Available” which means that the VID is available for allocation to a UIN. Any request for VID allocation will pick up VIDs which have this status. The Batch Job to generate the pool will run every time the number of VIDs in the pool reduces to a configured number.

VID generation will happen according to the below logic:

1. VID generated should contain the number of digits as configured.

2. A generated VID should follow the below logic a. The number should not contain any alphanumeric characters b. The number should not contain any repeating numbers for 2 or more than 2 digits c. The number should not contain any sequential number for 3 or more than 3 digits d. The numbers should not be generated sequentially e. The number should not have repeated block of numbers for 2 or more than 2 digits f. The number should not contain the restricted numbers defined by the ADMIN g. The last digit in the number should be reserved for a checksum h. The number should not contain '0' or '1' as the first digit.

MOSIP has a VID generator service which will receive a call to generate a VID. The service will also support receiving an expiry period (optional Parameter). This service when called will pick up a VID from the pre-generated pool and respond it to the source. The Service will also mark that VID in the pool as “Assigned” and attach the expiry period to the VID if received. The service will also make an asynchronous call to the batch job to check the remaining VIDs and generate the pool if needed.

MOSIP also has a VID revoke service which will receive a VID and expire it. When received a request along with the VID, the service will change the status of the VID as “Expired”.

MOSIP also has a batch Job to auto-expire VIDs and mark expired VIDs as to be available to be allocated again.

1. All the VIDs will be marked as ‘Expired’ through the batch job based on the expiry period assigned to them

2. All the VIDs which are in expired state for a configured amount of days should be marked as ‘Available’ through a daily batch job thus enabling re-usability of them

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.

4. Once validated, the Partner shares its SSL certificate to the MOSIP. This SSL certificate is already signed by MOSIP as Root CA.

5. MOSIP verifies the SSL certificate.

6. Once both the SSL certificates are validated, the communication channel is established and communication happens.

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

This module enables a resident to:

• Enter demographic data & upload supporting documents

• Book an appointment for one or many users for registration by choosing a suitable registration center and time slot

• Receive appointment notifications

• Reschedule and cancel appointments

Resident data is sent to the designated registration center before appointment that can be used during the registration process.

Detailed functionality

For detailed functionality of Pre-registration features please view our page, Pre-registration Functionality.

Process flow

Process flow diagram for create and update flows in Pre-registration.

Process flow diagram for cancel and discard flows in Pre-registration.

Services

For detailed description of Pre-registration services refer to pre-registration repo.

Logical View

Below is the diagram depicts the logical architecture of Pre-registration,

Build and deploy

Refer to the build and deploy instructions in the pre-registration repo.

APIs

For detailed functionality of Pre-registration APIs please view our page, Pre-registration APIs

UI Reference Implementation

MOSIP provides a reference implementation of the Pre-registration UI that may be customized as per country needs. The implementation is is available on ref impl repo.

Please find below the sequence diagrams for auth flows.

Login flow:

Resource request flow:

Service to Service communication:

Documentations for the Auth Implementations

1. Auth Adapter Documentation

2. Auth Angular User Guide

3. Auth SpringBoot User Guide

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.

This document presents cell architecture for all major MOSIP modules for production deployment.

Registration Processor Cell

The following resources are shared across cells:

• ABIS

• ABIS Queue

• Registration Process DB

• ID Repository HDFS/CEPH cluster

• ID Repository DB

The communication between Demilitrized Zone (DMZ) and Militarized Zone (MZ) is strictly via a firewall.

The encrypted packets from registration client first land into Packet Landing Zone in the DMZ. Some of the Registration Processor stages run in the DMZ for initial packet handling.

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.

• A User say 'X' has to be created in KeyCloak and the role “Default” needs to be mapped to it.

2. Creating the Relevant Master Data

• All data required as part of ID Object, for example, Gender, Location hierarchy, templates, etc. should be setup in the database through the CSV Utility

• Master data of user, machine, device and center should be created and uploaded through the CSV Utility (Note - the user id for the User 'X' should be present in Master data of User)

• All necessary center-machine-device-user mappings should be completed through the CSV Utility for the first user.

3. Creating the First User in MOSIP

• The User 'X' should now download the latest Registration Client and login with the credentials set in KeyCloak.

• The User will automatically skip Operator/Supervisor On-boarding and will reach the home page of Registration Client.

• The User authentication method for User 'X' will be always User ID and Password as it is the default user.

• The User now can register himself/herself in MOSIP and will get an RID and UIN.

4. Allocating the RID to the User Created in KeyCloak

• The RID created for the User 'X' needs to be updated in KeyCloak.

5. User On-boarding

• The role for the User 'X' needs to be changed to Registration_Officer or Registration_Supervisor.

• The role "Default" needs to be removed from KeyCloak so that no other user has the role Default.

• The User 'X' can now login to Registration Client (from the mapped Machine/Centre) with the above Username/Password.

• The User now would need to On-board as his/her role would be changed.

• Once on-boarding is completed User 'X' can register the subsequent Officers and Supervisors.

• The User details of the subsequent Officers and Supervisor must be created in KeyCloak with appropriate roles assigned (as per Step 1) and their RIDs should be mapped in KeyCloak (as per Step 4) so that they can login to Registration Client.

Flow chart describing first user onboarding

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

Admin Services Functionality

Logical view

Backend Services

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

Frontend - Admin portal

Reference implementation of Admin portal is available in ref impl repo

Build and Deploy

Build and deploy instructions available in the above repositories.

APIs

APIs from multiple services are used for Admin as follows:

• Admin APIs

• Document APIs

• Register Center APIs

• Device APIs

• Machine APIs

• Common APIs

• Zone APIs

• Device Management APIs

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

• Match is expected to be capable of image-image, extract-extract and extract-image comparisons

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 .

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.

• It is recommended that ABIS is deployed in a secure zone (military zone).

• ABIS system is not recommended to connect to any external network.

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.

Deployment architecture choices

In order to get the best out of mosip and keep manageability high the deployment architecture plays a crucial role. Let us take a look at a few of the common deployment architecture options available based on various perspectives.

• Packaging choices

  • Option 'Jar' - Spring boot services in Virtual Machines|

  • Option 'Docker' - Dockers on a Kubernetes container management setup

• Infrastructure choices

  • Option 'On-Premise' - Deploy in a private or own data center

  • Option 'Cloud' - Deploy in a cloud

  • Option 'Hybrid' - Cloud + On Premises

• Platform choices

  • Option 'Open Source' - Proven community favored platforms

  • Option 'Cloud Native' - Cutting edge supported cloud technologies from AWS, Azure, GCP et al

  • Option 'Commercial' - Established and well supported priced packages

Security: Deployment with secure zones

The architecture proposed may be deployed on-premise or cloud. Here, all MOSIP modules are installed with clear separation between militarised and demilitarised zones.

Scalability: Cell based architecture

For linear scaling of capacity and provisioning of hardware, a cell based architecture (along with secure zones) may be preferred.

Rapid deployment: Hybrid architecture

A hybrid architecture may be considered where benefits of cloud and on-premise are leveraged. While cloud provides rapid deployment and ease of management, on-premise can facilitate data localization and any other policy requirements.

An example of hybrid architecture is given below:

This document lists out the instructions on how to use the in a Spring Boot application.

• Step 1:

• Step 2:

• Step 3:

Inject required libraries

• Add the Auth Adapter module to your project as a maven dependency

• Add ComponentScan annotation as shown below to your project. This is to create auth adapter bean.

Attach annotations to authorize endpoints

To restrict access to your endpoints, you need to add the @PreAuthorize annotation. Look at the below example for reference.

There are few more methods available apart from hasAnyRole like hasRole. Look in to the documentation for more details.

Note: Now we support only hasRole and hasAnyRole methods.

Use restTemplate for Http calls

To make any kind of HTTP or HTTPS calls to a mosip's micro service that also injected the Auth Adapter, use the standard RestTemplate capabilities as shown below.

• Intially autowire the RestTemplate in the class where you are going to make an API call.

• Now make the call using the autowired restTemplate as shown in the sample below:

Note: Do not create a new instance of the RestTemplate instead use the autowired one.

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.

Our Standards

Examples of behaviour that contributes to creating a positive environment include:

• Using welcoming and inclusive language

• Being respectful of differing viewpoints and experiences

• Gracefully accepting constructive criticism

• Focusing on what is best for the community

• Showing empathy towards other community members

Examples of unacceptable behaviour by participants include:

• The use of sexualised language or imagery and unwelcome sexual attention or advances

• Trolling, insulting/derogatory comments, and personal or political attacks

• Public or private harassment

• Publishing others' private information, such as a physical or electronic address, without explicit permission

• Other conduct which could reasonably be considered inappropriate in a professional setting

Our Responsibilities

Project maintainers are responsible for clarifying the standards of acceptable behaviour and are expected to take appropriate and fair corrective action in response to any instances of unacceptable behaviour.

Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, or to ban temporarily or permanently any contributor for other behaviours that they deem inappropriate, threatening, offensive, or harmful.

Scope

This Code of Conduct applies both within project spaces and in public spaces when an individual is representing the project or its community. Examples of representing a project or community include using an official project e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event. Representation of a project may be further defined and clarified by project maintainers.

Enforcement

Instances of abusive, harassing, or otherwise unacceptable behaviour may be reported by contacting the project team at [email protected]. All complaints will be reviewed and investigated and will result in a response that is deemed necessary and appropriate to the circumstances. The project team is obligated to maintain confidentiality with regard to the reporter of an incident. Further details of specific enforcement policies may be posted separately.

Project maintainers who do not follow or enforce the Code of Conduct in good faith may face temporary or permanent repercussions as determined by other members of the project's leadership.

Attribution

This Code of Conduct is adapted from the , version 1.4, available at https://www.contributor-covenant.org/version/1/4/code-of-conduct.html

For answers to common questions about this code of conduct, see https://www.contributor-covenant.org/faq

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.

4. When a chip model is registered by a foundational trust provider.

5. When an authentication partner requests for an API key.

6. When a credential partner requests for an API key.

Activation or Deactivation

The partner can choose to activate or deactivate various entities in the partner management portal.

1. Activation or deactivation of partner.

2. Activation or deactivation of device model.

3. Activation or deactivation of chip model.

4. Activation or deactivation of SBI.

5. Activition or deactivation of API Keys.

Hotlisting of Devices

The partner admin can choose to hotlist a device by marking a device as hotlisted.

Create or Update Partners

The partner admin can create a new partner or update details of a partner in the Partner Management portal.

Associate & Re-Issue API Keys

The partner admin can associate new API keys to an authentication or crential partner and re-issue their API keys.

Policy Admin

Create Policy Group

In order to create a policy we must have a policy group first. The policy admin needs to first create a policy group using the partner management portal.

Create and Publish Policies

Once the policy group is created the policy admin can create policies and associate these policies to various policy groups. After these policies are created, they would be in draft state. These policies need to be published by the policy admin. Once published these policies can be used by the partners.

Activate or Deactivate a Policy

The policy can be activated or de-activated anytime by the policy admin.

Update a Policy

A policy can be updated multiple times when it is in draft state. Only the validity date can be updated once the policy is published.

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.

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

    • Non-Sensitive

  • The Sensitive data is encrypted in the DTO layer.

  • AES-256 algorithm is used for the encryption.

  • The data are classified and kept in the configuration file. The application layer reads this configuration and the sensitivity property is injected into the DTO layer.

  • Hibernate interceptors are used to intercept the fields in the DTO layer.

  • During the reading of these fields, once again Hibernate interceptors are called to decrypt the data.

    • The key expiration is in-built into the key store.

• Following are the various components in the system,

  • Keys are stored in the "Key Store". This is a database table in which the keys are maintained along with the index.

  • Indexes are persisted in a separate store. When a request comes to a system to encrypt, the current index is retrieved and using this index, the key for encryption is taken. Indexes are stored along with the encrypted data as the prefix separated by a colon. For example, 4:sdf*)(8S@#YFLSJ&*hfdlkj23h

  • The scheduler runs a job at some specific time when the necessity for re-encryption arises.

  • HSM devices are used to store the Master keys. These master keys are used to encrypt the keys in the Key store.

• Encryption:

  • The properties in the entities which are supposed to be encrypted are configured in the config server.

  • During the encryption, a listener is installed in the DAO layer to intercept the incoming entity objects. If those properties are supposed to be, encrypted or not, are received from the config server.

  • The data is encrypted and prefixed with the index of the key, which is used for the encryption and stored in the data store.

  • The key itself is encrypted with the master key from HSM and stored in a separate data store.

  • The index is incremented if the old index is expired.

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.

  • During the decryption, the index is calculated by the delimiter. This index is used to find the Key, which was used for the encryption.

  • The Key itself has to be decrypted by the master key from HSM, before decrypting the content.

Decryption

• Key rotation

  • On-Demand:

    • The keys are stored with the expiry date.

    • When a request comes to the system, the key is checked for expiry.

    • If the old key had expired, then a new index is generated and persisted in the Indexes. If there is no key exists in the Key store, a new key is created for the encryption. And the new key is used for further encryptions.

  • Bulk:

    • There are times, that the total encrypted data are re-encrypted again. A scheduler is maintained to oversee this. During the scheduled time, the encrypted data is read and re-encrypted once again and saved. The newly encrypted data will have the new index in front of the encrypted content separated by a delimiter.

    • Bulk mode is used to remove the expired keys and data is encrypted with the new key.

• TODO: How do we handle failures during the bulk re-encryption?

• TODO: How to handle the load, if it is extremely high?

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

• ID Authentication requests must come to MOSIP only via trusted parties who are white listed in MOSIP. The trusted parties are referred to as partners in MOSIP.

• The biometric devices used for authentication must be registered with MOSIP.

ID Auth allows only partners to make authentication requests. The requests are cryptographically secured and verified. A partner that captures data from a biometric device must conform to standards to ensure interoperability.

An individual is authenticated based on the following:

• Demographic data

  • name

  • date of birth

  • gender

  • address

• Biometrics

  • fingerprint

  • iris

  • face

To enhance security a second factor of authentication is supported:

• OTP based

• Static pin based

• Challenge response

To analyze and generate authentication patterns, all authentication requests are audited. These audit logs may be used to determine any frauds during authentication process.

Detailed functionality

ID Authentication Functionality

Process flow

Demographic authentication

Biometric authentication

Multifactor authentication

OTP authentication

Partner and MISP authentication

eKYC authentication

Logical View

Services

For detailed description of ID Auth services, code and design refer to ID authentication repo.

Build and deploy

Refer to build and deploy instructions in ID authentication repo.

APIs

ID Authentication APIs

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

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

Detailed functionality

Registration Processor Functionality

Process flow

Packet Pre-Processing

New Packet Processing

Update Packet Processsing

Lost UIN Packet Processing

Activate/De-Activate Packet Processing

Logical View

Services

For detailed description of Registration Processor Services refer to registration processor repo.

For high level and low level design refer to registration processor repo

Build and deploy

Refer to build and deploy instructions in registration processor repo.

APIs

Registration Processor APIs

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

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

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 registration client repo. The App may be modified according to a country's need.

Registation client setup guide

First user on-boarding

TBD

Where to start?

• Refer to 'What is a foundational ID system' for a comprehensive overview of foundational ID systems and MOSIP.

• Get to know the Technology Stack

• Get to know the MOSIP github repo structure

• If you do not have a GitHub account, create one here.

• Deploy and try MOSIP using the MOSIP deployer for developers.

• The code of conduct has some basic ethics that must while operating within the MOSIP community. Make sure you read it completely. If you have any queries/suggestions, direct them to [email protected].

• If you are a developer willing to contribute to MOSIP, take a look at MOSIP Java coding standards.

Congratulations! You've successfully bootstrapped yourself into the world of MOSIP. Welcome aboard!

Areas of contribution?

Curious about where you can contribute? There are plenty of ways to get involved with MOSIP :

Requirements and Design

• Share new requirements and ideas

• Review and provide feedback on design and architecture

Coding

• Fix issues and enhance features

• Review code contributions

• Triage and resolve bugs

Testing

• Run tests on unstable builds

• Create and add new tests

• Fix test scripts and generate test data

Documentation

• Correct and improve documentation

• Test documentation and report any issues

• Fix documentation issues

• Localize documents (French, Arabic, and Spanish are currently in high demand!)

Ready to fix an issue?

Fantastic! Submit a pull request by following our code submission guidelines.

Found an Issue or Have an Enhancement Request?

Fantastic! We'd love to hear your feedback. If you've discovered an issue or have an idea for an enhancement, please submit it to our issues repository. Be sure to follow the issue reporting guidelines to help us address it efficiently. Your contributions are invaluable in helping us improve!

Running and enhancing tests

For the quality gurus and the testing geeks! Join the MOSIP testers group where you get to contribute towards improving the quality of MOSIP releases making it stable and better adoptable. Lots of material about the MOSIP functional test rig such as building and running the test rig, documentation to modify code, test scripts, and test data generation have been made available.

Getting in touch

We're here to assist you every step of the way!

• Join the Developer Mailing List: Stay up-to-date with the latest announcements, discussions, and support from the MOSIP developer community.

• Join Our Community Room via : Connect with fellow community members, ask questions, and get support from experienced developers. It's a great place to collaborate and learn from others!

Courtesy : Sasikumar Ganesan

Background

A virtual ID can be requested by an Indivudual against his UIN. The request is received to fetch a VID, which is unallocated yet at the time of request. There are many types of VIDs such as Perpetual VIDs, Transactional, Long term, short term.

Solution

The key solution considerations are

A pool of the VIDs are maintained for the faster dispatch of the VIDs to the requestor.

• Vert.x REST Services: Following are the services which are available for the VID generator component,

1. VID Fetcher Service

   • This service requests for an unassigned VIDs.

   • Expiry days is passed as a parameter to this service. So, the VID pool knows when to expire this VID.

   • In case of perpetual VIDs, the expiry days is not passed. So that, the expiry of the VIDs have to be called back specifically.

   • Each time when this service is called, a call is triggered to the "VID pool size checker"

   • Once the VID assigned, the status is changed to ASSIGNED

Flowchart diagram for fetcher

1. VID Revoke Service

   • This service revokes the VID and allocates the VID in the free pool.

   • This service accepts the VID as input.

   • The requested VID status is changed to EXPIRED

   • The expired VID can be reallocated after the configured cool-off period

Flowchart diagram for revoker

• Vert.x Verticles: Following are the various verticles which are available,

1. VID pool size checker

   • This vertical checks whether the pool has the available sufficient VIDs.

   • The configuration for the Shrink pool size, number of VIDs to be generated etc., are retrieved from the config server.

   • If the pool had shrunk below the configured size, the next "VID Pool Populator" vertical is notified.

   • The "VID pool size checker" vertical is called whenever a request is received for the VID generator.

2. VID Pool Populator

   • When the notification is received from the "VID pool size checker", this vertical is notified to generate the next set of VIDs are generated and placed in the pool.

   • When this vertical runs, it creates a lock. So that no multiple populator runs.

   • The worker verticle size is double as "VID Genertor Service".

   • The status of the new generated VIDs is AVAILABLE

• Vert.x expirer:

  • The expired VIDs status' have to be changed back to available. This scheduler runs at night when the traffic is minimal. The entire database have to be scanned for the expired VIDs.

  • The VID's status is changed back to AVAILABLE, if the VID is expired and crossed the cool-off period.

Flowchart diagram for expirer

• Database:

1. A separate schema is needed for the VID.

2. VID Statuses are maintained in the database.

Module diagram

Data Architecture Principles

MOSIP deals with sensitive information pertaining to the identity of people. It is a central repository of identity data and extra attention is paid to ensure the security and privacy of this data. MOSIP advocates minimalism in the data collected and incorporates features to minimise the interpretation of this data as information. A low-to-zero knowledge design paradigm is used to achieve this.

Data Sets in MOSIP

• Master Data - This includes lookups, locations, centres, devices, zones etc. This is not sensitive information

• Configuration Manager Data - This includes system configuration information and must be protected. It does not contain any personal information.

• Registration Client Database - This is a local database in the registration client. This contains local copies of the relevant master data, downloaded pre-registration information and some transactional information. The pre-registration information is sensitive and encrypted and stored.

• Registration Packets - Registration packets are created and encrypted in memory on the registration client and then persisted in the encrypted form. The sync process moves these packets to the server for processing. These packets are the source of truth and are digitally signed.

• Registration Processor Database - The registration processor contains transactional information about the RIDs being processed and does not contain any personal information.

• ID Repository Entries - The ID Repository contains the identity data. This includes biographic/demographic information and biometric information. The actual storage of these is distributed between RDBMS and object storage.

• Authentication Entries - It has encrypted records with one-way linkage to the ID using cryptography. The information can be decrypted for return as part of the KYC response. Biometrics stored here are only non-reversible extracts. A low-resolution photograph can be stored for KYC purposes.

• Partner Management Data - This contains protected information such as the API Key and Public Key of the partner. There is no personal information here.

• Audit Trail - This does not contain any personal information. It does contain a transaction id for traceability.

• Application Logs - These logs do not contain any personal information.

• Resident Services Data - This has a transaction history with ID numbers but does not contain any personal information.

• Pre-Registration Data - This has personal information and is stored in an encrypted form.

• IAM Data - The mosip system user list is present here and this is protected information as it controls access to the system.

Data Storage Guidelines

• PII of an individual like name, age, gender, address etc... and other sensitive information must be signed and stored in an encrypted form.

• Documents and images must not be stored in a database table. They must be stored in an object store and referenced in DB.

• Object Store should have only encrypted data present in it with access control.

• No business logic is applied at the database level, only Primary, Unique, foreign keys and not-null are applied. Foreign keys are applied within the same database, if a table is referenced in another database then no FK is applied.

• Database-specific features like triggers, DB functions like sequence generators etc.… must not be used in MOSIP. This avoids vendor lock-in

• The surrogate key, wherever used, must be a random number and not be generated based on the record data or sequence number.

• Direct queries on the database by a human must not be made. Database administrators must ensure this control during database configuration setup

• The database is setup in UTF-8*** file format to support multiple languages

• The following data types are used

  • Character Varying

  • Timestamp

  • Date

  • Integer

  • Number

  • Bytea/blob

  • Boolean

Logical view of MOSIP data system

Access Control to Data

In MOSIP, the following users are defined to perform various activities and have control over the DB objects that are defined

• sysadmin: sysadmin user is a super administrator role, who will have all the privileges to perform any task within the database. Currently, all the objects are owned by the sysadmin.

• dbadmin: dbadmin user is created to handle all the database administration activities like monitoring, performance tuning, backups, restore, replication setup, etc.

• appadmin: appadmin user is used to performing all the DDL tasks. All the DB objects that are created in these databases will be owned by appadmin user.

• Application User: Each module will have a user created to perform DML tasks like CRUD operations. Will have masteruser, prereguser, idauser, idrepouser, idmapuser, kerneluser, audituser, regprcuser, keymgruser, regdeviceuser, authdeviceuser to perform tasks in respective modules.

Multi-Language

The MOSIP platform is being built for multiple countries, there is a need to support multiple languages. So as per the requirements, MOSIP will support multiple languages as configured by the country-level administrator. Multi-language support is needed for the following datasets.

• Master Data

• ID data of an individual

• Transaction comments

• Labels used in UI

• Messages and notifications

From the database side, the data will support the UTF-8 Unicode character set to store data entered in multiple languages.

There will not be any in-built support to translate data at the database level. Any translation or transliteration will be handled at API or UI layer. Internationalization support is available to handle multiple language needs in the user interface and communication templates. For master data, the information can be stored in multiple languages. For user data, MOSIP supports the storage of data in two languages.

Performance

To support performance, the following database design features are to be considered

• Database sharding: By default, the sharding algorithm is not applied in the MOSIP system. SI can define the sharding algorithm based on the deployment setup

• All tables will have a primary key index on the primary key field. This will help in faster retrievals and joins

• All foreign keys will have indexes defined so that they will help in faster joins

• No referential integrity is applied on tables across databases

• Partitioning: Partitioning design is database-specific. Depending upon the chosen database, the country may employ the partitioning approach as prescribed by the database engine"

• Data in object stores should be easily addressable with hierarchical path conventions

Data Model Consideration

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

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

• Database-specific features: The use of DB-specific features like defaults, DB sequences, identify fields are not used.

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

• Data Security: Individual and security-related information is encrypted.

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

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.

Packet Structure

The packet is created using the Commons Packet Manager, which creates a packet in the below structure using the .

Encrypted ZIP File

The packet name here is also the request ID that is generated for a request created when a resident enrolls into MOSIP, requests for updating data or request for finding his/her lost id. The request ID is a 29 digit number derived from the Center ID (5 digits), Machine ID (5 digits), sequence number (5 digits), timestamp (14 digits).

Folder Structure

• Container: The container is the base folder in which the sub-packets are stored with their respective JSON files containing meta information.

• Sub-Packets: Inside the container we ideally have three packets named as ID Packet, Evidence Packet and Optional Packet. Data inside each packet is stored based on a property in ID Schema called "Field Category".

• Packet JSON: Each sub packet has a JSON file associated with it which contains the meta information of the respective sub-packet.

• ID Object: Each packet has an ID JSON attached with it which has basic demographic data of the resident, document names that were uploaded, information about the introducers or guardians, biometrics file names (of applicant, introducer, guardians) and the version of the ID schema used. Data for each ID JSON is populated based on the ID Schema property, "Field Category".

• Biometric Files: The biometric data of the resident, officer, supervisor, intorducer or guardian is stored in respective and in respective folders as driven by ID schema.

• Documents: The documents uploaded by the resident during registration or pre-registration is stored in respective folders as driven by ID schema.

• Packet Meta Information: A bunch of meta data is generated during the registration process like the officer's or supervisor's id, machine details, device details, gps location, etc. which is stored in the Packet Meta Info file in JSON format.

• Audit: The audit trails created during packet creation is logged and sent to registration processor to be uploaded in the audit database for analytics.

• Packet Hash: During the packet creation a hash of the data being collected is stored in these files so that the data can be verified when the packet reaches the server. We have two types of hash file, Packet Data Hash file & Packet Operation Hash file.

Packet Encryption Procedure

Before writing the packet into the local disk, the zipped content should be encrypted using Session and RSA public key (center specific) to secure the data. The same data can only be decrypted at server end where the private key is available.

• Session Key Encryption:

  • Session key generation is a randomly generated and sent to client as part of sync from server.

  • Pass the created Zip object [in-memory] through the AES-256 bit encryption.

  • Pass the Random Session Key as a seed to this AES encryption.

  • Get the Registration Officer Id from user context object.

• RSA Public Key Encryption:

  • AES Session key bytes pass through the RSA public key encryption.

• Use the "#KEY_SPLITTER#" as a key separator for the AES encrypted bytes and the RSA Public key encrypted Session key seed.

• Append the RSA Public key Encrypted Session Key, Key Separator to the AES encrypted bytes.

• Append the EO and machine information as a META-INFO JSON file and create another ZIP out of it. [Packet Zip + META-INFO JSON]

• Save the encrypted data as a ZIP in local file system under the defined location in configuration file.

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

• ID Authentication

• Resident services

Key Features

• Store identity information for a given UIN.

• Update identity information partially or status of UIN.

• Read identity Information associated with a valid UIN.

• Read identity Information for a given RID.

• Check status of UIN for validating a UIN.

The identity data stored inside the ID Repository is encrypted. This is the most critical storage repository and is configured keeping the following non-functional aspects in mind:

• Scalability

• Performance

• High availability

ID Repository functionality

Store identity data and documents

Upon receiving the request to store identity details of an individual, the system validates input ID attributes in the request against MOSIP ID defined for the country.

1. Stores ID JSON, biometric documents, proof documents of an individual generated during registration.

2. On successful storage of identity for an individual, status of UIN of the individual by default is marked as 'ACTIVATED'.

Retrieve stored identity details by UIN or RID

Upon receiving a request to retrieve identity details of an individual based on input UIN or RID and type as an optional parameter, the system performs the following steps:

1. Validates if input UIN is 'ACTIVATED'.

2. Retrieves latest ID attributes of the individual.

3. The system retrieves and sends demographic or biometric details or both.

Update identity data and documents

Upon receiving a request to update identity details of an individual, the system performs the following steps:

1. Validates if input UIN is 'ACTIVATED'

2. Updates input ID attributes of the individual.

3. Updates demographic/biometric/both

4. Updates status of UIN as 'DEACTIVATED' or 'BLOCKED' if requested.

5. Sends the response with updated ID details of the individual.

De-activate/re-activate UIN and its associated VIDs

An individual's UIN/VIDS can be de-activated or re-activated.

Lock/Unlock of authentication types

An individual can lock or unlock a particular authentication type using resident services, for example, locking demographic and/or biometric authentication, the system locks the requested authentication type after certain validations. After the requested authentication type is locked for the individual, then he/she will not be able to authenticate himself/herself by using locked authentication type. Similarly, the individual can choose to unlock these authentication types.

Process flow

Identity service - Store identity data and documents

Identity service - Retrieve stored identity details by UIN or RID

Identity service - Update identity data and documents

VID service

Logical view

Services

The services, code, design and documentation are available in

Build and Deploy

Refer to build and deploy instructions in

APIs

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 anonymous_profile table is created for the ID issuance module and is populated as per the JSON structure given below.

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

Table Of Content

Test Rig Definition

Test Rig represents a one click automation to build, deploy and test a software module. Successful execution of test rig would ascertain complete setup of the MOSIP platform.

Test-Rig comprises of multiple components starting from:

1. Kubernetes env setup

2. Pulling the source code from the GIT repository

3. Running sonarqube tests for static code analysis

4. Building the application using maven

5. Automated application deployment using Kubernetes

6. Running automated unit tests

7. Running automated tests to verify and validate the application build against the given requirements.

Test Automation

MOSIP platform architecture is mainly based on Micro services and SEDA architecture. Therefore it predominantly comprises of Rest & JAVA APIs. Therefore test automation best serves the purpose of detailed API level testing. Test automation is the key to the successful testing of individual APIs and their interrelation with interdependent APIs. It ensures comprehensive test coverage and test data.

Automation deliverables mainly comprises of individual module level suites for the individual MOSIP modules:

1. Pre-Registration

2. Registration Client

3. Registration Processor

4. IDA

5. Kernel

Additionally there will be an end to end, system level test suite that will cut across all modules covering the functionality

Module Level Automation Suites

The below diagram depicts the various building blocks of the module level suite.

Salient features

1. The automation suite is configurable to selectively execute tests such as Sanity or/and Regression

2. Each module level suite covers API and inter API automation

The individual module level test suites and the end to end suite are triggered via the CI/CD pipeline and run post application deployment

The user guides listed below detail the usage of individual module level automation suites

System Level or E2E Automation Suite (Test Rig)

End to end system level Test Rig covers the functionality across the modules starting with Pre-Registration and ending in Registration Processor or IDA.

The below diagram depicts the overall design of the end to end suite.

Configurations in Pre-Registration Properties files

File Name: pre-registration-mz.properties

Templates used by Pre-Registration

Email Acknowledgment

This template is used in email notification sent to the applicants when they completes their pre-registration appointment booking. This email is sent to the applicant's email id which is collected as part of pre-registration data collection.

Template type code: Email-Acknowledgement

Sample template:

Dear $name,

Your Pre-Registration for UIN is Completed Successfully on $Date at $Time. Your ID is #$PRID.
Appointment is scheduled for $Appointmentdate at $Appointmenttime.
you will also receive the details on your registered Mobile Number

Attributes:

• $name - Name of the applicant

• $date - Date when pre-registration was done

• $time - Time when pre-registration was done

• $PRID - Pre-registration ID of the applicant

• $Appointmentdate - Appointment date

• $Appointmenttime - Appointment time

SMS Acknowledgement

This template is used in sms notification sent to the applicants when they completes their pre-registration appointment booking. This sms is sent to the applicant's mobile number which is collected as part of pre-registration data collection.

Template type code: SMS-Acknowledgement

Sample template:

Your Pre-Registration for UIN is Completed Successfully on $Date at $Time. 
Your ID is #$PRID.
Appointment is scheduled for $Appointmentdate at $Appointmenttime.
You will also receive the details on your registered email address.

Attributes:

• $date - Date when pre-registration was done

• $time - Time when pre-registration was done

• $PRID - Pre-registration ID of the applicant

• $Appointmentdate - Appointment date

• $Appointmenttime - Appointment time

Subject for Email Acknowledgement

This template is used to set the subject of the email notification sent to the resident.

Template type code: Acknowledgement-email-subject

Sample template:

Pre-Registration $PRID: Acknowledgement 

Attributes:

• $PRID - Pre-registration ID of the applicant

Consent

This is a template for taking consent of the applicant before he/she provides his/her demographic details.

Template Type Code:

Sample Template: consent

I understand that the data collected about me during pre-registration by the said authority includes my -  
  • Name
  • Date of birth
  • Gender
  • Address
  • Contact details
  • Documents
I also understand that this information will be stored and processed for the purpose of verifying my identity in order to access various services, or to comply with a legal obligation. I give my consent for the collection of this data for this purpose.

Attributes: This template doesn't support any attributes.

Cancel Appointment

This template is used in the SMS or Email notification sent to resident when their appointment is cancelled.

Template type code:

Sample template:

Dear $name,

Your appointment for pre-registration id, $PRID and appointment date and time, $Appointmentdate $Appointmenttime has been canceled due to a government emergency/holiday. Please re-book another slot for Registration.

Thanks

Attributes:

• $name - Name of the applicant

• $PRID - Pre-registration ID of the applicant

• $Appointmentdate - Appointment date of the applicant

• $Appointmenttime - Appointment time of the applicant

Onscreen Acknowledgement

Template type code: Onscreen-Acknowledgement

Sample template:

1. Guideline 1
2. Guideline 2
3. Guideline 3
4. Guideline 4
5. Guideline 5
6. Guideline 6
7. Guideline 7
8. Guideline 8
9. Guideline 9
10. Guideline 10

Attributes: This template doesn't support any attributes.

Pre-Registration UI Specification

File Name: pre-registration-demographic.json

For details about the pre-registration UI specification, please go through this page.

Pre-Registration Mapping JSON

This is a mapping file for the Pre-registration ID object. The fields name, proofOfAddress, and postalCode are the only attributes that are used internally in Pre-registration.

• name - Name of the applicant. It is used in notification templates & the Pre-registration dashboard screen.

• proofOfAddress - Document containing Proof of Address. It is used in the document upload screen to fetch the address document from another applicant.

• postalCode - Postal Code in the Address. To fetch the list of centers for the postal code provided by the individual while providing the demographic details.

File Name: pre-registration-identity-mapping.json

{
	"identity": {
		"name": {
			"value": "fullName",
			"isMandatory" : true
		},
		"proofOfAddress": {
			"value" : "proofOfAddress"
		},
		"postalCode": {
			"value" : "postalCode"
		}
	}
}

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 registration-env.properties file.

mosip.mdm.enabled=Y

Registering biometric devices for registration

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

• Register MDS - MDS can be registered with MOSIP using Register MDS API

• Whitelist Device - Biometric Devices can be white-listed using below steps:

  • Add Device Specification (like model, make, etc.) using Device Specification API

  • Map Biometric Devices to Device Specifications using Device API

  • Map White-listed Device to a Center ID to which Registration Client is tagged using Registration Centre Device API

• Register Device - Biometric device can be registered using MOSIP using Register Device API

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)

• eod_auth (Authentication for apporoving EOD packets)

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-env.properties

mosip.registration.mds.fingerprint.dedup.enable.flag=Y    
mosip.registration.mds.iris.dedup.enable.flag=Y    
mosip.registration.mds.face.dedup.enable.flag=Y    

Registration Processor

Configuring ABIS queue

ABIS queue can be configured in RegistrationProcessorAbis-env.json 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.

ida.fingerprint.provider=<fully qualified classname of Biometric SDK>
ida.face.provider=<fully qualified classname of Biometric SDK>  
ida.iris.provider=<fully qualified classname of Biometric SDK>
ida.composite.biometric.provider=<fully qualified classname of Biometric SDK>

Registering biometric devices for authentication

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

• Register MDS - MDS can be registered with MOSIP using Register MDS API

• Register Device - Biometric device can be registered using MOSIP using Register Device API

• Update the code of the registered device to the serial number of the device in register_device_master and register_device_master_h table.

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.

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 ID Authentication API Specification 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 Biometric SDK 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

4. Gender - the gender received in authentication request is compared with the individual's gender saved in the authentication database

5. Address - the address attributes received in authentication request is compared with the individual's address attributes saved 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 OTP request API specification.

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 Authentication API Specification.

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 base64URL encoded and the signature is signed using the device key. More details of the biometric data block is available in the Secure Biometric Interface document.

4. The request should be sent to the authentication server, within a set time period in the configurations (i.e. time period between the current time stamp and the request time stamp is <= time period set in configurations).

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 ID Authentication API Specification 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.

   2. The introducer's biometrics are collected for authentication in the server side.

   3. The individual's biometrics are collected for authentication when he/she is trying to update his/her demographic details.

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 ID Authentication API Specification 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

4. Verify if the environment details, domain URI & consent token is valid

5. Verify if the authentication request has data as per the authentication mode selected

6. Verify if the partner is eligible for performing the authentication as per the partner's policy linked to the Partner API key

7. Verify if the VID or UIN details received is valid

8. In case of biometric data,

   1. Verify if the biometric block is signed using the device key

   2. Verify if the digital ID block is signed using the foundational trust module's key

   3. Verify if the timestamp in the digital ID block has reached the authentication server within the configured time period

   4. Once all the above validations are completed the biometrics are sent to the SDK for finding the match

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.

Guidelines to implement Authorization and Authentication techniques in the Angular application are detailed in this document.

Before going in to the components let us discuss the following flows of Authorization and Authentication.

Authentication flow:

1. Initially a login request is made passing user credentials to a REST API as specified in the SPECS of that API.

2. In the response of a successful authentication you will receive user details and an auth_token as the value of the header "Authorization".

3. Now the received auth token has to be stored and re-used. For example let us use sessionStorage to store the auth_token under the key "TOKEN".

4. Now any kind of HTTP/HTTPS requests we make from the application has to be sent by adding a header "Authorization" and value of auth_token stored in sessionStorage with key by name "Token" for the purpose of authentication.

5. If the response comes back with a new token which might be because of previous token getting expired or refresh token mechanisms that happen in the backend, we need to replace the old token with the new one in the session storage.

Authorization flow:

1. After successful login the user details are sent to the client(Angular application/ Browser).

2. Now store the userDetails in the sessionStorage for example under the key "UserDetails".

3. Now we need to hide some pages/components/user action elements etc. based on the roles that the user possess.

Implementation of above flows:

To implement the Authentication and Authorization flows mentioned above, all we need to do is implement an Interceptor and a Directive which were mentioned above and detailed below.

Http Interceptor

Tasks to be implemented in a Client/UI Http interceptor are:

1. Append "Authorization" header to the request using the token value stored in the session storage.

2. Replace/Add the session storage token value with the one received in the response "Authorization" headers.

Below code implements the requirements mentioned above:

import { Injectable } from '@angular/core';
import { HttpInterceptor, HttpRequest, HttpHandler, HttpResponse, HttpEvent, HttpEventType } from '@angular/common/http';
import { Observable } from 'rxjs';
import { map, catchError, tap } from 'rxjs/operators';

@Injectable({
  providedIn: 'root'
})

export class InterceptService implements HttpInterceptor {
  constructor() { }

  intercept(request: HttpRequest<any>, next: HttpHandler): Observable<HttpEvent<any>> {
    const token = sessionStorage.getItem('TOKEN');
    if (token) {
      request = request.clone({
        setHeaders: {
          'Authorization': token
        }
      });
    }

    return next.handle(request).pipe(tap(event => {
      if (event instanceof HttpResponse) {
        const receivedToken = event.headers.get('Authorization');
        if (receivedToken) {
          sessionStorage.setItem('TOKEN', receivedToken);
        }
      }
    }, err => {
      console.log(err);
    }));
  }
}

Roles Directive

Role of the Roles directive is to fetch roles from UserDetails stored in the session storage and verify if the user has required roles to perform some action or read some details and restrict access accordingly.

Below code implements the requirements mentioned above:

import { Directive, TemplateRef, ViewContainerRef, Input, ElementRef } from '@angular/core';

@Directive({
  selector: '[appRole]'
})

export class RoleDirective {
  userRolesString: any;
  userRoles: Array<string>;
  shouldDisplay = false;
  requiredRoles: Array<string>;

  constructor(private element: ElementRef) { }

  @Input() set appRole(roles: string) {
    this.element.nativeElement.hidden = true;
    const userSessionData = sessionStorage.getItem('UserDetails');
    this.userRolesString = JSON.parse(userSessionData).role;
    this.userRoles = this.userRolesString.split(',');
    this.requiredRoles = roles.split(',');
    this.shouldDisplay = this.userRoles.some(v => this.requiredRoles.indexOf(v) !== -1);
    if (this.shouldDisplay) {
      this.element.nativeElement.hidden = false;
    }
  }
}

Now inject the above interceptor and directive in the app.module.ts as follows

@NgModule({
  declarations: [ RoleDirective, ...],
  imports: [...],
  providers: [{
    provide: HTTP_INTERCEPTORS,
    useClass: InterceptService,
    multi: true
  }, ...],
  bootstrap: [AppComponent]
})

To activate/deactivate => show/hide element all we need to do is add the appRole attribute to the HTML element as shown below:

<button class="btn btn-success" appRole="DIVISION_ADMIN,SUPERVISOR">Add</button>

In the above sample, the add button will only be visible for users with DIVISION_ADMIN or SUPERVISOR role.

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

De-Duplication

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

Demographic De-Duplication

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

Process Flow

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

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

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

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

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

Biometric De-Duplication

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

Process Flow

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

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

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

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

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

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

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

Manual Adjudication

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

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

Request sent to Manual Adjudication System

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

Response received from Manual Adjudication System

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

Process Flow for Biometric Deduplication

Auth adapter is a package that needs to be injected into Mosip's applications exposing REST API's inorder to secure them.

Auth Adapter includes following class definitions:

SecurityConfig

Holds the main configuration for authentication and authorization using spring security.

Inclusions:

• AuthenticationManager bean configuration:

  • This is assigned an that we implemented.

  • RETURNS an instance of the ProviderManager.

• bean configuration:

  • This extends AbstractAuthenticationProcessingFilter.

  • Instance of the is created.

  • This filter comes in line after the .

  • Binds the AuthenticationManager instance created with the filter.

  • Binds the created with the filter.

  • RETURNS an instance of the .

• RestTemplate bean configuration:

  • Binds the instance with the RestTemplate instance created.

  • RETURNS an instance of the RestTemplate.

• Secures endpoints using antMatchers and adds filters in a sequence for execution.

AuthFilter

AuthFilter is bound with AuthenticationManager to attempt authentication.

Attempt Authentication tasks:

• Receives "Authorization" Header from request headers.

• Use the assigned Authentication manager to authenticate with the token.

AuthHeadersFilter

This filter is going to act as a CORS filter. It is assigned before in the filter chain.

Tasks:

• Sets headers to allow cross origin requests.

• Sets header to allow and expose "Authorization" header.

AuthProvider

Contacts auth server to verify token validity.

Tasks:

• Contacts auth server to verify token validity.

• Stores the response body in an instance of .

• Updates token into SecurityContext.

• Bind instance details with the that extends Spring Security's UserDetails.

AuthSuccessHandler

Handles successful authentication. If any action needs to be done after successful authentication, this is where you have to do it.

AuthEntryPoint

Captures and sends "UnAuthorized" error.

AuthToken

• Used in for token details.

• This extends UsernamePasswordAuthenticationToken class.

AuthUserDetails

Used by spring security to store user details like roles and use this across the application for Authorization purpose.

ClientInterceptor

It is used to intercept any http calls made using rest template from this application.

Config:

This is added to the list of interceptors in the RestTemplate bean created in the .

Tasks:

• Intercept all the requests from the application and do the below tasks.

• Intercept a request to add auth token to the "Authorization" header.

• Intercept a response to modify the stored token with the "Authorization" header of the response.

MosipUser

Mosip user is the standard spec that will be tuned based on the details stored in ldap for a user.

AuthControllerAdvice

Adds latest token to the response headers before it is committed.

The Audit Manager in MOSIP captures all the information about the actions performed by various MOSIP applications. This information can further be used for data analysis which will help in inspecting, cleansing, transforming, and modeling data to discovering useful information, informing conclusions, and decision-making.

Audit Log Parameters

The following parameters are captured as a part of the audit service,

Application-Specific Audit Details

• I

Abbreviations

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.

ID Authentication Service

ID Auth allows only partners to make authentication requests. The requests are cryptographically secured and verified. A partner that captures data from a biometric device must conform to standards to ensure interoperability.

User Event Type

The following events are triggered as part of User Event Type in ID Authentication Service module

System Event Type

The following events are triggered as part of System Event Type in ID Authentication Service module

ClamAV is a free, cross-platform and open-source antivirus software toolkit able to detect many types of malicious software, including viruses.

Steps to install ClamAV in RHEL-7.5

To install clamAV first we need to install EPEL Repository:

After that we need to install ClamAV and its related tools.

After completion of above steps, we need to configure installed ClamAV. This can be done via editing /etc/clamd.d/scan.conf. In this file we have to remove Example lines. So that ClamAV can use this file's configurations. We can easily do it via running following command -

Another thing we need to do in this file is to define our TCP server type. Open this file using -

here this we need to uncomment line with #LocalSocket /var/run/clamd.scan/clamd.sock. Just remove # symbol from the beginning of the line.

Now we need to configure FreshClam so that it can update ClamAV db automatically. For doing that follow below steps -

First create a backup of original FreshClam Configuration file -

In this freshclam.conf file, Here also we need to remove Example line from the file. Run following command to delete all Example lines-

Test freshclam via running-

After running above command you should see an output similar to this -

We will create a service of freshclam so that freshclam will run in the daemon mode and periodically check for updates throughout the day. To do that we will create a service file for freshclam -

And add below content -

Now save and quit. Also reload the systemd daemon to refresh the changes -

Next start and enable the freshclam service -

Now freshclam setup is complete and our ClamAV db is upto date. We can continue setting up ClamAV. Now we will copy ClamAV service file to system service folder.

Since we have changed the name, we need to change it at the file that uses this service as well -

Remove @ symbol from .include /lib/systemd/system/[email protected] line and save the file.

We will edit Clamd service file now -

Add following lines at the end of clamd.service file.

And also remove %i symbol from various locations (ex: Description and ExecStart options). Note that at the end of the editing the service file should look something like this -

Now finally start the ClamAV service.

If it works fine, then enable this service and test the status of ClamAV service -

Now in MOSIP we require ClamAV to be available on Port 3310. To expose ClamAV service on Port 3310, edit scan.conf

and Uncomment #TCPSocket 3310 by removing #. After that restart the clamd@scan service -

Since we are exposing ClamAV on 3310 port, we need to allow incoming traffic through this port. In RHEL 7 run below command to add firewall rule -

Reference link:

The hardware compute and storage requirements for MOSIP core platform are estimated as below.

Production

Compute

Compute hardware estimates for a production deployment:

* Average throughput

** VCPU: Virtual CPU

We estimate 30% (approx) additional compute capacitiy for administration, monitoring and maintenance. This may be optimized by the System Integrator.

Notes

1. High availability is taken into consideration with assumed replication factor of 2 per service pod/docker

2. The above estimates do not include compute servers needed for

   1. Database

   2. HDFS/CEPH

   6. Virus scan

   7. Load balancers

   8. External IAM

   9. Disaster recovery