Identity & Civil Registration

Every layer of digital public infrastructure resolves, eventually, to one question: who is this person, and who says so? The identity layer is where that question is answered — and where sovereignty is either secured or quietly surrendered.

This publication sets out a reference architecture for national identity built on three separable layers: the registry (the authoritative record), the credential (the artifact a person holds), and the assertion protocol (how identity is proven to a relying service without exposing the register itself).

An identity register is not a piece of infrastructure but a constitutional artifact.

Separating these layers is the central architectural move. It allows credentials and assertion mechanisms to evolve — cards, mobile IDs, biometrics — without ever re-opening custody of the register.

The three-layer model isolates what must remain under exclusive sovereign control (the registry and its cryptographic root) from what can safely be delivered through vendors and partners (credential media, verification devices).

Layer 1 — the registry. Authoritative record, sovereign key custody, never exposed directly.

Layer 2 — credentials. Cards, mobile IDs, verifiable credentials — replaceable media.

Layer 3 — assertion protocol. Yes/no answers to relying services, minimal disclosure.

Relying services — a bank opening an account, a clinic pulling an entitlement — receive assertions, not records. The register answers yes or no; it does not hand over the file.

Six principles govern every architectural decision in this publication. They are cited elsewhere as PL-01, P-1 through P-6.

A standardized glossary ensures clarity across administrative and engineering teams in sovereign identity deployments.

The reference architecture enforces open standards across transport, cross-functional service contracts, and whole-of-government governance layers.

Interoperability Hierarchy

• Protocol Interoperability: Enforces HTTPS with TLS 1.3, JSON over REST, UTF-8, ISO 8601 UTC timestamps, API versioning, and standardized authentication. This is necessary but insufficient alone for component-level replaceability.
• Cross-Functional Interoperability: Aligns API endpoint schemas, request parameters, and response structures to GovStack Building Block specifications (govstack-bb-*). Guarantees software component replaceability without breaking dependent applications.
• Whole-of-Government Interoperability: Enforces binding organizational, legal, and semantic data exchange standards across state bodies, enabling life-event automation (e.g., birth registration updating social and health registers).

Core Technical Specifications

Security, Privacy-by-Design & Accessibility

• Data Minimization & Tokenization: Zero-knowledge proofs and sector-specific Pairwise Pseudonymous Identifiers (PPID) ensure citizens are never tracked across agencies via raw National Identity Numbers.
• Non-Repudiation & Auditing: Structural XMLDSig/XEnc digital signatures and immutable ledger logs ensure full non-repudiation and transaction history.
• Zero-Trust Architecture: Enforces mandatory mutual TLS (mTLS) across all internal API endpoints to prevent lateral movement upon perimeter breach.
• Universal Accessibility: Systems comply with WCAG 2.1 UI standards and support low-tech channels (USSD and SMS rails) alongside web portals. Explicit citizen consent interfaces allow reviewing and revoking access permissions.

Single Sign-On (SSO) on a sovereign scale operates as a foundational building block under the GovStack PAERA framework, serving registries, e-services, and payment rails.

PAERA Implementation Sequence

1. Governance & Legal Layer: Legal recognition of federated digital identities, clear ownership demarcation, and strict PII protection complying with country/regional privacy acts.
2. Architectural & Interoperability Layer: Open standard API endpoints (OIDC Core 1.0, OAuth 2.0 RFC 6749, SAML 2.0 Web Browser SSO profile).
3. Integration with Foundational Identity: Native binding to the authoritative National Identity / Civil Registry for ground-truth verification.
4. Security & Federation Layer: Centralized Identity Provider (IdP) deployment with API Gateways and trust federation (X-Road / PKI pattern).

Functional Specifications

A functional DPI requires legal and normative compliance backing the technical infrastructure across a three-tiered pyramid:

• Soft Law & Specifications: Conformance with open international frameworks, including ISO/IEC 27001 (Security), ISO 20022 (Financial Messaging), and W3C Verifiable Credentials.
• Regional & International Law: Structural alignment with macro frameworks such as the General Data Protection Regulation (GDPR) and regional cross-border data transfer protocols.
• National Mandates: Statutory parameters enforcing data privacy, explicit citizen consent, anti-monopoly clauses, and the "Once-Only" principle (banning redundant data collection across state agencies).

The architecture is defined by its interfaces, not by products. The options below conform to the interfaces in the previous section, as assessed at time of publication (v1.0, 2026).

• REGISTRY — open source: MOSIP · OpenCRVS (civil registration). Commercial: established registry/ABIS platforms (Idemia, Thales, NEC class).
• CRED — open source: Inji wallet (MOSIP) · open verifiable-credential stacks. Commercial: vendor mobile-ID and smart-card suites.
• ASSERT — open source: eSignet · Keycloak (OIDC). Commercial: commercial IAM platforms.
• TRUST FEDERATION — open source: X-Road secure data exchange framework. Commercial: commercial API management & service meshes.

For a ministry or agency beginning from an existing civil register, the recommended sequence is:

1. Consolidate the register first. Digitize and deduplicate the authoritative record before issuing a single new credential. Credentials issued against a contested register inherit its disputes.
2. Stand up the assertion layer as a thin service. A minimal yes/no verification API delivers value to relying services months before any new credential ships.
3. Treat credential issuance as a rolling program, not a big bang. Begin with one high-frequency use case — SIM registration, social protection enrolment — and let demand pull coverage.
4. Contract the exit before the entry. Escrow, data-return, and key-handover clauses are negotiated at their cheapest on the day of signature and at their most expensive on the day of dispute.

The full publication is available as a typeset PDF. Cite this work as:

Protocol Lab (2026). PL-01: Identity & Civil Registration, v1.0. Azul Tech Ltd, Kigali.