Comment on page

MOSIP OpenCRVS

Overview
This document describes plan & scope of integration of MOSIP and OpenCRVS.
Integration plan
Phase 1: Technical Proof Of Concept integration (v0.5)
Phase 2: Detailed design of production implementation (v1.0)
Phase 3: Implementation of v1.0.
Phase 4: Installation at MEC.
Scope
The following is a list of possible scenarios for this integration.
1.A birth is certified by OpenCRVS. MOSIP receives event data and creates UIN for the birth.
2.A death is certified by OpenCRVS. MOSIP receives event data and deactivates the particular UIN.
3.A birth is corrected on OpenCRVS. MOSIP receives event data and corrects the particular details of that person.
4.A death is corrected on OpenCRVS. MOSIP receives event data and corrects the particular details of that person.
5.Upon birth certification, once MOSIP generates UIN, MOSIP issues the relevant details/credentials back to OpenCRVS.
6.Upon birth certification, if MOSIP encounters a problem while generating UIN, MOSIP issues back an error to OpenCRVS.
7.TBD
Phase 1: Technical Proof Of Concept integration (v0.5)
In this phase, v0.5 POC, only 1, 2, and 5 scopes are handled.
The following new components are added:
OpenCRVS Side Mediator. (Maintained and deployed by OpenCRVS)
MOSIP Side Mediator.
OpenCRVS Stage - Registration Processor.
Design
Opencrvs Integration v0.5
OpenCRVS Side Mediator
Runs on OpenCRVS cluster. Maintained by OpenCRVS.
Subscribes to OpenCRVS Webhooks for BIRTH_REGISTERED and DEATH_REGISTERED events.
Receive data from webhooks, for the above events. Encrypts that data. Sends it over to MOSIP Side Mediator on private/internal MOSIP channel.
Receives UIN from MOSIP Side Mediator when uin generation is successful.
For the purposes of this phase, it was decided that MOSIP would send the UIN back. TBD whether this can continue in later phases.
MOSIP Side Mediator
Runs on MOSIP cluster. Maintained by MOSIP.
Subscribes to MOSIP WebSub, for CREDENTIAL_ISSUED event.
Receives data from OpenCRVS.
On Birth:
Puts the birth data to Kafka.
Reads data from Kafka asynchronously. Creates a registration packet with the data from OpenCRVS, using packetmanager library, with process type as OPENCRVS_NEW and source as OPENCRVS.
Uploads the packet to regproc-packetreceiver service.
Syncs the packet with regproc-status service.
Updates rid, and status in mosip-opencrvs/birth_transactions database table.
For the purposes of this phase, this birth process is just emulating the way Registration Client would make a registration.
A better procedure for creating registrations through partners is TBD.
On Death: WIP
Receives data from WebSub, upon credential being issued. Proxies the data, off to OpenCRVS Side Mediator.
Registration Processor
Only the following stages are included in the registration processor route (in the same order) for the packet with OPENCRVS_NEW process type:
Packet Receiver
Securezone Notifier
Packet Uploader
Packet Validator
Packet Classifier
Introducer Validator
UIN Generator
Finalization
Print Stage
OpenCRVS Stage
This is a new stage, that just issues the credential to opencrvs partner.
The following stages are omitted:
CMD Validator
Operator Validator
Supervisor Validator
Quality Classifier
Demographic Deduplication
Biometric Deduplication
ABIS Handler
ABIS Middleware
Verification
Manual Adjudication
Biometric Extraction.
Installation Instructions
For MOSIP Side Components installation, refer to mosip-opencrvs deployment instructions.
Phase 2: Detailed design of production implementation (v1.0)
Birth registration
Death registration
Death reversal
Data modification
Specification for MOSIP Mediator (TBD)
Source code
For MOSIP Side Components (Mediator and Regproc Stage), refer to mosip-opencrvs repository.
For OpenCRVS Side Mediator, refer to opencrvs's mosip-mediator repository.

Last modified 1yr ago