Introduction

Partner Management provides services for various types of partners associated with the MOSIP system. Currently, in MOSIP we have identified some types of partners, but the adopters can choose to add many more partners.

1. Authentication Partners who provide authentication services to individuals who have registered in the MOSIP system.

2. MISP (MOSIP Infrastructure Service Provider) who provide infrastructure to send authentication request through as secure channel.

3. Device providers to provide MOSIP compliant devices for authentication & registration.

4. Foundational Trust Providers to provide chips in SBI 2.0 devices.

5. Credential or Print partners to generate ID Cards for the residents.

6. ABIS (Automated Biometric Integration System) to perform de-duplication. ... and many more,

Registered Partners are only allowed to access MOSIP services based on the roles provided to them by the MOSIP Partner Admin. These partners need to self register through MOSIP's Partner Management portal before the Partner Admin verifies their details and provides them access to MOSIP services. MOSIP services for a partner will work only when the Partner's credentials are registered in MOSIP and are verified by the service.

Partner Management also involves policy management for Partners. Each partner can access various services only based on a defined policy.

Based on partner type, MOSIP provides various services to respective partners.

Detailed functionality

For detailed functionality of partner management please view our page, Parter Management Functionality

Process Flows

Device Provider

Foundational Trust Provider

Authentication Partner

Credential Partner

MISP (MOSIP Infrastructure Service Provider)

Policy Management

Policy and Policy Group

Policy

A Policy is a document in MOSIP which dictates various actions between the partner and MOSIP system. Policies for various partners may differ based on various use cases. Generally in MOSIP we have two types of Policies,

1. Authentication Policy, used by Authentication Partners

2. Credential Issuance Policy, used by Credential Partners

Sample Authentication Policy JSON

{
  "allowedAuthTypes": [
    {
      "authType": "otp",
      "mandatory": true
    },
    {
      "authType": "demo",
      "mandatory": false
    },
    {
      "authType": "bio",
      "authSubType": "FINGER",
      "mandatory": true
    },
    {
      "authType": "bio",
      "authSubType": "IRIS",
      "mandatory": false
    },
    {
      "authType": "bio",
      "authSubType": "FACE",
      "mandatory": false
    }
  ],
  "authTokenType": "random/partner/policy/policyGroup",
  "allowedKYCAttributes": [
    {
      "attributeName": "fullName"
    },
    {
      "attributeName": "dateOfBirth"
    },
    {
      "attributeName": "gender"
    },
    {
      "attributeName": "phone"
    },
    {
      "attributeName": "email"
    },
    {
      "attributeName": "addressLine1"
    },
    {
      "attributeName": "addressLine2"
    },
    {
      "attributeName": "addressLine3"
    },
    {
      "attributeName": "location1"
    },
    {
      "attributeName": "location2"
    },
    {
      "attributeName": "location3"
    },
    {
      "attributeName": "postalCode"
    }
  ]
}

Sample Credential Issuance Policy JSON

{
  "dataSharePolicies": {
    "typeOfShare": "Data Share",
    "validForInMinutes": 30,
    "transactionsAllowed": 2,
    "encryptionType": "Partner Secret",
    "shareDomain": "mosip.io",
    "source": "ID Repository"
  },
  "shareableAttributes": [
    {
      "attributeName": "fullName",
      "source": [
        {
          "attribute": "fullName",
          "filter": [
            {
              "language": "eng"
            }
          ]
        }
      ],
      "encrypted": false
    },
    {
      "attributeName": "dateOfBirth",
      "source": [
        {
          "attribute": "dateOfBirth"
        }
      ],
      "encrypted": false,
      "format": "YYYY"
    },
    {
      "attributeName": "gender",
      "source": [
        {
          "attribute": "gender"
        }
      ],
      "encrypted": false
    },
    {
      "attributeName": "phone",
      "source": [
        {
          "attribute": "phone"
        }
      ],
      "encrypted": false
    },
    {
      "attributeName": "email",
      "source": [
        {
          "attribute": "email"
        }
      ],
      "encrypted": false
    },
    {
      "attributeName": "addressLine1",
      "source": [
        {
          "attribute": "addressLine1"
        }
      ],
      "encrypted": false
    },
    {
      "attributeName": "addressLine2",
      "source": [
        {
          "attribute": "addressLine2"
        }
      ],
      "encrypted": false
    },
    {
      "attributeName": "addressLine3",
      "source": [
        {
          "attribute": "addressLine3"
        }
      ],
      "encrypted": false
    },
    {
      "attributeName": "region",
      "source": [
        {
          "attribute": "region"
        }
      ],
      "encrypted": false
    },
    {
      "attributeName": "province",
      "source": [
        {
          "attribute": "province"
        }
      ],
      "encrypted": false
    },
    {
      "attributeName": "city",
      "source": [
        {
          "attribute": "city"
        }
      ],
      "encrypted": false
    },
    {
      "attributeName": "postalCode",
      "source": [
        {
          "attribute": "postalCode"
        }
      ],
      "encrypted": false
    }
  ]
}

