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

Audience

• Data Modelers

• Database Administrators

• Database Developers

• Application Developers

A simple and consistent naming convention for database objects, when followed rigorously, can help database application developers greatly.

Common Naming Standards

Common standards are followed

• Singular names for the entities

• Object name length to be less than 30 chars

• Lowercase object names separated by an underscore (_)

• Only defined abbreviations are used

• No prefix or suffix to the table names

• Each table is defined as an alias, this alias is used in constraints and index names

Database Naming Standards

The database names will follow the below naming convention mosip_(abbreviated value of the module name)

Ex: mosip_prereg

Schema Naming Standards

The schema name is named after the DB name, by default, without mosip_. If there is more than one schema in a DB, then a proper single-word name is assigned, either a full word or an abbreviated word. Ex: prereg

Table Naming Standards

• The table name can have one or two words that describe the contents of the table separated by an underscore (_).

• Table name should always be in the singular.

• An alias for each table is defined, this alias can be used in various other places like reference keys, indexes, constraints, etc.

Index Naming Standards

Indexes are named as idx_(table-alias)_(column-abbreviation)

Key Naming Standards (Primary, Unique, Foreign Keys)

Primary Key: Each table should have a primary key, the key should be named “pk_table-alias_column-name”. If it is a composite key, then in place of the column name any meaningful name can be provided.

Unique Key: If a surrogate is used as PK then create a unique key, on fields that uniquely define a business key. The naming of the unique key should be “uk_table-alias_column-names”.

Foreign Key: For any references from a table with the other tables, creating a foreign key is mandatory. This helps maintain referential integrity. A foreign key can be named as fk__table-alias1_table-alias2

Attribute Standards

Standardize the attribute implementation-defined the following common datatypes used across the MOSIP system. The datatype sizes are defined to consider multi-language storage support, which may vary based on the implementation.

Acronyms

The following acronyms are used in the data model

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.

Introduction

In MOSIP, privacy and security are the highest priorities and this document details the measures that have been implemented in the platform so far. As an open-source project, we aim to continuously improve the security features and incorporate new developments through collaborations and community contributions. We use a variety of security tools to assess security, discover vulnerabilities and address them.

Governing Principles

MOSIP's approach to privacy and security is determined by the framework principles under which it operates.

MOSIP Security Design Key Features

• Direct access to data stored in the database is not permitted - data is accessed via APIs only.

• The Zero-Knowledge Administration principle is used so administrators can manage data without seeing the actual data. Data can be accessed only via APIs

• The integrity of each database row is protected to prevent any malicious tampering like swapping identities, for instance.

• Revocable Virtual IDs and Tokens are used to thwart any attempt on profiling the users.

• Access controls are implemented on all APIs to ensure data privacy (who can see what).

• All APIs support rate-limiting and are digitally signed.

• All network channels assumed 'dirty'.

• Every artefact (including JSON data sent over API) is digitally signed.

MOSIP Cryptography Algorithms

MOSIP uses the following algorithms:

1. RSA OAEP 2048 bit minimum for all PKI-based encryption.

2. AES GCM 256-bit minimum for all Symmetric key encryption.

3. SHA256 is the standard hashing algorithm.

4. X509 V3 as the certificate standard.

5. FIPS 140-2 Level 3 is the minimum Hardware Security Module (HSM) standard.

6. PKCS11 is used for HSM communication.

Database encryption

As a principle, MOSIP does not use any mechanism in-built in a database for encryption. All sensitive data to be stored in a DB is encrypted/decrypted outside the DB at the application layer.

• All sensitive (configurable) data is encrypted using a symmetric key algorithm. MOSIP supports AES 256 algorithm by default.

• Each cell is encrypted using its own symmetric key and the keys are selected randomly.

• By default, we generate 10,000 symmetric keys for database encryption. This is a soft limit and that can be increased.

• The symmetric keys are encrypted using a master key in HSM.

• Every key has an expiry and the application follows the expiry to update the data with new keys.

Registration data encryption

Registration Client is used to collecting all the personal and biometric information for MOSIP. The client is designed to work on TPM-compatible machines. The client follows the following principles:

• All machines are registered using the TPM identity keys. The public part of these keys is pre-whitelisted in the MOSIP database.

• An SK from the SRK key is created to encrypt all the other keys used by MOSIP.

• All local configurations are encrypted using the same mechanism.

• A set of (defaulted to 10000) RSA keys is created for registration. These keys are generated in an HSM and the public part of these keys is embedded in the MOSIP registration client. These keys are used to encrypt the user's/residents' data.

• The registration data in its unencrypted form is always stored in the volatile memory and never stored on permanent storage.

Key management

MOSIP uses AES and RSA keys. By default, the MOSIP is designed to have the expiry and key rotation as configurable parameters. The default values are set as follows:

