Partners in MOSIP are created in a self-service mode. The partner visit the MOSIP partner management portal and requests for collaborating with MOSIP by providing basic details such as organization name & email id, purpose of registration (how they want to collaborate with MOSIP - as a device provider, authentication partner, print partner, etc), basic credentials and performing an OTP based verification.
Once these details are filled by the partner and a request is sent to MOSIP, the Partner Admin verifies the details of the partners and allows the partner to integrate with MOSIP.
Once the partner is registered in MOSIP and is able to login to the partner management portal, MOSIP provides basic features such as,
Adding more contact information
Viewing user details
Managing credentials
The device providers is one who partners with MOSIP to provide MOSIP complaint devices for authentication and registration.
A device provider needs to upload his/her certificate using which he/she would be generating their device keys. These certificates are verified by MOSIP. Once the verification is done the root for these certificates are changed to MOSIP and can be downloaded back by the partner.
A device provider needs to upload a single certificate for all his/her devices.
This certificate needs to be upto date in MOSIP system before anyone performs any authentication using the device. During authentication, MOSIP would verify the device certificate using which the device info in authentication request is signed.
Using the partner management portal a device provider can add, update or view their device model details. Once the device provider registers the model details a request is sent to the partner admin for approval of the model.
During device registration MOSIP verifies the make and model detials. If a model details for a device is not available or approved by the partner admin, then registration for that device would fail.
Using the partner management portal a device provider can add, update or view their device model details. Once the device provider registers the SBI details a request is sent to the partner admin for approval of the SBI.
The foundational trust providers is one who partners with MOSIP to provide MOSIP complaint foundational trust modules (chips) for authentication devices.
Using the partner management portal a foundational trust provider can add, update or view their chip model details. Once the partner registers the model details a request is sent to the partner admin for approval of the model. As part of registration of the chip model, the partner needs to upload an associated certificate which would be used to generate keys for the particular type of chip.
The chip key will be used to sign the digital id in the authentication request. So, when the auth request reaches MOSIP, MOSIP would verify the certificate using which the digital id is signed.
The authentication partner is one who partners with MOSIP to provide authentication services to individuals.
An authentication partner need to upload an encryption & a signatire certificates using the partner management poratl. The signature certificate will be used in MOSIP to verify the signature when any request is received from the partner; where as, the encryption certificate would be used when any PII data is sent to the partner during e-KYC.
The authentication partner can view associated API keys and request for an API key for against a policy which is available for his/her policy group. Once a requeste is initiated a request is generated but a request is also sent for approval to the partner admin. The partner admin needs to approve the request before it can be used in MOSIP. This API key is one of the manadatory attributes in the authentication request using which MOSIP verifies the partner and policy mapping.
An credential partner need to upload an encryption & a signatire certificates using the partner management poratl. The signature certificate will be used in MOSIP to verify the signature when any request is received from the partner; where as, the encryption certificate would be used when any PII data is sent to the partner based on policy to issue a credential.
The authentication partner can view associated API keys and request for an API key for against a policy which is available for his/her policy group. Once a requeste is initiated a request is generated but a request is also sent for approval to the partner admin. The partner admin needs to approve the request before it can be used in MOSIP. This API key is one of the manadatory attributes in the authentication request using which MOSIP verifies the partner and policy mapping.
A MISP would be providing services to multiple authentication partners. The audit trails on which partner & when used MISP's licence key to perform authentication would be avaialable for the MISP to monitor.
The partner admin receives approval requests for various scenarios. The list of scenarios are mentioned below:
When a partner registers in MOSIP.
When a device model is registered by a device provider.
When a secure biometric interface is registered by a device provider.
When a chip model is registered by a foundational trust provider.
When an authentication partner requests for an API key.
When a credential partner requests for an API key.
The partner can choose to activate or deactivate various entities in the partner management portal.
Activation or deactivation of partner.
Activation or deactivation of device model.
Activation or deactivation of chip model.
Activation or deactivation of SBI.
Activition or deactivation of API Keys.
The partner admin can choose to hotlist a device by marking a device as hotlisted.
The partner admin can create a new partner or update details of a partner in the Partner Management portal.
The partner admin can associate new API keys to an authentication or crential partner and re-issue their API keys.
In order to create a policy we must have a policy group first. The policy admin needs to first create a policy group using the partner management portal.
Once the policy group is created the policy admin can create policies and associate these policies to various policy groups. After these policies are created, they would be in draft state. These policies need to be published by the policy admin. Once published these policies can be used by the partners.
The policy can be activated or de-activated anytime by the policy admin.
A policy can be updated multiple times when it is in draft state. Only the validity date can be updated once the policy is published.