Policy Group

A Policy Group is a sector or domain like banking, insurance, telecom etc, specific to a country. Any policy manager, partner manager and partner can belong to a specific policy group. MOSIP would require Policy Group master data prepared and defined beforehand by country, before creation of Partner, Partner Manager and Policy Manager.

Policy Manager

Policy Manager would be creating and managing policies for the policy group he/she belongs to.

PartnerAPIKey

For a partner to opt for an authentication policy, they have to generate PartnerAPIKey request with following sample parameters - PartnerCode, UseCaseDescription, SupportingInfo, Status etc. Once the PartnerAPIKey request is approved by Partner Manager, Partner is provided PartnerAPIKey that contains details like - PartnerAPIKey (combination of PartnerCode, policy group and policy), issuedOn, validTill, isActive etc)

Logical View

Services

For detailed description of Partner Management Services, high and low level design refer to partner management repo.

Build and deploy

Refer to build and deploy instructions in partner management repo.

APIs

Partner Management

1. Partner Management

A. Create a Partner

Upon receiving a request to create a partner with input parameters (Partner ID, Partner Organization Name, Partner Contact Number, Partner Email ID, Partner Address, IsActive), the system stores the data in the database.

Throws an error message if mandatory parameters are missing.

B. Read Partner

Upon receiving a request to fetch a Partner with input parameters (Partner ID and/or Partner Organization Name), the system fetches the data existing against the input parameter received.

1. If only Partner ID is received, fetches data against the Partner ID from the database

2. If Partner Organization Name is received, fetches data against the Partner Organization Name from the DB

3. If both Partner ID and Partner Organization Name are received, fetches data against the combination of both the input parameters

4. If the input parameter received is null or empty, fetches all the data

5. Fetches only active data from the database

6. If the data does not exist for input parameters received, throw the appropriate message.

7. In case of exceptions, the system should trigger relevant error messages.

C. Update Partner

Upon receiving a request to update a Partner with input parameters (Partner ID, Partner Organization Name, Partner Contact Number, Partner Email ID, Partner Address, IsActive) the system updates the data as per the below steps:

1. Partner ID serves as search criteria to update the record in the database

2. Updates the data received against the data already existing in the database against the Partner ID received

3. If the mandatory input parameters are missing, throws the appropriate message.

4. In case of exceptions, the system triggers relevant error messages.

D. Deactivate Partner

Upon receiving a request to deactivate a Partner with input parameters (Partner ID), the system deactivates the data as requested

1. Responds to the source with the required message

2. If the mandatory input parameters are missing, throw the appropriate message

3. In case of exceptions, the system triggers relevant error messages

2 Policies Management

A. Create a Policy

Upon receiving a request to create a Policy with input parameters (Policy ID, Policy Name, Policy Description, Policy Json File, IsActive), the system stores the data in the database and responds to the source with the required message

1. If the mandatory input parameters are missing, throw the appropriate message

2. In case of exceptions, the system should trigger relevant error messages

B. Read Policy

1. The system receives a request to fetch a Policy with input parameters (Policy ID and/or Policy Name)

2. Fetches the data existing against the input parameter received

