National Digital Identity & Self-Sovereign Identity¶

Identity Is Infrastructure¶

Digital identity belongs in the infrastructure layer, below individual applications. Without a shared identity layer, residents cannot open accounts, receive payments, or reach services, even when payment infrastructure exists.

The benefits build on one another. Reliable identity makes it easier to open a financial account, an account makes digital payments easier, and payments widen access to government services and economic participation. Where identity is weak, each later step costs more and reaches fewer people, however good the technology.

Countries that already have strong identity roots face a different gap. Every portal, bank, and telecom operator integrates separately with each registry it needs, writes its own checks, and often keeps copies of personal data to make those checks faster. Institutions then disagree on whether the same record is valid, revocations reach them unevenly, and reconstructing a decision afterwards means collecting logs from several systems. Both situations call for the same layer: a way to issue a fact once from the authoritative record and verify it anywhere.

Design Principles¶

Sign ID follows privacy by design and combines Self-Sovereign Identity (SSI) with state governance. Citizens hold their own credentials, and the state decides who may issue and verify them. Five principles follow:

• Complement National Identity Roots: The identity layer builds on the national identity number, civil registration, government sign-in, and the national public key infrastructure for electronic signatures. It adds reusable credentials on top of these roots and does not replace them.

• Shared Trust, Records in Place: Registries remain the systems of record. The shared layer holds only what verification needs: who may issue and verify what, issuer keys, credential schemas, and credential status. No personal data is written to a ledger in readable form.

• Policy Defined Once: The government defines in one trust framework which institutions issue which credentials, which verifiers may request them and for what purpose, and how status changes. Every issuer, wallet, and verifier applies the same rules.

• Citizen Control: Credentials sit in the holder’s wallet, the holder approves each presentation, and selective disclosure releases only the attributes a verifier’s policy requires. Issuers can still suspend or revoke what they issued, but because verifiers check status against published lists, an issuer does not learn where a credential is used.

• Open Standards without Lock-In: Credentials, protocols, and identifiers follow W3C, IETF, and OpenID standards. Cryptography is algorithm-agile so that it can follow the national public key infrastructure, and anchoring is ledger-agnostic, with no token required for issuance, verification, or revocation.

Reference Architecture¶

Figure 3 shows the components. The trust registry lists accredited issuers, authorized verifiers and their permitted purposes, approved wallet providers, credential schemas, and verification policies, and it publishes the issuers’ keys. A key-event registry records the creation, rotation, and deactivation of issuer identifiers, and each schema states which fields of a credential the holder may disclose selectively. Registry changes, schema versions, and status-list digests are written to an append-only transparency log that contains no personal data. The log’s roots can be anchored to a ledger the state chooses, permissioned or public.

An accredited issuer, such as the civil registry or the business registry, derives a credential’s claims from its authoritative record, signs the credential with a key held in a hardware security module, and delivers it to the holder’s wallet. When a service asks for proof, the holder approves the request and presents only the attributes that the verifier’s policy needs, signed with a device key over the verifier’s challenge so that the presentation cannot be replayed. The verifier, directly or through a verification gateway, checks that the issuer is accredited for that credential type, that the signature is valid, that the credential has not expired and is still active, that each disclosed attribute was signed by the issuer, that the presentation is bound to the holder’s device, and that the disclosed attributes satisfy its policy. Verification uses published keys and status, so it needs no call to the issuer and can run offline from cached data.

Each credential is active, suspended, revoked, or expired. Issuers publish signed status lists that verifiers cache, and a suspension or revocation reaches verifiers within a time that policy sets for each credential type (Table 10). Every verification returns a structured evidence record stating which verifier checked which credential type from which issuer, under what authorization, when, and with what result. The record refers to the cryptographic proofs and holds no copy of the attributes. Lifecycle and verification events can be anchored to the DataHub, so an auditor or court can reconstruct a verification without the institutions sharing their logs.

Wallets, Binding, and Recovery¶

A credential is only as strong as the link between the wallet and the person. At onboarding, the wallet is bound to a national identity root: the holder signs a binding statement with a national electronic signature, or completes the government’s digital ID onboarding, which may include biometric verification. Recovery after a lost or replaced phone follows the same path. The holder authenticates again, a new device key is bound, and credentials are issued again, with each step recorded as an evidence record.

Where a government already runs a widely used citizen app, our preferred pattern is to embed the Sign ID wallet in that app as a module, so citizens do not need to install anything new. Government-approved wallets from other providers can join through the same protocols. Credentials are encrypted on the device, device keys stay in secure hardware where the device has it, and a biometric check or PIN protects each presentation.

National identity programs tend to fail at the edges, where the common case does not apply. Sign ID treats these edges as core requirements: activation, device change, loss, and recovery; guardianship for minors and delegation to representatives; an assisted path for people without a smartphone; QR and NFC presentation where connectivity is poor; support for low-cost Android devices; local languages; and accessibility. Each follows the civil registration authority’s rules for births, deaths, corrections, and appeals.

Governance and Accountability¶

The trust framework is the rulebook of a national identity program. It defines each credential’s meaning, schema, and refresh cycle; the legal authority, technical controls, and key custody an issuer needs for accreditation; which verifiers may request which credentials and for what purpose; the status rules and update time for each credential type; evidence formats and retention; and the conformance tests that issuers, verifiers, and wallets must pass.

