Comment on page
MOSIP OpenCRVS
This document describes plan & scope of integration of MOSIP and OpenCRVS.
- 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.
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
- 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.

Opencrvs Integration v0.5
- Runs on OpenCRVS cluster. Maintained by OpenCRVS.
- Subscribes to OpenCRVS Webhooks for
BIRTH_REGISTERED
andDEATH_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.
- 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 asOPENCRVS
. - 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.
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.




Last modified 1yr ago