National ID
Why integrate OpenCRVS with National ID?
Civil registration provides the source of truth for any vital event that occurs in a country. Civil registration can inform a National ID system when a birth occurs and therefore instigate the generation of a National ID for the child at birth. At the point of death, a civil registration system can inform the National ID system that the person is deceased, thus preventing fraudulent usage of a National ID of a deceased person.
The partnership of Civil Registration and National ID is what collectively constitutes the foundational identity infrastructure of a nation.
Bridging the Identity Gap: Integrating Civil Registration and National Identity Systems
Which National ID systems can OpenCRVS interoperate with?
OpenCRVS is agnostic regarding which National ID system it integrates with. This section is first organised around the main business use cases.
As of OpenCRVS v1.8.0, OpenCRVS has a production ready integration library dedicated to interoperating with MOSIP and E-Signet, fellow OpenSource Digital Public Goods. A dedicated section exists that builds on the same agnostic integration points specifically for integrating with MOSIP.
In the past, OpenCRVS has delivered proof-of-concept (not production ready) integrations with INGroupe and OSIA standard National ID systems
Existing National ID integration functionality
Currently OpenCRVS supports the following default National ID integration functionality:
Authenticating and verifying the identity of informants and parents during the event application process both offline and online.
Configurable rules to determine whether or not a civil registration event should or should not integrate with a National ID system at the point of registration.
Integration with a National ID system at the point of registration synchronously and asynchronously
📌 Recommendations on Key Scenarios
1. ⚰️ Death Registration & ID Deactivation
🧩 Scenario / Issue
A death is registered in OpenCRVS and triggers interaction with the national ID system regarding the individual’s identifier.
⚠️ Risks
Immediate ID deactivation may disrupt access to essential services for surviving family members (🏦 banking, 💰 benefits, 🏥 healthcare).
Downstream systems may act automatically without context or grace periods.
Loss of trust if families experience sudden service denial following death registration.
✅ Recommendations
❌ Do not automatically deactivate IDs upon death registration.
🚩 Use a death flag or status indicator shared with the ID system.
⏳ Leave final action (timing and service impact) to relying parties, with clearly defined grace periods and policies.
📢 Treat death registration as a notification, not an automatic enforcement trigger.
2. 👶➡️🧑 Updates to Registered Data (Infant vs Adult)
🧩 Scenario / Issue
Civil registration data changes are requested after initial registration (e.g. name corrections, parent details).
⚠️ Risks
Silent updates to adult identity records can cause mismatches with banks and other relying parties.
Updates propagated without strong authentication undermine identity assurance.
Loss of traceability of changes over time.
✅ Recommendations
🔍 Clearly distinguish between:
👶 Infant updates (pre-biometric)
🧑 Adult updates (post-biometric)
✅ Allow OpenCRVS-driven updates only for infants where biometrics are not yet captured.
🔐 Route adult updates through the national ID system using higher-assurance authentication.
📝 Maintain full audit trails for all updates.
3. 🔓 Fetching Demographic Data Without Authentication
🧩 Scenario / Issue
A civil registration office or system requests demographic (biographic) data from the ID system using only an ID number, without authenticating the individual.
⚠️ Risks
No assurance that the person present is the individual whose data is being fetched.
Risk of fraud or misattribution (e.g. incorrect parents linked to a child).
Normalisation of data sharing without consent or verification.
✅ Recommendations
🚫 Do not allow demographic data retrieval without prior authentication and consent.
🔑 Authenticate first (e.g. via eSignet), then return approved attributes for pre-population if needed.
🏛️ Restrict unauthenticated access to exceptional, high-assurance government use cases only, with strong governance.
🧭 Make the authentication step explicit in both system design and user messaging.
4. 🧱 Size & Purpose of the ID Schema
🧩 Scenario / Issue
Countries decide how many attributes are stored in the ID system, ranging from minimal identifiers to extensive personal profiles.
⚠️ Risks
Large schemas blur the line between an ID system and a population register.
Increased privacy and data-protection risk due to data concentration.
Greater complexity and tighter coupling with downstream systems, making future change harder.
✅ Recommendations
🎯 Keep the ID schema as minimal as possible, aligned with identification and authentication needs.
📚 Treat civil registration systems as the source of truth for life events.
🔁 Avoid duplicating detailed civil registration data inside the ID platform.
🏗️ Be explicit about architectural intent: Identification service vs population register.
5. 🍼📄 Printing a National ID on Birth Certificates
🧩 Scenario / Issue
Countries request that a national identifier (UIN or VID) be printed on birth certificates.
⚠️ Risks
Over-exposure of foundational identifiers, increasing privacy and misuse risk.
Confusion between the purpose of a birth certificate (proof of birth) and an ID credential.
Long-term rigidity if identifiers or policies evolve.
✅ Recommendations
❌ Do not print a national ID by default on birth certificates.
🤔 Only consider printing an identifier where a clearly defined use case cannot be met otherwise (e.g. health or social protection).
🔗 Prefer indirect linkage (e.g. Birth Registration Number linked internally to the ID system).
🛡️ If printing is unavoidable, prefer revocable or masked identifiers over permanent UINs.
6. 🌐🚫 Offline Operation & Authentication Limitations
🧩 Scenario / Issue
Civil registration is conducted offline (especially in remote settings), without real-time authentication or biometric verification.
⚠️ Risks
Lower assurance of identity at the point of registration.
Inconsistent handling between offline and online registrations.
Misaligned expectations of what offline workflows can safely support.
✅ Recommendations
📣 Be explicit about assurance limitations in offline workflows.
🔄 Treat offline operation as temporary or contextual, with reconciliation once connectivity is restored.
🚧 Avoid extending offline workflows to high-risk identity actions (e.g. adult updates).
🛣️ Clearly communicate roadmap limitations and future enhancements.
Last updated