• AES 256-bit keys - 6 months from the date of creation.

• RSA 2048-bit encryption keys - 1 year from the date of creation

• RSA 2048-bit signature keys - 2 years from the date of creation.

Database encryption keys

• MOSIP uses symmetric keys to protect its database.

• Every key has an expiry date upon creation. (It's defined by the configuration, Default set to 6 Months)

There are two modes of operation for key management:

• Inline

  • In this mode, the system would look at a configuration to see

  • When data is written back to the database a new active key is used.

  • When data is read where the encryption key is expired the system notifies the key management that the expired key is used and has to be re-encrypted with an active key.

• Batch

  • In this mode, the system would search for all the tables for encrypted data with expired keys.

  • Re-encrypt them with the new active keys.

  • This mode is scheduled to run on a need basis or bi-monthly so there is no huge data crunch and the inline mode would have re-encrypted most of the data.

Registration data encryption

Registration Client is used to collecting all the personal and biometric information for MOSIP. The client is designed to work on TPM-compatible machines. The client follows the following principles:

• All machines are registered using the TPM identity keys. The public part of these keys is pre-whitelisted in the MOSIP database.

• An SK from the SRK key is created to encrypt all the other keys used by MOSIP.

• All local configurations are encrypted using the same mechanism.

• A set of (defaulted to 10000) RSA keys is created for registration. These keys are generated in an HSM and the public part of these keys is embedded in the MOSIP registration client. These keys are used to encrypt the user's/resident's data.

• The registration data in its unencrypted form is always stored in the volatile memory and never stored in any permanent storage or filesystem.

Key Management

RSA 2048-bit keys are used for the encryption of resident/user data from the registration client. The expiry policy for the same is set to 1 year.

• The default expiry of these keys is set to 1 year.

• These keys will be rotated using the API. Currently, the key rotation would happen manually with client upgrades.

Digital Signature Keys

The digital signature keys are domain-specific and are used to sign the artefacts generated by MOSIP for external consumption. It's expected that the countries would follow their legal standard on digital signatures. The default expiry is set to 2 years.

Authentication & Authorization (TBD)

In MOSIP Authentication largely falls into the below categories:

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

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

In MOSIP Authorization falls into the below categories:

• Authorization of APIs accessed via web channel (We are in migration to a KeyCloak server at this point in time. Soon we will publish the documents)

• Authorization to access specific data (will be implemented in v3)

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 a hierarchy and users using Apache Directory Studio.

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

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:

{
  "processName": "", //New, Update or Lost. Correction is not included here
  "date": "", //Occurance of the event date. Just date with no time. 
  "oldProfile": {
    "yearOfBirth": "", //Only the year of birth is kept.  
    "gender": "", // Code for - Female, Male, Transgender, ...
    "location": [""], //hiearchy except last 2 (means no personal address) maintained as per the array. JSON array remembers the order
    "preferredLanguages": [""], // list of preferred languages
    "channel":["list of channel names eg: phone,email"],
    "exceptions": [{
        "type" : "", //eg: Finger
        "subType": "" //eg: Right Thumb
    }],
    "verified":[""] // list of all the verified id schema atribute names
    "biometricInfo": [ {
        "type" : "",
        "subType": "",
        "qualityScore": "",
        "attempts": "",
        "digitalId": "" //Digital Id of the device
   }],
   "documents": [""] //type of the documents eg: driving license, passport.
  },
  "newProfile": {
    "yearOfBirth": "",
    "gender": "", // Confidential, Female, Male, Transgender, ...
    "location": [""], //hiearchy except last 2 (means no personal address) maintained as per the array. JSON array remembers the order
    "preferredLanguages": [""], // list of preferred languages
    "channel":["list of channel names eg: phone,email"],
    "exceptions": [{
        "type" : "", //eg: Finger
        "subType": "" //eg: Right Thumb
    }], 
    "verified": [""] // list of all the verified id schema atribute names
    "biometricInfo": [ {
        "type" : "",
        "subType": "",
        "qualityScore": "",
        "attempts": "",
        "digitalId": "" //Digital Id of the device
   }],
    "documents": [""] //type of the documents eg: driving license, passport
  }
}

Below is the image for the Anonymous profile table created in the ID repository schema

This page lists all the technologies used in building MOSIP. As far as possible free and open source software with clear long term support availability have been chosen. For a deployment certain choices can be replaced with other free or commercial options.

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

Data Model Considerations

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

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

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

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

• Data Security: Individual and security related information is encrypted

Data Model

Databases inventory in MOSIP.

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

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

Pillars of a Digital Future

• Digital Identity and Trust

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

Design choices

The MOSIP architecture decisions have been based on the 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.