3. Responds to the source with the required data

   • If only Policy ID is received, fetches data against the Policy ID from the database

   • If Policy Name is received, fetches data against the Policy Name from the database

   • If both Policy ID and Policy Name are received, fetches data against the combination of both the input parameters

   • If the input parameter received is null or empty, fetches all the data

   • Fetches only active data from the database

   • If the data does not exist for input parameters received, throw the appropriate message.

4. In case of exceptions, the system triggers relevant error messages

C. Update Policy

Upon receiving a request to update a Policy with input parameters (Policy ID, Policy Name, Policy Description, Policy Json File, IsActive), the system updates the data and responds to the source with the required message

1. Policy ID serves as search criteria to update the record in the database

2. Updates the data received against the data already existing in the database against the Policy ID received

3. If the mandatory input parameters are missing, throws the appropriate message

4. In case of exceptions, the system triggers relevant error messages

D. Delete Policy

Upon receiving a request to delete a Policy with input parameters (Policy ID) the system deletes the data as requested and responds to the source with the required message

1. If the mandatory input parameters are missing, throws the appropriate message

2. In case of exceptions, the system triggers relevant error messages.

3 Partner Policy Mapping

A. Create Partner-Policy Mapping

Upon receiving a request to create a Partner-Policy Mapping with input parameters (Partner ID, Policy ID, IsActive), the system stores the data in the database and responds to the source with the required message:

1. Input parameters must be present as mentioned below:

   • Partner ID - Mandatory

   • Policy ID - Mandatory

   • IsActive - Mandatory

2. There can only be one Policy mapped to a Partner

3. If the mandatory input parameters are missing, the system throws the appropriate message

4. In case of exceptions, the system triggers relevant error messages.

B. Read Policy Json File based on Partner ID

Upon receiving a request to fetch a Policy with input parameters (Partner ID), the system fetches the data existing against the input parameter received and responds to the source with the required data as per the below steps:

1. Fetches the Policy mapped to the Partner ID received in the input

2. Fetches only active data from the database

3. If the mandatory input parameters are missing, throws the appropriate message.

4. If the data does not exist for input parameters received, throw the appropriate message

5. In case of exceptions, the system triggers relevant error messages.

C. Update Partner-Policy Mapping

Upon receiving a request to update a Partner-Policy Mapping with input parameters (Partner ID, Policy ID, IsActive), the system updates the data and responds to the source with the required message as per the below steps:

1. Input parameters must be present as mentioned below:

   • Partner ID - Mandatory

   • Policy ID - Mandatory

   • IsActive - Mandatory

2. Partner ID serves as search criteria to update the record in the database

3. There can only be one Policy mapped to a Partner

4. Updates the data received against the data already existing in the database against the Partner ID received

5. If the mandatory input parameters are missing, throw the appropriate message

6. In case of exceptions, the system triggers relevant error messages.

D. Delete Partner-Policy Mapping

Upon receiving a request to delete a Partner-Policy Mapping with input parameters (Partner ID, Policy ID), the system deletes the data as requested and Responds to the source with the required message

1. Input parameters must be present as mentioned below:

   • Partner ID - Mandatory

   • Policy ID - Mandatory

2. If the mandatory input parameters are missing, throw the appropriate message

3. In case of exceptions, the system triggers relevant error messages.

4 Generate API Key

An Authentication partner can generate an API key for a policy which is mapped with the partner.

6 MISP License Key Generation

Once a MISP partner is active it can generate a license key that can be shared with Relying Parties for authentication.

7 Validate and Re-issue Digital Certificate to Partner

Upon receiving a request to validate the Digital Certificate provided by a Partner with Input (Digital Certificate), the system does the following:

1. Validates the Digital Certificate

2. Signs the Digital Certificate with MOSIP's Certificate and issue a Certificate Chain

3. Responds with the signed certificate to the source

4. If the mandatory input parameters are missing, throws the appropriate message.

5. In case of exceptions, the system triggers relevant error messages

8 Distribution of Public Keys to Partners

Upon receiving a request to get Public Key with an input parameter (Date Time-stamp) the system performs the following steps:

1. The system calls the Key Manager Service to get the Public Key with Input Parameter (Application ID, Reference ID, Date Time-Stamp)

2. Retrieves the Public Key as per the timestamp.