Operation follows lines of authority. A policy authority approves the credential catalog and every change to it. A national operator runs the trust registry, status service, verification gateway, and transparency log. The national security authority sets the security gates for going live, and the national certification authority provides trust anchors where electronic signatures are involved. Issuers manage their own credentials, and verifiers request only what their authorization allows. Decisions on legal identity, such as registration eligibility, nationality, and corrections, stay with the authority that holds them in law. Where AI is used in an identity program, it does not decide legal identity, biometric matches, or disputes over issuance, revocation, and recovery.

Precedent: Bhutan National Digital Identity (NDI)¶

Bhutan launched its SSI-based national identity system nationwide in October 2023, which its national investment authority describes as the first at population scale (source). Its program shows that Self-Sovereign Identity can be implemented at national scale.

• National Scale Deployment: More than 330,000 people had registered by mid-2025 (source), and SSI is the official national identity infrastructure.

• Legal Foundation: The National Digital Identity Act of 2023 provides the legal framework and gives digital credentials legal recognition (source).

• Blockchain Evolution: Platform selection has been pragmatic. The system migrated from Hyperledger Indy to a public blockchain network in 2024 and moved to Ethereum in October 2025, adjusting the balance between performance, decentralization, and security requirements.

• Standards Compliance: The system implements W3C Verifiable Credentials and Decentralized Identifiers (DIDs) for international interoperability and so that it remains usable as the underlying technology changes.

• Credentials Beyond Identity: Beyond foundational identity, the system issues academic credentials (Royal University of Bhutan), mobile number verification for SIM registration, and digital signatures for document authentication.

• Developer Ecosystem: A national hackathon in June 2025 brought 13 teams together to build NDI-integrated applications for government and private sector use cases (source).

Success Factors:

• Government Commitment: Strong political will and legal backing through dedicated national legislation.

• Open Standards: Adoption of W3C standards and the open-source CREDEBL platform, registered as a digital public good with the Digital Public Goods Alliance, supports interoperability and sustainability.

• Phased Approach: Pilot programs ran before the national rollout, so the system could be refined in iterations based on real-world feedback.

• Citizen-Centric Design: Biometric authentication, device-level encryption, and intuitive wallet interfaces put user experience and security first.

Standards Compliance & Interoperability¶

Sign ID implements internationally recognized standards, so its credentials can be checked in other countries while each nation keeps control of its own identity system:

Table 1: Identity stack standards

Selective disclosure in the SD-JWT format reveals the actual value of each attribute the holder discloses, which is enough for most checks, such as nationality or license class. Where presentations must not be linkable to one another, the same trust registry and status service can carry credentials in formats built on BBS signatures or zero-knowledge proofs, subject to the national cryptographic policy. These formats prove a fact, such as being over 18, without revealing the data behind it, and produce a different proof each time. Issuers can start with identifiers tied to official government web domains (did:web), pinned in the trust registry, and move later to a DID scheme that the government operates and that resolves through national infrastructure.

Because credentials follow these standards, they can be recognized across borders. A professional license issued in one nation can be verified cryptographically in another, and academic credentials can be accepted across jurisdictions, while each nation keeps sovereign control over its identity infrastructure.

Reference Program: Sierra Leone¶

Sierra Leone starts from established institutions with low credential coverage. Its civil registration authority already issues national identification numbers, captures biometrics, and issues identity cards; a ministry coordinates digital services across government; and citizens already use a government service portal. Our program for Sierra Leone builds on these institutions instead of replacing them, and reuses CREDEBL, the open-source platform behind Bhutan’s NDI, for issuance, verification, and the citizen wallet. We add the government layer on top: administration, issuer and verifier consoles, role controls, audit and reporting, integration with the civil registry and agency systems, and deployment.

The program is sequenced around the law. A controlled deployment first proves issuance, presentation, verification, and audit end to end, with one core credential and a small number of services and verifying institutions. The pilot evidence then supports an application plan and a legislative package, and national rollout across agencies follows the adoption of that legislation.

Growing from a Pilot Network¶

National identity programs rarely begin with a full national rollout, and verifiers have little reason to accept a credential that few people hold. We start with a credential network, a bounded deployment that connects a few issuers and verifiers around the credentials a jurisdiction needs most, for example in a city, an economic zone, or a regulated sector.

Each credential type, such as residency, business registration, or a license or permit, has a governed schema in the trust registry and an issuer that holds the authoritative record and manages the credential’s lifecycle. Citizens and businesses hold credentials in mobile or web wallets, and banks, agencies, and service providers verify them by QR presentation or API without contacting the issuer for each check. Issuers draw on the existing identity and company registries and qualified electronic-signature services.

Each pilot is measured against a baseline: time to verify, registry connections that verifiers no longer need, attributes that verifiers receive and store, and time to reconstruct a decision. At each stage, a government steering body decides, on the evidence of security, conformance, performance, and value, whether to continue.

Because all participants in a network share one trust registry from the start, a pilot can grow by adding credential types and participants without changing how verifiers check credentials. Anchoring lifecycle events to the DataHub gives issuers, verifiers, and auditors a shared, independently verifiable history. Our direction is for networks started in different sectors or regions to converge on a single national trust registry over time, so that a credential issued in one is accepted in the others.