Overview

In the context of MOSIP, identifiers are alphanumeric digital handles for identities in the system. While a person's identity is represented as a collection of biographic and biometric attributes that can uniquely identify the person, the identity is referred to using identifiers.

UIN

Unique Identification Number (UIN), as the name suggests, is a unique number assigned to a resident. UIN never changes and is non-revocable. UIN is randomized such that one should not be able to derive any Personal Identifiable Information (PII) from the number itself.

The rules that govern generation of a UIN are listed here.

VID

The VID / Virtual ID is an alias identifier that can be used for authentication transactions. The key characteristic of such an identifier is that it expires. This allows for free disclosure and usage of this identifier in various contexts. It is privacy friendly in a way such that it can be revoked, configured for one time usage and is not linkable. Since these are used for authentication transactions, such identifiers are to be known to the user only or generated with their participation.

RID / AID

The Application ID (AID) refers to the unique identifier given to a resident during any ID lifecycle event, such as ID Issuance, ID Update, or Lost ID retrieval, at the registration center. It serves as a distinguishing factor for each specific event and can later be utilized by the resident to check the progress or status of the event. Previously, in MOSIP, the Application ID was referred to as the RID (Registration ID) and/or PRID (Pre-registration ID).

PRID

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

Token ID (PSUT - Partner Specific User Token)

The Token identifier/PSUT is a system provided customer reference number for relying parties to uniquely identify the users in their system. The token identifier is an alias meant for the partner/relying party typically unique (Configured through PMS policy, in case uniqueness is not the need then partner policy can be set to provide random number) to them. This identifier is included in the response of the authentication transactions. One key differentiator is that the PSUT is not accepted as an identifier for authentication transactions. This ensures that the partner who has the PSUT can not reauthneticate.

What is Digital Identification?

Digital Identification is a means of identifying 'who you are' through some kind of digital medium. The digital medium could be any device such as a mobile phone or a computer or anything that has a digital means of identifying 'who you are' in both offline and online mode with your consent irrespective of your religion, caste, creed, gender, country and ethnicity. The Internet is only an enabler but is not the mandatory requirement for digital identification. While identifying 'who you are', the user bearing the identity must have absolute control of revealing a controlled set of information that they wish to reveal and not everything in order to become eligible for getting a service rendered.

What is a foundational ID system?

Governments are exploring the development of multipurpose foundational ID systems, in which individuals receive a unique identifier from the government that they can use for identity assertion and verification. It can then be used to access a wide variety of government and private services.

Functional IDs are the IDs that are used in specific use cases. By design, they are created having the final usecase in mind such as healthcare, finance, banking, insurance, social and civil registry etc. The Functional ID systems can leverage the Foundational ID system.

What is MOSIP?

MOSIP is a robust, secure, open-source platform for building foundational identity systems. MOSIP is configurable and flexible to adapt to a country’s national ID requirements.

Privacy and security

MOSIP modules

MOSIP ecosystem

MOSIP needs to work along with other ecosystem players to create a solution for a particular country.

MOSIP offerings

Key MOSIP offerings are:

• ID Lifecycle Management

