UI specification helps us identify how the data in an ID attribute (attributes of an ID object) is going to be retrieved from the UI. The UI screens in registration client application and pre-registration application are rendered using their respective UI specification JSON. We have different UI Specifications for Registration Client & Pre-registration which is derived from the ID Schema. Here we would be discussing about the properties used in the UI specification of Registration Client.
Registration Client UI Specification
Here is one of the attributes in the Registration Client UI Specification.
Below are the properties in registration client UI specification that are used to store ID attributes in an ID object.
ID
The id property is the unique id provided to a fields to uniquely identify it. The fields can be alpha-numeric without any spaces between them.
Description
This is a non-mandatory property used to describe the ID attribute.
Label
This property defines label name to be used in UI. The label has sub attributes as primary and secondary to store data in primary language and secondary language based on the country's configuration.
Type
This property defines the field value type for the attribute. MOSIP supports primitive as well as user defined types.
Currently MOSIP supports the below data types, any MOSIP adopter can choose to define their own data types.
string
number
integer
simpleType
documentType
biometricType
Below are the definitions of the user defined data types currently being used in MOSIP.
This property is applicable for only number fields to add UI level validation for minimum value.
Maximum
Similar to minimum, this property is applicable to only number fields to add UI level validation for maximum value. It is applicable only if the value is greater than zero.
Control Type
This property defines what kind of UI component to be used to capture data in UI. Currently the values that can be used are:
textbox
dropdown
dob
fileupload
Field Type
This property identifies if the ID attribute is country specific (specified as dynamic) or is already defined in the platform (specified as default).
Format
This property is used to add a simple validation in the UI level.
Currently, the allowed values here are
lowercased - To validate if the data entered by the user is in lower case
uppercased - To validate if the data entered by the user is in upper case
MOSIP adopter can choose to add more values for different types of validations.
Field Category
This property defines where the ID attributes will be placed in packet structure. Currently, the new packet structure has three parts; private, evidence and optional. For more details on packet structure please go through our documentation on Registration Packet.
Input Required
This is a mandatory property which decides if the input is to be provided from the UI or not. Items which are marked as true will be validated using the ID object validator.
Validator
This property enables us to add a the list of validators for the ID attribute. Each validator will have the below fields,
Currently, regex is supported by MOSIP, the adopter can choose to add various types of validators.
Bio Attributes
This property contains the list of biometric attributes that can be captured by the ID attributes which have type "biometricType".
leftEye
rightEye
rightIndex
rightLittle
rightRing
rightMiddle
leftIndex
leftLittle
leftRing
leftMiddle
leftThumb
rightThumb
face
For various ID attribute there are different rules to capture biometrics,
individualBiometrics - all the biometrics needs to be captured here if the resident is not an child
individualAuthBiometrics - only one biometric is needed for authentication
parentOrGuardianBiometrics - only one biometric is needed for authentication
Required On
This property contains a list of rules which decides if the attribute is mandatory or not. It has additional fields, engine and expr which are used to specify the rule engine and the expression.
This expression states that, individual biometric authentication capture is madatory when,
the resident is not child
the resident has come for update
the resident is not updating his/her biometrics
the guardian of the resident is not providing his/her biometrics
Which means, the applicant is an adult applicant who has come to the registration center to update only his/her demographics details, so we must capture his/her biometrics for authentication.
Sub type
This property helps the system to uniquely identify a attribute if we are not able to identify it using the type.
Example: In individualBiometrics, individualAuthBiometrics and parentOrGuardianBiometrics the types are same i.e. biometricType; hence to uniquely identify them we created sub types such as applicant, applicant-auth and introducer respectively.
Contact Type
This property is used to identify the contact attributes. Here we have categorized the contact types into three categories, i.e. email, phone and postal (all the postal address related items).
Group
This property is used to group the ID attributes so that we can select them in the update screen.
Examples:
We have grouped all the address items as "Location", so that the resident needs to just select the group to update, i.e. the Location and in update screen he/she would be able to update all the location attributes.
ID attributes related to Parent or Guardian are grouped together as "GuardianDetails".
Required
This is a mandatory property which is needed to identify if the ID attribute is mandatory or not.
The above attributes which are available in the current MOSIP platform, adopters can choose to add new attributes or remove attributes based on their requirement.
Steps to create your own UI specification
Create the basic ID Object definition & ID Schema as per your requirement.
If any of your attributes needs pre-defined master data (example: Blood Group)
The adopters can use our Dynamic Fields API to create dynamic master data
Then the adopter can add this field in the UI specification and mark the field type as dynamic
Once all the attributes are added, the adopter can create the UI Specification for registration client using the ID Schema APIs.
Once the UI Specification is created it needs to be published. Once published, the ID schema version is updated & an ID Schema is generated from the registration client UI specification for verification.
The adopters now can verify the structure of the ID schema derived against the one that they had defined earlier & make modifications as required.