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.
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.
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
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.
From the above set of roles, only the application user is specific to a module. The other users are common and need to be created per PostgreSQL DB instance.
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.
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
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.
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 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
The database names will follow the below naming convention mosip_(abbreviated value of the module name)
Ex: mosip_prereg
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
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.
Indexes are named as idx_(table-alias)_(column-abbreviation)
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
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.
The following acronyms are used in the data model
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.
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
Databases inventory in MOSIP.
Attribute | Attribute Description | Type | Size |
---|---|---|---|
Abbreviation | Description | Abbreviation | Description | |
---|---|---|---|---|
Sl No | Database Name | Schema Name | Description |
---|---|---|---|
vid
Virtual ID
character varying
36
uin
Unique Identification Number-Encrypted
character varying
500
reg_id
Registration ID
character varying
39
_code
Code
character varying
64
_descr
Description
character varying
256
_type
Type
character varying
128
_name
Name
character varying
128
_id
Identification Code / Number
character varying
36
_addr_line
address line
character varying
256
_loc_line
location line
character varying
128
country
country
character varying
64
pin
pin
character varying
16
_comment / _remarks
Comments / remarks captured as part of a transaction
character varying
1024
count
smallint
_by
character varying
256
ref_id
Reference id
character varying
64
ref_id_type
Reference ID Type
character varying
64
is_active
boolean
cr_by
character varying
256
cr_dtimes
timestamp
upd_by
character varying
256
upd_dtimes
timestamp
is_deleted
boolean
del_dtimes
timestamp
ack
Acknowledgement
active
Active
addr
Address
autn
Authentication
bio
Biometric
cd
Code
cr
Created
del
Deleted
demo
Demographic
descr
Description
dob
Date of Birth
dt
Date
dtime
Date Time
dtimes
Date Timestamp
expiry
Expiry
fk
Foreign Key
ibio
Individual Biometric
id
Identifier
ida
Identity and authentication
idem
Individual Demographic
idsvr
ID Issuance Server
idsw
ID Issuance Software
Idx
Index
ins
Insert
ip
IP Address
lang
Language
last
Last
lh
Left Hand
lst
List
mref
Master Reference
msg
Message
mstr
Master
ntv
Native
nxt
Next
otp
One Time Password
parent
Parent
pct
Percentage
pk
Primary Key
pkt
Packet
preid
Pre ID Issuance
prev
Previous
pwd
Password
rcvd
Received
regn
Registration
remark
Remarks
rh
Right Hand
seq
Sequence
status
Status
tkn
Token
total
Total
trn
Transaction
ttyp
Transaction Type
typ
Type
uin
Unique Identification Number
upd
Update
usrl
User Login
vid
Virtual ID
wfl
Workflow
audit
Audit
dtimesz
Date Timestamp with Time Zone.
kernel
Kernel
reg
Registration
regprc
Registration Processor
prereg
Pre Registration
1
mosip_kernel
kernel
Kernel database store security key details, data related to kernel services like sync process, OTP, etc.
2
mosip_master
master
All the master data defined by a country / organization is maintained in mosip_master database.
3
mosip_idrepo
idrepo
ID repository database stores all the data related to an individual for which an UIN is generated.
4
mosip_prereg
prereg
Pre-registration database to store the data that is captured as part of pre-registration process and appointments booking.
5
mosip_reg
reg
Registration client database to capture registration related data. The needed data from MOSIP system will be synched with this database.
6
mosip_regprc
regprc
The data related to Registration process flows and transaction will be maintained in this database.
7
mosip_ida
ida
ID Authentication related requests, transactions will be stored in this database
8
mosip_audit
audit
Audit related logs collected from all modules are stored in this database
9
mosip_credential
credential
Credential request from MOSIP applications related entities and its data is stored in this database
10
mosip_idmap
idmap
Database to store and manage all the data related to mapping between various IDs, like vid with UIN of an individual
11
mosip_keymgr
keymgr
Key Manager database maintains common system configurations, data related to key services like encryption, decryption keys, certificates..etc
12
mosip_regdevice
regdevice
Database to store all registration device management data, look-up data, configuration data, metadata...etc.
13
mosip_authdevice
authdevice
Database to store all partner authentication device management data, look-up data, configuration data, metadata...etc
14
mosip_pms
pms
Partner Management Service related entities and its data is stored in this database