• ID Authentication

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 systems just the way needed. The image below depicts how MOSIP provides the base layer to build a national ID platform.

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 Lifecycle Management features and identity verification capabilities out of the box. Conceived to help build global digital public goods in the space of digital identification and governance, MOSIP is anchored at the International Institute of Information Technology, Bangalore (IIIT-B). It harnesses the power of open-source technologies and embraces the best practices of scalability, security and privacy. Learn more >>

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 populations (a few thousand to several hundreds of millions.

Releases

The latest release of MOSIP, version 1.2.0 LTS is here! Check out the exciting new services and enhancements in the documentation.

To learn more, see our Releases Notes.

To read through the previous version of the documentation, see the Older version documentation (1.1.5).

Resources

• Source Code: GitHub Repositories

• Containers: Docker Repository

• Maven Repository: Nexus Repository

• Presentations: mosip.io

• Training: MOSIP Academy

• Learning videos: YouTube Channel

• Community: MOSIP Community on Discourse

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 profiles per registration centre

• quality of biometric data captured

Information like this will allow policymakers to take corrective measures as and when required.

Some examples are given below:

Example 1: If registration centres are setup for enrolling residents and if they see that the number of women enrolling in a particular area is less because of cultural factors, they can introduce a door-to-door enrollment process to increase coverage.

Example 2: The quality of biometrics captured for a particular registration centre or region can be monitored. And if it is found to be unacceptable, they can proceed to replace the biometric devices in that centre.

Example 3: They can compare the total number of enrollments against the total number of UINs issued. If there is a big gap, they can then address this by increasing the capacity of the registration processor module to handle and process more packets.

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 at various stages in the ID lifecycle like pre-registration, registration processing, ID issuance and authentication.

• As a part of this implementation, a new anonymous_profile table is created in each of these modules and is populated as per the JSON structure given below for each profile.

Note: New DB tables are added for the anonymous profile because data in existing tables (except the pre-registration module) are encrypted and cannot be used to create reports and dashboards.

Anonymous Registration profile

• This profile will be used to capture data about enrollment. This suggests that the user has started the registration process.

• This data is captured at two stages, i.e., during pre-registration and registration processing.

• The same registration profile JSON is re-used to capture data in these two modules.

• This profile data is captured in anonymous_profile tables under the mosip_prereg mosip_regprc schemas.

• We can configure the stage at which the anonymous profile data in the registration processor needs to be captured. This can be configured as a part of the registration processor camel routes in the mosip-config repository as shown below.

The profile will be available from version 1.2.0 and above.

JSON structure of the registration profile is given below

Below is the image for the Anonymous profile table created in the Pre-registration schema

Below is the image for the Anonymous profile table created in the Registration processor schema

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

Anonymous Authentication Profile

• This profile data will be captured when the resident performs authentication.

• The profile data is captured in an anonymous_profile table under the mosip_IDA schema.

The profile will be available from 1.2.0 and above.

JSON structure of the Authentication profile is given below:

Below is the image for the Anonymous profile table created in the IDA schema

Generating dashboards from Anonymous profile data

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

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

• Data Privacy

• No Vendor Lock-in

• Open Standards

• Async/ Offline First

• Commodity Computing

• Fault tolerant

• Manageable

• Secure By Default

Overview

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

High-Level Reference Functional Architecture

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

Overview

ID Schema is a standard that defines dataset that can be stored in the Identity repository for a resident. The schema allows the adopters to customize the fields that's needed for running the identity program.

Defining the ID Schema is the first step towards creating a foundational ID system. Once defined, all applications built on top of the MOSIP platform must conform to the same.

One should not confuse ID Schema with what is seen on the screen of the Registration client/ Pre-registration. ID Schema is the final data that you would like to store against each user in the final ID Repository. Quite often we collect more data than listed in ID Schema. This is essential to validate the user's claim. We should consider these data as transactional and it will never reach the final ID Repository.

Understanding ID Schema

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

Terminology

• Field: Unit of data collected from residents (eg. fullName, dateOfBirth, proofOfIdentity etc).

• Field attribute: Qualification of Field (e.g.: fieldCategory, fieldType, etc).

• Definition: Custom data types are defined for collecting different types of data:

  • simpleType: Multiple languages.

  • documentType: Document metadata.

  • biometricType: Biometric file metadata

JSON keys

• bioAttributes:

  • leftEye, rightEye, leftIndex, leftRing, leftLittle, leftMiddle, rightIndex, rightRing, rightMiddle, rightLittle, rightThumb, leftThumb, face,

• fieldCategory

  • none: Cannot be used for any purpose. But will be stored in id.json (default subpacket). These are used in exceptional cases when we need to store some data for future reference in case of investigating an ID fraud or if law mandates the storage of such data.

  • pvt: Private information, can be used in authentication. A limited data that can be used for authentication & kyc.

  • kyc: Information that can be disclosed to partners either as a credential or through the ekyc API's.

  • evidence: Field is treated as proof and may be subjected to removal. In certain countries law mandates deletion of such data once the Identity of the user is verified. Marking some of the fields as evidence helps in deleting them without violating the source of truth signatures.

  • optional: Field is treated as proof and will be removed after a predefined interval (defined as policy).

• format

  • lowercased: Value stored in lower case format

  • uppercased: Value stored in upper case format

  • none: No format applied to the data

• validators

  • type: Validation engine type. Supported type as of now is regex.

  • validator: Based on the type the actual script is placed here. In case the type is regex then the actual regex pattern is used here.

  • arguments: Array to hold parameter or dependent field IDs required for validation.

• subType

  • For every documentType field, document category code must be the value of this key. This document category code is used to validate the provided document types in the ID object.

ID schema is loaded as a part of master data to identity_schema table in mosip_masterdata DB.

Dependencies

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

1. UI Specifications

Versions of ID Schema

ID Schema is identified based on it's version in the MOSIP system. On publishing of an ID Schema, the schema is versioned. Every ID Object stores the ID Schema version which is validated during ID Object validation.

Good Practice

The following is the list of good practices that MOSIP recommends for creating your ID Schema.

• As a privacy by design practice, it is recommended that the number of fields is kept to a usable minimum in order to avoid profiling.

• Larger number of data results in serious data quality issues.

• Keeping the fields minimum ensures everyone is inclusively added to the foundational identity.

• As a best guide, limit the total number of fields to be less than 10.

• Stick to one version of ID Schema for better compatibility.

Overview

Identity Lifecycle Management refers to the process of issuing and managing user identities in a given system. An individual can visit a registration centre to get a new ID or update their ID details. A registration officer would typically capture the individual’s demographic (name, date of birth, gender, etc.) and biometric (face, iris, and fingerprint image) details.

The various life cycle events are briefly explained below:

• New ID issuance (for adults and infants)

• ID data update or update individual’s information

• De-activate or re-activate the individual’s ID

• Lost ID

• Correction process

New ID issuance

Pre-registration

A resident can access the pre-registration portal and do the following:

• Enter demographic data and upload supporting documents

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

• Receive appointment notifications

• Reschedule, update and cancel appointments

Registration (enrolment)

For adults

• The resident visits a registration centre.

• The registration officer captures demographic details, biometrics and documents and uploads the same for processing.

• Upon successful registration, a registration ID (RID) is allocated to the resident and an acknowledgement slip containing the captured details and the RID is issued (printed) to the resident as proof of registration.

• The registration processor processes the registration details perform quality checks and checks for duplicate entries (de-duplication).

• Upon successful processing, a Unique Identification Number (UIN) is allocated to the resident and a notification is sent to the resident on the registered phone number and/or email.

• Upon a failure in processing, the registration process is discarded and a notification is sent to the resident on the registered phone number and/or email.

For infants/children

• A child visits the registration centre along with a guardian/parent.

• The registration officer captures the demographic details along with the face photo.

Note: For infants/children less than 5 years old, the Registration Client does not capture the biometrics as they are still evolving. However, the country may choose to override the same by modifying the rules accordingly.

• Parent/guardian' UIN or RID and the biometrics needed for authentication are captured.

• Additionally, a proof of relationship document is uploaded.

• Upon successful registration, an acknowledgement receipt containing the registration ID is issued to the parent/guardian.

ID data update/updating individual’s information

• Residents can update their information in two ways:

  • By visiting the registration centre: The demographic and biometric information can be updated at the centres.
• Registration receipt containing the Registration Identity(RID), labels and data in the configured language, and QR code (of the RID) provided to the resident at the centre.

• Updated ID credentials were sent to the resident via the country’s configured printing and postal service.

• Notifications were sent to the resident using the email ID and mobile number provided as a part of demographic data collection.

De-activate/re-activate individual’s ID

• De-activate ID means an individual will not be able to authenticate themselves by using the UIN or VID.

• Likewise, a country can also re-activate an individual’s ID as need be.

Finding a lost ID

In the event of loss of the ID, the resident can go to the nearest registration centre and provide his/her biometrics and optionally provide demographic details. The details are sent to the MOSIP server which performs a biometric and demographic match. Upon a successful match, MOSIP provides mechanisms to retrieve the UIN of the resident which may be printed and delivered to the resident. Notifications are sent to the resident's registered email and/or phone.

Correction process

• In case the system finds an error in the demographic data, documents or biometric data provided by an individual, the correction flow is triggered.

• Before issuing the UIN for the individual, the incorrect or incomplete information provided by the individual is intimated to them.

• Once the corrected information is received by the system, a correction procedure is triggered.

• Updated ID credentials are sent to the resident via the country’s configured printing and postal service.

Overview

MOSIP offers identity verification services that enable the usage of identity in various contexts. After the successful issue of the ID, identity verification services become available for the resident. Online identity verification is enabled through MOSIP's ID Authentication (IDA) module. As MOSIP is a foundational ID system, different services (both government and private) may rely on the foundational ID system to validate the identity of a resident rather than implementing multiple authentication systems. A typical authentication flow is illustrated below:

Refer to the video below to learn more!

Authentication types

Yes/No Authentication

MOSIP offers a yes/no API that can be used for the verification of attributes supplied along with authentication factors. The API verifies the identifier and the provided demographic attributes and also validates other authentication factors such as the OTP or biometrics and responds with a yes or a no. Successful verification of the data results in a yes. This kind of API can be typically used to support the verification of a limited set of demographic data about the person or for simple presence verification when biometrics are used.

KYC Authentication

MOSIP additionally offers a KYC API, which can be used to get an authorized set of attributes for the resident in the response of the API. This API is intended for use by authorized relying parties to perform KYC requests. The authentication includes an identifier along with authentication factors such as OTP and biometrics. The information returned is governed by a policy. Different relying parties can be provided with different KYC data based on their needs. The policy helps implement selective disclosure as part of the KYC data. The data thus returned is digitally signed by the server and can be used by the relying party with confidence.

Multifactor authentication

The authentication APIs support multiple factors. These can be:

• Biometric: Finger, face, iris

• Demographic: Name, date of birth, age, gender etc.

• OTP: One-Time Password Based on the level of assurance needed for the transaction, the relying party can decide which factors are sufficient for identity verification.

Biometric authentication is performed using third-party matcher SDK that performs 1:1 matches on a given modality. Each biometric modality is treated as an independent factor in authentication.

VID

All authentications in MOSIP essentially perform 1:1 matches. This essentially requires the authentication call to specify an identifier of the person and the authentication factors to perform the match on the individual referred to by the identifier. MOSIP supports the usage of multiple identifiers for a person. This promotes anonymity and also acts as a deterrent to profiling the individual. The individual can be identified in the authentication transaction by the UIN or other alias identifiers/ VIDs. When a VID is used there are additional checks to see if the VID has not expired or has not been revoked. The expiry of the VID is governed by the policy chosen at the time of its creation of the VID.

For understanding VIDs and their characteristics, read more about VID.

Tokenization

In one-off usage contexts, identity verification can be anonymous. In cases where identity verification is linked to transactions that need identity assurance, there is a need to tie the user identity of the user to the transaction. This is achieved by way of providing such relying parties with a "sticky" token identifier that can be used as a reference ID for the individual in their system. The authentication APIs return a token when the authentication is successful. Based on the type of relying party and their policy, the token is either random or sticky. The expected usage is for the relying party to remember the token returned by the authentication API for referring to their customer and for audit/redressal purposes.

Learn more about the Token ID.

Relying parties and policies

Read more about parties and policies.

Consent

MOSIP has a provision for specifying the user consent associated with an authentication transaction. This can be stored for audit purposes and the authentication flow can be extended to verify the consent if needed.

Hotlisting

MOSIP has a provision to help protect against the misuse of identity. For any report of lost identity or detection of fraudulent activity by fraud, the module can require the temporary suspension of authentication activities on a user. This is enabled by the hotlisting feature. The authentication service checks if the identifier used is hotlisted and if so, the authentication process is aborted and fails. The hotlisting service can be used by helpdesk and fraud solutions to list and delist the identifiers that need to be blocked temporarily.

Overview

MOSIP platform integrates with the following biometric components:

All biometric components need to comply with standard interfaces defined by MOSIP. Test kits to verify compatibility are available.

Vendors who provide biometric systems are of MOSIP.

Modalities

Modalities supported in MOSIP are

MOSIP's fundamental architecture and design incorporate the highest levels of privacy and security.

Security by design

Key security features:

• Encryption of data in-flight or rest. (See )

• Integration with trusted applications only.

• Fraud avoidance - association of authentication only with specific transactions.

• Misuse prevention - user can lock or unlock their authentication.

• Virtual ID and Tokens to prevent identity theft.

• All data sent out of MOSIP will be digitally signed.

• All incoming data will be signed by the respective entity.

• Any data sent to a relying party will be encrypted.

• Protection against internal attacks with every record in DB protected with integrity.

• Centralized key management.

• All API's are protected with OAUTH 2.0.

Privacy by intent

Key privacy features:

• Minimal data with selective disclosure on a need-to-know basis.

• Sensitive data protected (not stored or logged in clear form).

• Consent support – the user decides who can receive what credentials & what attributes.

• No search on the database (You can find a record only if you know the ID).

• Clear segregation of Biometric & Demographic data.

• De-centralised ID usage and data (cannot profile based on usage).

• Users are not limited to one permenant ID - Virtual ID.

• All relying party gets a privacy enabled tokens to prevent profiling across transactions. Permenant ID is never shared.

• Supports Wallet based decentralized ID issuance and usage.

• Face data is not sent to ABIS for deduplication.

Overview

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

The ABIS system never learns about residents' identities. Any Personally Identifiable Information (PII), such as demographic details or an applicant's AID (application ID), is not shared with the ABIS system. Internally, MOSIP maintains a mapping between the ABIS-specific reference ID and the AID of the resident.

MOSIP-ABIS interface

ABIS must support the following types of biometric images:

• Individual fingerprint images (segmented)

• Iris images (left, right)

• Face image

Test kits

ABIS deployment

• It is recommended that ABIS be deployed in the same secure zone (military zone) where the registration processor is deployed.

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

Overview

The right to privacy is a fundamental right in many contexts. Privacy protection or preservation can be ensured in an application by adopting a privacy friendly design stance.

What is privacy and privacy protection?

Privacy takes many forms. From an identity system perspective, the confidentiality of identity information and anonymity when using the identity offers privacy.

MOSIP views the identity system as a custodian of the individual's data. This data has to be protected in order to protect the individual from privacy and security risks. Privacy protection measures include , transparency, user control, confidentiality, selective disclosure, user anonymity and intrusion protection.

Privacy design elements

MOSIP addresses privacy design at four levels.

1. Functional privacy

   • Selective disclosure

   • Anonymization

   • Need to know

   • Encryption

   • Tokenization

2. Security

   • Trusted applications

   • Access control

3. User centricity

   • User control

   • Consent

   • Usability

   • Inclusion

4. Transparency

   • Openness

   • Verifiability

   • Governance

The security of user data is given the highest priority in MOSIP. Data is protected in flight and rest using strong cryptographic techniques. All operations on decrypted data are done in memory.

Various flows with encryption are illustrated below. Refer to for all references of the type 'Kx' and 'KPx'.

Registration data flow

5. The UINs are hashed, encrypted and stored in uin the table of mosip_idrepo DB. (K7.4)

6. Biometrics are shared and encrypted with the ABIS partner's key (PK1).

7. Registration processor stores encrypted demographic data in mosip_regprc DB. (K11)

Datashare

Data shared with all partners like ABIS, Print, Adjudication, IDA etc. is encrypted using partners' public key. Note that IDA is also a partner, however, a special partner in the sense that data is additionally zero-knowledge encrypted before sending to IDA (see the section below).

Zero-knowledge encryption

Encryption and sharing by Credential Service

1. Generate master symmetric encryption key K9.

2. Generate a 10,000 symmetric keys pool (ZKn). Encrypt each ZKn with K9 and store it in DB. (K12)

3. Randomly select one key from ZKn, and decrypt using K9.

4. Derive new key ZKn' = ZKn + UIN/VID/APPID.

5. Encrypt biometric templates and demographics.

   • BIO = encrypt(bio/demo with ZKn').

6. Encrypt ZKn (this is done to share ZKn with IDA).

   • ZKn-IDA = encrypt(ZKn with K22)

7. Share the following with IDA:

   1. ZKn-IDA

   2. BIO

   3. Random index (0 - 9999)

   4. SHA-256 hash of UIN/VID/APPID

Decryption by IDA

1. Generate master symmetric encryption key K18.

2. Decrypt data in Step 8 above using PK8.

3. Decrypt ZKn-IDA with K22 to get ZKn.

4. Encrypt ZKn with K18 and store it at a random index.

5. Bio-data is stored as is.

ID authentication flow

2. The authentication client further encrypts the auth request with IDA-PARTNER public key.

Overview

The Foundational Trust Module (FTM) is created using a secure microprocessor capable of performing all required biometric processing and secure storage of keys. The foundational device trust would satisfy the below requirements.

• The module has the ability to securely generate, store, and process cryptographic keys.

• Generation of asymmetric and symmetric keys with TRNG.

• The module has the ability to protect keys from extraction.

• The module has to protect the keys from physical tampering, temperature, frequency, and voltage-related attacks.

• The module could withstand Hardware cloning.

• The module could withstand probing attacks

• The module provides memory segregation for cryptographic operations and protection against buffer overflow attacks

• The module provides the ability to withstand cryptographic side-channel attacks like Differential Power analysis attacks, and timing attacks.

• CAVP validated the implementation of the cryptographic algorithm.

• The module has the ability to perform a cryptographically valid, secure boot.

• The module has the ability to run trusted applications.

The foundational device trust derived from this module is used to enable trust-based computing for biometric capture. The foundational device trust module provides a trusted execution environment based on the following:

• Secure Boot

  • Ability to cryptographically verify code before execution.

  • Ability to check for integrity violations of the module or device.

  • Halt upon failure.

  • The ability to securely upgrade and perform forward-only upgrades to thwart downgrade attacks.

  • SHA256 hash equivalent or above should be used for all hashing requirements

  • All root of trust is provisioned upon first boot or before.

  • All upgrades would be considered successful only after a successful boot with proper hash and signature verification.

  • The boot should fail upon hash or signature failures and never operate in an intermediary state.

  • A maximum of 10 failed attempts should lock the upgrade process and brick the device. However, chip manufacturers can decide to be less than 10.

• Secure application

  • Ability to run applications that are trusted.

  • Protect against the downgrading of applications.

  • Isolated memory to support cryptographic operations.

  • All trust is anchored during the first boot and not modifiable.

Certification

The FTM should have at least one of the following certifications in each category to meet the given requirement.

Category: Cryptographic Algorithm Implementation

• CAVP (RSA, AES, SHA256, TRNG (DRBGVS), ECC)

Category: FTM Chip

(ONE of the following certifications)

• FIPS 140-2 L3 or above

• PCI PTS 5 or above (Pre-certified)

• PCI - PED 2.0 or above (Pre-Certified)

• One of the following Common Criteria (CC) certification

  • https://www.commoncriteriaportal.org/files/ppfiles/pp0035a.pdf

  • https://www.commoncriteriaportal.org/files/ppfiles/pp0084a_pdf.pdf

System/Device Level Tamper (optional)

System/Device Level Tamper Responsiveness is recommended (not mandatory). In this case, FTM should be capable of showcasing Tamper Responsiveness (keys must be erased) against a tamper at the system/device level.

Threats to Protect

The FTM should protect against the following threats.

• Hardware cloning attacks - Ability to protect against attacks that could result in a duplicate with keys.

• Hardware Tamper attacks

  • Physical tamper - No way to physically tamper and obtain its secrets.

  • Voltage & frequency related attacks - Should shield against voltage leaks and should prevent low voltage. The FTM should always be in either the state operational normally or inoperable. The FTM should never be operable when its input voltages are not met.

  • Temperature attacks on the crypto block - Low or High the FTM are expected to operate or reach an inoperable state. No state in between.

• Differential Power Analysis attack.

• Probing attacks - FTM should protect its surface area against any probe-related attacks.

• Segregation of memory for execution of cryptographic operation (crypto block should be protected from buffer overflow type attacks).

• Vulnerability of the cryptographic algorithm implementation.

• Attacks against secure boot & secure upgrade.

• TEE/Secure processor OS attack.

Foundational Trust Module Identity

Upon the FTM provider's approval by the MOSIP adopters, the FTM provider would submit a self-signed public certificate to the adopter. Let us call this the FTM root. The adopter would use this certificate to seed their device's trust database. The FTM root and their key pairs should be generated and stored in FIPS 140-2 Level 3 or more compliant devices with no possible mechanism to extract the keys. The foundational module upon its first boot is expected to generate a random asymmetric key pair and provide the public part of the key to obtain a valid certificate. The FTM provider would validate to ensure that the chip is unique and would issue a certificate with the issuer set to FTM root. The entire certificate issuance would be in a secured provisioning facility. Auditable upon notice by the adopters or its approved auditors. The certificate issued to the module will have a defined validity period as per the MOSIP certificate policy document defined by the MOSIP adopters. This certificate and private key within the FTM chip are expected to be in its permanent memory.

The FTM should have at least one of the following certifications in each category to meet the given requirement.

Secure Provisioning

Secure provisioning applies to both the FTM and the Device providers.

1. The devices and FTM should have a mechanism to protect against fraudulent attempts to create or replicate.

2. The device and FTM trust should be programmed in a secure facility which is certified by the respective MOSIP adopters.

3. The organization should have a mechanism to segregate the FTMs and Devices built for MOSIP using a cryptographically valid and repeatable process.

4. All debug options within the FTM or device should be disabled permanently

5. All key creations needed for provisioning should happen automatically using FIPS 140-2 Level 3 or higher devices. No individual or group or organization should have a mechanism to influence this behaviour.

6. Before the devices/FTM leaves the secure provisioning facility all the necessary trust should be established and should not be re-programmable.

Overview

Applications

• Registration Client.

• Backend quality check.

• Biometric authentication during onboarding (internal auth).

• ID Authentications.

Biometric SDK library

The library is used by Registration Client to perform 1:N match, segmentation, extraction etc. For more information on integration with Registration Client, refer to Registration Client Biometric SDK Integration Guide.

A simulation of this library is available as Mock BioSDK. The same is installed in the MOSIP sandbox.

Biometric SDK service

For 1:1 match and quality check of biometrics at the MOSIP backend, the BioSDK must be running as a service that can be accessed by Registration Processor and IDA Internal Services. The service exposes REST APIs specified here.

A simulation (mock) service has been provided. The mock service loads mock BioSDK internally on the startup and exposes the endpoints to perform 1:N match, segmentation, extraction as per IBioAPI.

The service may be packaged as a docker running inside MOSIP Kubernetes cluster or running separately on a server. It is important that the scalability of this service is taken care depending on the load on the system, i.e., the rate of enrolment and ID authentication.

API

1. BioSDK library: IBioAPI.

2. BioSDK service: TBD.

Testing kit

BioSDK server request/response may be tested using BioSDK testing kit.

Configuration

The following properties in application-default.properties needs to be updated to integrate the BioSDK library and service with MOSIP.

mosip.fingerprint.provider=io.mosip.kernel.bioapi.impl.BioApiImpl
mosip.face.provider=io.mosip.kernel.bioapi.impl.BioApiImpl
mosip.iris.provider=io.mosip.kernel.bioapi.impl.BioApiImpl
mosip.ida.biosdk-service.url=http://mock-biosdk-service.default:80
mosip.regproc.biosdk-service.url=http://mock-biosdk-service.default:80
mosip.idrepo.biosdk-service.url=http://mock-biosdk-service.default:80

Overview

Biometric devices capture individuals' biometric data (fingerprint, iris scan, photo) and send it to a registration client or authentication client (app). The functional architecture of the various entities involved is shown below.

Device types

* An adopter may choose to have different subtypes, however, the certification needs to be adhered to.

Enrolment flow

Authentication flow

SBI test kit

Devices calculator

The following calculator may be used to estimate the number of devices required for a rollout.

Partners

Providers of biometric devices are Partners of MOSIP and need to be onboarded to a given deployment of MOSIP. Specifically,

CBEFF

• Standards:

  • ISO 19785-3

  • OASIS patron format ISO/IEC JTC 1 SC 37 - biometrics

    • Patron identifier 257

    • Patron format identifier 11

  • OASIS Binary Data Block Format Identifiers for Format Type ISO/IEC JTC 1 SC 37-biometrics

    • Patron identifier 257

    • BDB patron format identifier

      • 7 for finger image

      • 2 for finger minutiae

      • 8 for face image

      • 9 for iris image

• MOSIP Schema is similar to OASIS Schema, with an optional attribute called others added from the LTS version.

• MOSIP's CBEFF Utils can be used to create and validate CBEFF XML data.

CBEFF Sample

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<BIR xmlns="http://standards.iso.org/iso-iec/19785/-3/ed-2/">
    <BIRInfo>
        <Integrity>false</Integrity>
    </BIRInfo>
    <BIR>
        <Version>
            <Major>1</Major>
            <Minor>1</Minor>
        </Version>
        <CBEFFVersion>
            <Major>1</Major>
            <Minor>1</Minor>
        </CBEFFVersion>
        <BIRInfo>
            <Integrity>false</Integrity>
        </BIRInfo>
        <BDBInfo>
            <Index>98293c98-7b64-4f9a-a209-9cadfd8e4a1e</Index>
            <Format>
                <Organization>Mosip</Organization>
                <Type>7</Type>
            </Format>
            <CreationDate>2022-07-27T15:29:22.987808900Z</CreationDate>
            <Type>Finger</Type>
            <Subtype>Left RingFinger</Subtype>
            <Level>Raw</Level>
            <Purpose>Enroll</Purpose>
            <Quality>
                <Algorithm>
                    <Organization>HMAC</Organization>
                    <Type>SHA-256</Type>
                </Algorithm>
                <Score>94</Score>
            </Quality>
        </BDBInfo>
        <BDB>RklSADAyMA\.....</BDB>
        <SB>ZXlKNE5XTWlP.....</SB>
        <others>
            <entry key="SPEC_VERSION">0.9.5</entry>
            <entry key="RETRIES">1</entry>
            <entry key="FORCE_CAPTURED">false</entry>
            <entry key="EXCEPTION">false</entry>
            <entry key="PAYLOAD">{"digitalId":"eyJ4NWMiOlsiTUlJR.....</entry>
            <entry key="SDK_SCORE">0.0</entry>
        </others>
    </BIR>
    <BIR>
        <Version>
            <Major>1</Major>
            <Minor>1</Minor>
        </Version>
        <CBEFFVersion>
            <Major>1</Major>
            <Minor>1</Minor>
        </CBEFFVersion>
        <BIRInfo>
            <Integrity>false</Integrity>
        </BIRInfo>
        <BDBInfo>
            <Index>511e3f9c-e6f4-46b3-bc6d-193a01c6ad67</Index>
            <Format>
                <Organization>Mosip</Organization>
                <Type>7</Type>
            </Format>
            <CreationDate>2022-07-27T15:29:22.987808900Z</CreationDate>
            <Type>Finger</Type>
            <Subtype>Left LittleFinger</Subtype>
            <Level>Raw</Level>
            <Purpose>Enroll</Purpose>
            <Quality>
                <Algorithm>
                    <Organization>HMAC</Organization>
                    <Type>SHA-256</Type>
                </Algorithm>
                <Score>94</Score>
            </Quality>
        </BDBInfo>
        <BDB>RklSADAyMA\.....</BDB>
        <SB>ZXlKNE5XTWlP.....</SB>
        <others>
            <entry key="SPEC_VERSION">0.9.5</entry>
            <entry key="RETRIES">1</entry>
            <entry key="FORCE_CAPTURED">false</entry>
            <entry key="EXCEPTION">false</entry>
            <entry key="PAYLOAD">{"digitalId":"eyJ4NWMiOlsiTUlJ.....</entry>
            <entry key="SDK_SCORE">0.0</entry>
        </others>
    </BIR>
    <BIR>
        <Version>
            <Major>1</Major>
            <Minor>1</Minor>
        </Version>
        <CBEFFVersion>
            <Major>1</Major>
            <Minor>1</Minor>
        </CBEFFVersion>
        <BIRInfo>
            <Integrity>false</Integrity>
        </BIRInfo>
        <BDBInfo>
            <Index>f9c11267-9018-44c2-a4d7-5bb1f1cf2555</Index>
            <Format>
                <Organization>Mosip</Organization>
                <Type>8</Type>
            </Format>
            <CreationDate>2022-07-27T15:29:22.988805100Z</CreationDate>
            <Type>Face</Type>
            <Subtype></Subtype>
            <Level>Raw</Level>
            <Purpose>Enroll</Purpose>
            <Quality>
                <Algorithm>
                    <Organization>HMAC</Organization>
                    <Type>SHA-256</Type>
                </Algorithm>
                <Score>94</Score>
            </Quality>
        </BDBInfo>
        <BDB>RklSADAyMA\.....</BDB>
        <SB>ZXlKNE5XTWlP.....</SB>
        <others>
            <entry key="SPEC_VERSION">0.9.5</entry>
            <entry key="RETRIES">1</entry>
            <entry key="FORCE_CAPTURED">false</entry>
            <entry key="EXCEPTION">false</entry>
            <entry key="PAYLOAD">{"digitalId":"eyJ4NWMiOlsiTUlJR.....</entry>
            <entry key="SDK_SCORE">0.0</entry>
        </others>
    </BIR>
    <BIR>
        <Version>
            <Major>1</Major>
            <Minor>1</Minor>
        </Version>
        <CBEFFVersion>
            <Major>1</Major>
            <Minor>1</Minor>
        </CBEFFVersion>
        <BIRInfo>
            <Integrity>false</Integrity>
        </BIRInfo>
        <BDBInfo>
            <Index>5d7669c1-1f7d-4810-9cd5-5521a38be151</Index>
            <Format>
                <Organization>Mosip</Organization>
                <Type>7</Type>
            </Format>
            <CreationDate>2022-07-27T15:29:22.988805100Z</CreationDate>
            <Type>Finger</Type>
            <Subtype>Right RingFinger</Subtype>
            <Level>Raw</Level>
            <Purpose>Enroll</Purpose>
            <Quality>
                <Algorithm>
                    <Organization>HMAC</Organization>
                    <Type>SHA-256</Type>
                </Algorithm>
                <Score>94</Score>
            </Quality>
        </BDBInfo>
        <BDB>RklSADAyMA\.....</BDB>
        <SB>ZXlKNE5XTWlP.....</SB>
        <others>
            <entry key="SPEC_VERSION">0.9.5</entry>
            <entry key="RETRIES">1</entry>
            <entry key="FORCE_CAPTURED">false</entry>
            <entry key="EXCEPTION">false</entry>
            <entry key="PAYLOAD">{"digitalId":"eyJ4NWMiOlsiTUlJR.....</entry>
            <entry key="SDK_SCORE">0.0</entry>
        </others>
    </BIR>
    <BIR>
        <Version>
            <Major>1</Major>
            <Minor>1</Minor>
        </Version>
        <CBEFFVersion>
            <Major>1</Major>
            <Minor>1</Minor>
        </CBEFFVersion>
        <BIRInfo>
            <Integrity>false</Integrity>
        </BIRInfo>
        <BDBInfo>
            <Index>db6f289e-fb86-4c0d-818e-2fa709660caf</Index>
            <Format>
                <Organization>Mosip</Organization>
                <Type>9</Type>
            </Format>
            <CreationDate>2022-07-27T15:29:22.988805100Z</CreationDate>
            <Type>Iris</Type>
            <Subtype>Left</Subtype>
            <Level>Raw</Level>
            <Purpose>Enroll</Purpose>
            <Quality>
                <Algorithm>
                    <Organization>HMAC</Organization>
                    <Type>SHA-256</Type>
                </Algorithm>
                <Score>94</Score>
            </Quality>
        </BDBInfo>
        <BDB>RklSADAyMA\.....</BDB>
        <SB>ZXlKNE5XTWlP.....</SB>
        <others>
            <entry key="SPEC_VERSION">0.9.5</entry>
            <entry key="RETRIES">1</entry>
            <entry key="FORCE_CAPTURED">false</entry>
            <entry key="EXCEPTION">false</entry>
            <entry key="PAYLOAD">{"digitalId":"eyJ4NWMiOlsiTUlJRjlqQ.....</entry>
            <entry key="SDK_SCORE">0.0</entry>
        </others>
    </BIR>
    <BIR>
        <Version>
            <Major>1</Major>
            <Minor>1</Minor>
        </Version>
        <CBEFFVersion>
            <Major>1</Major>
            <Minor>1</Minor>
        </CBEFFVersion>
        <BIRInfo>
            <Integrity>false</Integrity>
        </BIRInfo>
        <BDBInfo>
            <Index>a60f8367-0818-40de-b935-405bc6d0f810</Index>
            <Format>
                <Organization>Mosip</Organization>
                <Type>7</Type>
            </Format>
            <CreationDate>2022-07-27T15:29:22.988805100Z</CreationDate>
            <Type>Finger</Type>
            <Subtype>Left IndexFinger</Subtype>
            <Level>Raw</Level>
            <Purpose>Enroll</Purpose>
            <Quality>
                <Algorithm>
                    <Organization>HMAC</Organization>
                    <Type>SHA-256</Type>
                </Algorithm>
                <Score>94</Score>
            </Quality>
        </BDBInfo>
        <BDB>RklSADAyMA\.....</BDB>
        <SB>ZXlKNE5XTWlP.....</SB>
        <others>
            <entry key="SPEC_VERSION">0.9.5</entry>
            <entry key="RETRIES">1</entry>
            <entry key="FORCE_CAPTURED">false</entry>
            <entry key="EXCEPTION">false</entry>
            <entry key="PAYLOAD">{"digitalId":"eyJ4NWMiOlsiTUlJR\.....</entry>
            <entry key="SDK_SCORE">0.0</entry>
        </others>
    </BIR>
    <BIR>
        <Version>
            <Major>1</Major>
            <Minor>1</Minor>
        </Version>
        <CBEFFVersion>
            <Major>1</Major>
            <Minor>1</Minor>
        </CBEFFVersion>
        <BIRInfo>
            <Integrity>false</Integrity>
        </BIRInfo>
        <BDBInfo>
            <Index>b1dd9bef-0e19-42e3-b0ba-0ded02ef429b</Index>
            <Format>
                <Organization>Mosip</Organization>
                <Type>7</Type>
            </Format>
            <CreationDate>2022-07-27T15:29:22.988805100Z</CreationDate>
            <Type>Finger</Type>
            <Subtype>Right IndexFinger</Subtype>
            <Level>Raw</Level>
            <Purpose>Enroll</Purpose>
            <Quality>
                <Algorithm>
                    <Organization>HMAC</Organization>
                    <Type>SHA-256</Type>
                </Algorithm>
                <Score>94</Score>
            </Quality>
        </BDBInfo>
        <BDB>RklSADAyMA\.....</BDB>
        <SB>ZXlKNE5XTWlP.....</SB>
        <others>
            <entry key="SPEC_VERSION">0.9.5</entry>
            <entry key="RETRIES">1</entry>
            <entry key="FORCE_CAPTURED">false</entry>
            <entry key="EXCEPTION">false</entry>
            <entry key="PAYLOAD">{"digitalId":"eyJ4NWMiOlsiTUlJR.....</entry>
            <entry key="SDK_SCORE">0.0</entry>
        </others>
    </BIR>
    <BIR>
        <Version>
            <Major>1</Major>
            <Minor>1</Minor>
        </Version>
        <CBEFFVersion>
            <Major>1</Major>
            <Minor>1</Minor>
        </CBEFFVersion>
        <BIRInfo>
            <Integrity>false</Integrity>
        </BIRInfo>
        <BDBInfo>
            <Index>ee0508b6-f42b-4a88-887b-10d71bc10ea0</Index>
            <Format>
                <Organization>Mosip</Organization>
                <Type>7</Type>
            </Format>
            <CreationDate>2022-07-27T15:29:22.988805100Z</CreationDate>
            <Type>Finger</Type>
            <Subtype>Right LittleFinger</Subtype>
            <Level>Raw</Level>
            <Purpose>Enroll</Purpose>
            <Quality>
                <Algorithm>
                    <Organization>HMAC</Organization>
                    <Type>SHA-256</Type>
                </Algorithm>
                <Score>94</Score>
            </Quality>
        </BDBInfo>
        <BDB>RklSADAyMA\.....</BDB>
        <SB>ZXlKNE5XTWlP.....</SB>
        <others>
            <entry key="SPEC_VERSION">0.9.5</entry>
            <entry key="RETRIES">1</entry>
            <entry key="FORCE_CAPTURED">false</entry>
            <entry key="EXCEPTION">false</entry>
            <entry key="PAYLOAD">{"digitalId":"eyJ4NWMiOlsiTUlJR.....</entry>
            <entry key="SDK_SCORE">0.0</entry>
        </others>
    </BIR>
    <BIR>
        <Version>
            <Major>1</Major>
            <Minor>1</Minor>
        </Version>
        <CBEFFVersion>
            <Major>1</Major>
            <Minor>1</Minor>
        </CBEFFVersion>
        <BIRInfo>
            <Integrity>false</Integrity>
        </BIRInfo>
        <BDBInfo>
            <Index>614fb188-81c1-4190-af52-050a54fc31b5</Index>
            <Format>
                <Organization>Mosip</Organization>
                <Type>9</Type>
            </Format>
            <CreationDate>2022-07-27T15:29:22.988805100Z</CreationDate>
            <Type>Iris</Type>
            <Subtype>Right</Subtype>
            <Level>Raw</Level>
            <Purpose>Enroll</Purpose>
            <Quality>
                <Algorithm>
                    <Organization>HMAC</Organization>
                    <Type>SHA-256</Type>
                </Algorithm>
                <Score>94</Score>
            </Quality>
        </BDBInfo>
        <BDB>RklSADAyMA\.....</BDB>
        <SB>ZXlKNE5XTWlP.....</SB>
        <others>
            <entry key="SPEC_VERSION">0.9.5</entry>
            <entry key="RETRIES">1</entry>
            <entry key="FORCE_CAPTURED">false</entry>
            <entry key="EXCEPTION">false</entry>
            <entry key="PAYLOAD">{"digitalId":"eyJ4NWMiOlsiTUlJR.....</entry>
            <entry key="SDK_SCORE">0.0</entry>
        </others>
    </BIR>
    <BIR>
        <Version>
            <Major>1</Major>
            <Minor>1</Minor>
        </Version>
        <CBEFFVersion>
            <Major>1</Major>
            <Minor>1</Minor>
        </CBEFFVersion>
        <BIRInfo>
            <Integrity>false</Integrity>
        </BIRInfo>
        <BDBInfo>
            <Index>971a3c27-aa02-4041-b8d8-52b402d30cd9</Index>
            <Format>
                <Organization>Mosip</Organization>
                <Type>8</Type>
            </Format>
            <CreationDate>2022-07-27T15:29:22.988805100Z</CreationDate>
            <Type>ExceptionPhoto</Type>
            <Subtype></Subtype>
            <Level>Raw</Level>
            <Purpose>Enroll</Purpose>
            <Quality>
                <Algorithm>
                    <Organization>HMAC</Organization>
                    <Type>SHA-256</Type>
                </Algorithm>
                <Score>94</Score>
            </Quality>
        </BDBInfo>
        <BDB>RklSADAyMA\.....</BDB>
        <SB>ZXlKNE5XTWlP.....</SB>
        <others>
            <entry key="SPEC_VERSION">0.9.5</entry>
            <entry key="RETRIES">1</entry>
            <entry key="FORCE_CAPTURED">false</entry>
            <entry key="EXCEPTION">false</entry>
            <entry key="PAYLOAD">{"digitalId":"eyJ4NWMiOlsiTUlJR.....</entry>
            <entry key="SDK_SCORE">0.0</entry>
        </others>
    </BIR>
    <BIR>
        <Version>
            <Major>1</Major>
            <Minor>1</Minor>
        </Version>
        <CBEFFVersion>
            <Major>1</Major>
            <Minor>1</Minor>
        </CBEFFVersion>
        <BIRInfo>
            <Integrity>false</Integrity>
        </BIRInfo>
        <BDBInfo>
            <Index>7ad51076-4d10-4f83-92a4-3954e6797355</Index>
            <Format>
                <Organization>Mosip</Organization>
                <Type>7</Type>
            </Format>
            <CreationDate>2022-07-27T15:29:22.988805100Z</CreationDate>
            <Type>Finger</Type>
            <Subtype>Right MiddleFinger</Subtype>
            <Level>Raw</Level>
            <Purpose>Enroll</Purpose>
            <Quality>
                <Algorithm>
                    <Organization>HMAC</Organization>
                    <Type>SHA-256</Type>
                </Algorithm>
                <Score>94</Score>
            </Quality>
        </BDBInfo>
        <BDB>RklSADAyMA\.....</BDB>
        <SB>ZXlKNE5XTWlP.....</SB>
        <others>
            <entry key="SPEC_VERSION">0.9.5</entry>
            <entry key="RETRIES">1</entry>
            <entry key="FORCE_CAPTURED">false</entry>
            <entry key="EXCEPTION">false</entry>
            <entry key="PAYLOAD">{"digitalId":"eyJ4NWMiOlsiTUlJR.....</entry>
            <entry key="SDK_SCORE">0.0</entry>
        </others>
    </BIR>
    <BIR>
        <Version>
            <Major>1</Major>
            <Minor>1</Minor>
        </Version>
        <CBEFFVersion>
            <Major>1</Major>
            <Minor>1</Minor>
        </CBEFFVersion>
        <BIRInfo>
            <Integrity>false</Integrity>
        </BIRInfo>
        <BDBInfo>
            <Index>b055cbde-925b-47b3-bab6-070a57c1a916</Index>
            <Format>
                <Organization>Mosip</Organization>
                <Type>7</Type>
            </Format>
            <CreationDate>2022-07-27T15:29:22.988805100Z</CreationDate>
            <Type>Finger</Type>
            <Subtype>Left MiddleFinger</Subtype>
            <Level>Raw</Level>
            <Purpose>Enroll</Purpose>
            <Quality>
                <Algorithm>
                    <Organization>HMAC</Organization>
                    <Type>SHA-256</Type>
                </Algorithm>
                <Score>94</Score>
            </Quality>
        </BDBInfo>
        <BDB>RklSADAyMA\.....</BDB>
        <SB>ZXlKNE5XTWlP.....</SB>
        <others>
            <entry key="SPEC_VERSION">0.9.5</entry>
            <entry key="RETRIES">1</entry>
            <entry key="FORCE_CAPTURED">false</entry>
            <entry key="EXCEPTION">false</entry>
            <entry key="PAYLOAD">{"digitalId":"eyJ4NWMiOlsiTUlJR.....</entry>
            <entry key="SDK_SCORE">0.0</entry>
        </others>
    </BIR>
    <BIR>
        <Version>
            <Major>1</Major>
            <Minor>1</Minor>
        </Version>
        <CBEFFVersion>
            <Major>1</Major>
            <Minor>1</Minor>
        </CBEFFVersion>
        <BIRInfo>
            <Integrity>false</Integrity>
        </BIRInfo>
        <BDBInfo>
            <Index>02c43091-fe1e-4b6f-acae-e2cb59c1ed9b</Index>
            <Format>
                <Organization>Mosip</Organization>
                <Type>7</Type>
            </Format>
            <CreationDate>2022-07-27T15:29:22.988805100Z</CreationDate>
            <Type>Finger</Type>
            <Subtype>Right Thumb</Subtype>
            <Level>Raw</Level>
            <Purpose>Enroll</Purpose>
            <Quality>
                <Algorithm>
                    <Organization>HMAC</Organization>
                    <Type>SHA-256</Type>
                </Algorithm>
                <Score>0</Score>
            </Quality>
        </BDBInfo>
        <SB></SB>
        <others>
            <entry key="SPEC_VERSION"></entry>
            <entry key="RETRIES">0</entry>
            <entry key="FORCE_CAPTURED">false</entry>
            <entry key="EXCEPTION">true</entry>
            <entry key="PAYLOAD"></entry>
            <entry key="SDK_SCORE">0.0</entry>
        </others>
    </BIR>
    <BIR>
        <Version>
            <Major>1</Major>
            <Minor>1</Minor>
        </Version>
        <CBEFFVersion>
            <Major>1</Major>
            <Minor>1</Minor>
        </CBEFFVersion>
        <BIRInfo>
            <Integrity>false</Integrity>
        </BIRInfo>
        <BDBInfo>
            <Index>5b6e49c6-3a18-4ced-a931-d905860343fd</Index>
            <Format>
                <Organization>Mosip</Organization>
                <Type>7</Type>
            </Format>
            <CreationDate>2022-07-27T15:29:22.988805100Z</CreationDate>
            <Type>Finger</Type>
            <Subtype>Left Thumb</Subtype>
            <Level>Raw</Level>
            <Purpose>Enroll</Purpose>
            <Quality>
                <Algorithm>
                    <Organization>HMAC</Organization>
                    <Type>SHA-256</Type>
                </Algorithm>
                <Score>0</Score>
            </Quality>
        </BDBInfo>
        <SB></SB>
        <others>
            <entry key="SPEC_VERSION"></entry>
            <entry key="RETRIES">0</entry>
            <entry key="FORCE_CAPTURED">false</entry>
            <entry key="EXCEPTION">true</entry>
            <entry key="PAYLOAD"></entry>
            <entry key="SDK_SCORE">0.0</entry>
        </others>
    </BIR>
</BIR>

Overview

The admin application is a web-based application used by a privileged group of administrative personnel to manage various master data. The various resources that can be managed by an administrator are:

• Center (Registration centers)

• Device

• Machine

• User (Admin, Registration staff)

Along with resource and data management, the admin can generate master keys, check registration status, retrieve lost RIDs, and resume processing of paused packets.

• Masterdata Service exposes API to perform CRUD operations on masterdata through Admin service.

• Hotlist Service provides functionality to block/unblock any IDs with option of expiry. This hotlisted information will also be published to MOSIP_HOTLIST WebSub topic.

• Sync Data Service can be accessed only by the privileged group of admin personnel and enables default configurations and seed data to be setup when the MOSIP platform gets initialized.

The admin module has four services:

• Admin service

• Kernel Masterdata service

• Kernel Syncdata service

• Hotlist service

The documentation here will guide you through the pre-requisites required for the developer' setup.

Software setup

1. JDK 11

2. Any IDE (like Eclipse, IntelliJ IDEA)

3. Apache Maven (zip folder)

4. pgAdmin

5. Postman

6. Git/GitHub Desktop

7. Notepad++ (optional)

8. lombok.jar (file)

9. settings.xml

Follow the steps below to set up Admin Services on your local system:

1. Download lombok.jar and settings.xml.

2. Unzip Apache Maven and move the unzipped folder in C:\Program Files and settings.xml to conf folder C:\Program Files\apache-maven-3.8.4\conf.

3. Install Eclipse, open the lombok.jar file and wait for some time until it completes the scan for Eclipse IDE and then click Install/ Update.

1. Check the Eclipse installation folder C:\Users\userName\eclipse\jee-2021-12\eclipse to see if the lombok.jar is added. By doing this, you don't have to add the dependency of lombok in your pom.xml file separately as it is auto-configured by Eclipse.

2. Configure the JDK (Standard VM) with your Eclipse by traversing through Preferences → Java → Installed JREs.

Code setup

For the code setup, clone admin-services repository and follow the guidelines mentioned in the Code Contributions.

Importing and building of a project

1. Open the project folder where pom.xml is present.

2. Open command prompt from the same folder.

3. Run the command mvn clean install -Dgpg.skip=true -DskipTests=true to build the project and wait for the build to complete successfully.

4. After building of a project, open Eclipse and select Import Projects → Maven → Existing Maven Projects → Next → Browse to project directory → Finish.

5. After successful importing of project, update the project by right-click on Project → Maven → Update Project.

Environment setup

1. For the environment setup, you need an external JAR that is available here with different versions. (E.g.: You can download kernel-auth-adapter.jar and add to project Libraries → Classpath → Add External JARs → Select Downloaded JAR → Add → Apply and Close).

1. Clone admin-services repository.

2. Any changes in the properties for Masterdata and Admin services should be done in application-local1.properties file.

3. By default the Admin-services is connected to dev environment.

4. To run the specific service from IDE, Open IDE -> Specific service -> src/main/java/io.mosip.specific service -> Right click on the file and select run as Java Application.

For example, to run the Admin service, open IDE -> admin-service -> src/main/java/io.mosip.admin -> Right click on AdminBootApplication.java and select run as Java Application.

1. To run the specific service from Command Prompt, Open Project folder -> open command prompt from same folder -> Execute java -jar target/specific-service-1.2.0.jar.

For example, to run the admin service, Open Project folder -> open command prompt from same folder -> Execute java -jar target/admin-service-1.2.0-SNAPSHOT.jar.

The service should now be up and running.

Admin services API

• For API documentation, refer here.

• The APIs can be tested with the help of Swagger-UI and Postman.

• Swagger is an interface description language for describing restful APIs expressed using JSON. You can access Swagger-UI of admin-services for dev-environment from:

Admin service– http://dev.mosip.net/v1/admin/swagger-ui/index.html?configUrl=/v1/admin/v3/api-docs/swagger-config#/ and localhost from http://localhost:8098/v1/admin/swagger-ui/index.html?configUrl=/v1/admin/v3/api-docs/swagger-config#/.

Masterdata- http://dev.mosip.net/v1/masterdata/swagger-ui/index.html?configUrl=/v1/masterdata/v3/api-docs/swagger-config#/ and localhost from http://localhost:8086/v1/masterdata/swagger-ui/index.html?configUrl=/v1/masterdata/v3/api-docs/swagger-config#/.

Syncdata- http://dev.mosip.net/v1/syncdata/swagger-ui/index.html?configUrl=/v1/syncdata/v3/api-docs/swagger-config#/ and localhost from http://localhost:8089/v1/syncdata/swagger-ui/index.html?configUrl=/v1/syncdata/v3/api-docs/swagger-config#/.

Hotlist- http://dev.mosip.net/v1/hotlist/swagger-ui/index.html?configUrl=/v1/hotlist/v3/api-docs/swagger-config#/ and localhost from http://localhost:8095/v1/hotlist/swagger-ui/index.html?configUrl=/v1/hotlist/v3/api-docs/swagger-config#/

• Postman is an API platform for building and using APIs. Postman simplifies each step of the API lifecycle and streamlines collaboration so you can create better APIs—faster. It is widely used tool for API testing.

• Create an environment as shown in the image below.

This environment is created for dev. Give the variable name as url and set both the values as https://dev.mosip.net.

• In the similar way, create another environment for localhost as shown below.

This environment is created for localhost. Give the variable name as url and set both the values as http://localhost:8099.

Overview

The MOSIP platform is configured via the Admin application. This application can be accessed only by a privileged group of administration personnel. The admin module provides the following functions:

1. Management of resources via CRUD operations:

   1. Zone

   2. Centers (registration centers)

   3. Device

   4. Machine

   5. Users (Admin, registration staff)

2. Registration administration

   1. Packet status

   2. Retrieve lost RID

   3. Resume RID

Administrative zones

• Administrative zones are virtual boundaries which a country can define to better manage their resources that are used during registrations. These resources includes Centers, Users, Machines and Devices. These zones can be defined in a hierarchical fashion and a country can allocate resources to such zones based on their requirements.

• Resources under each zone is managed by a Zonal Admin. This is done by assigning an Administrative zone to the Zonal Admin during user creation.

• These Zonal Admins can exist at any zonal hierarchy. (For e.g, a Zonal Admin can directly be mapped to the whole country as a Zone or can be mapped to a significantly smaller zone such as a city). Thus, these resources when mapped to an Administrative zone can only be managed by the Admin of that zone.

Activate/deactivate/decommission resources

What is deactivation of a resource?

Deactivation refers to a temporary shutdown. This means that the resource will not be available for use unless and until it is activated later through the admin portal as required by the country.

What is decommissioning a resource?

• Decommission refers to a permanent shut down of the resource. This also automatically deactivates it.

• The primary difference being that a decommissioned resource cannot be bought into commission again as decommission refers to a permanent shutdown.

• Also, in cases where a center has some resources mapped to it (e.g. machines, devices or users), the portal will not allow the admin to decommission such a center.

Note- Activation/Deactivation/Decommission of a center in one language will be applied to the same center created in all the languages.

Services

Frontend- Admin portal

Developer Guide

API

Source code

Overview

Admin application is a web-based application used by a privileged group of administrative personnel to manage various master data. The various resources that can be managed by an Admin are:

1. Center (Registration centers)

2. Device

3. Machine

4. Users (Admin, Registration staff)