3. Responds to the source with the Private Key

4. The Public Key should be a valid and active key for the time-Stamp received

5. The Public Key corresponds to the Private Key used by the IDA

6. If the mandatory input parameters are missing, the system throws the appropriate message.

7. In case of exceptions, the system triggers relevant error messages.

Common Functionality

Self Registration

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.

User Management

Once the partner is registered in MOSIP and is able to login to the partner management portal, MOSIP provides basic features such as,

1. Adding more contact information

2. Viewing user details

3. Managing credentials

Device Provider

The device providers is one who partners with MOSIP to provide MOSIP complaint devices for authentication and registration.

Upload & Download of Device Certificate

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.

Manage Device Make and Model

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.

Manage Secure Biometric Interface

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.

Foundational Trust Provider

The foundational trust providers is one who partners with MOSIP to provide MOSIP complaint foundational trust modules (chips) for authentication devices.

Manage Chip Make and Model

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.

Authentication Partner

The authentication partner is one who partners with MOSIP to provide authentication services to individuals.

Upload & Download of Signature & Encryption Certificates

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.

Manage API Keys

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.

Credential Partners

Upload & Download of Signature & Encryption Certificates

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.

Manage API Keys

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.

MISP (MOSIP Infrastructure Provider)

View Transaction Logs

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.

Partner Admin

Approvals

The partner admin receives approval requests for various scenarios. The list of scenarios are mentioned below:

1. When a partner registers in MOSIP.

2. When a device model is registered by a device provider.

3. When a secure biometric interface is registered by a device provider.

4. When a chip model is registered by a foundational trust provider.

5. When an authentication partner requests for an API key.

6. When a credential partner requests for an API key.

Activation or Deactivation

The partner can choose to activate or deactivate various entities in the partner management portal.

1. Activation or deactivation of partner.

2. Activation or deactivation of device model.

3. Activation or deactivation of chip model.

4. Activation or deactivation of SBI.

5. Activition or deactivation of API Keys.

Hotlisting of Devices

The partner admin can choose to hotlist a device by marking a device as hotlisted.

Create or Update Partners

The partner admin can create a new partner or update details of a partner in the Partner Management portal.

Associate & Re-Issue API Keys

The partner admin can associate new API keys to an authentication or crential partner and re-issue their API keys.

Policy Admin

Create Policy Group

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.

Create and Publish Policies

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.

Activate or Deactivate a Policy

The policy can be activated or de-activated anytime by the policy admin.

Update a Policy

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.

Introduction

MOSIP and Partners communicate with each other when indviduals avail services of Partners. The communication must to be executed safely and securely.

• Confidential: The communication should be confidential and no other parties should be able to eaves drop the communicated details.

• Integrity: The integrity of the communication should be maintained.

Security at various levels

Network Layer

• All communication from Partners to MOSIP is routed via the MISP.

• The communication is protected via the secured network protocol suite of IPSec.

Presentation Layer

Process flow for communication at Presentation Layer:

1. Partner pings MOSIP.

2. Partner gets the MOSIP certificate which is signed by the Root CA.

3. Partner then verifies the MOSIP certificate with the Root CA.

4. Once validated, the Partner shares its SSL certificate to the MOSIP. This SSL certificate is already signed by MOSIP as Root CA.

5. MOSIP verifies the SSL certificate.

6. Once both the SSL certificates are validated, the communication channel is established and communication happens.

Application Layer - Encryption

1. The data is encrypted in the Application Layer itself before it gets into the Presentation Layer.

2. The Encryption certificate is shared across by both the parties (MOSIP & Partners) to decrypt the content.

Application Layer - Digital signature

1. Both the parties (MOSIP and Partner) have to sign the request and response in the communication.

2. Partner signs request and response using Partner's signature certificate. MOSIP can verify the signature using Partner's public key.

3. MOSIP signs request and response using MOSIP signature certificate. Partner can verify signature using MOSIP's public key.

Certificates used

Altogether, 3 certificates are used in the communication:

1. SSL certificate: Used in the Presentation Layer

2. Encryption certificate: Used in the Application Layer

3. Signature certificate: Used in the Application Layer