ID Schema is a standard JSON schema that defines data fields set to be captured from a resident. It is recommended that the number of fields is kept to a usable minimum in order to avoid profiling, minimize errors during data capture and avoid transactional fields.
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.
ID schema is loaded as a part of master data to
identity_schemathe table in
This guide is intended for adopters who would customize the default ID Schema to suit the needs of a specific deployment.
- Field: Unit of data collected from residents (eg.
- Field attribute: Qualification of Field (eg.
- Definition: Custom data types are defined for collecting different types of data:
simpleType: Multiple languages.
documentType: Document metadata.
none: Cannot be used for any purpose. But will be stored in id.json (default subpacket).
pvt: Private information, can be used only auth.
kyc: Information that can be disclosed to partners including IDA.
evidence: Field is treated as proof and may be subjected to removal.
optional: Field is treated as proof and will be removed after a predefined interval (defined as policy).
type: Validation engine type
arguments: Array to hold parameter or dependent field IDs required for validation.
- For every
document category codemust be the value of this key. This document category code is used to validate the provided document types in the ID object.
If any changes are made to the default ID Schema, make sure the following dependencies are updated as well:
ID Schema is identified based on its version in the MOSIP system. On publishing of ID Schema, the schema is versioned. Every ID Object stores the ID Schema version which is validated during ID Object validation.