Wiki · Concept · Last reviewed June 23, 2026

Digital Public Infrastructure

Digital public infrastructure, or DPI, means shared digital systems that let people, businesses, public agencies, and civic institutions identify, transact, exchange data, receive credentials, and access services at scale. The public claim is not only technical reuse; it is that these rails should be governed for public benefit, inclusion, interoperability, security, privacy, and redress rather than for extraction or gatekeeper control.

Category: Concept / Digital governance Published: June 23, 2026 Modified: June 23, 2026 Last reviewed: June 23, 2026 Tags: Digital Public Infrastructure, Digital Identity, Data Exchange, Public Services, AI Governance

Snapshot

Core idea: some digital functions are so foundational that they should be reusable, interoperable, accountable, and governed as infrastructure rather than rebuilt inside every agency or captured by one platform.
Typical layers: digital identity, authentication, payments, data exchange, registries, digital signatures, verifiable credentials, notifications, public service portals, and consent or authorization mechanisms.
Institutional point: DPI can be state-run, publicly governed, nonprofit, public-private, or standards-based; the public test is mandate, safeguards, interoperability, and accountability, not branding alone.
Global policy context: the G20, UNDP, World Bank, OECD, Digital Public Goods Alliance, and 50-in-5 campaign have made DPI a mainstream digital-development and public-sector reform term.
AI relevance: public AI assistants, provenance systems, benefits tools, data-sharing rails, and identity systems will often sit on top of DPI, making its governance a precondition for safe public-sector AI.
Risk: badly governed DPI can become a surveillance backbone, exclusion gate, vendor lock-in layer, or single point of failure for essential services.

Definition

Digital public infrastructure is a set of reusable digital building blocks for society-scale services. In the 2023 G20 framework, DPI is framed around shared digital systems that are secure, interoperable, capable of being built on open standards and specifications, and able to support equitable access to public or private services at societal scale under applicable governance and legal frameworks.

The infrastructure test is whether other services can safely rely on the rail under stable public rules. A portal, app, database, or vendor contract may be useful public technology without being DPI. It becomes infrastructure when it supplies a durable capability that many actors can build on: identity proofing, authentication, payments, data exchange, registries, notices, credentials, or trusted service APIs.

The word public does not always mean that the state owns every line of code or operates every server. It means that the infrastructure is justified by public benefit and access, subject to public oversight, rights safeguards, and accountable institutions. A payments rail, identity layer, or data exchange can be technically impressive and still fail the public test if it has no meaningful privacy limits, appeal route, portability, security review, or non-digital alternative for essential services.

DPI overlaps with Public Option Digital Services and Public Interest Technology, but it is narrower than either. DPI names the foundational rails; public option services are the public or publicly governed services people use on top of those rails; public interest technology is the broader practice of designing, auditing, procuring, and governing technology for democratic and rights-preserving outcomes.

Publicness Test

The useful question is not whether a component has a public logo, open-source repository, or national-scale user count. The useful question is whether the rail is governed as a public dependency. A DPI component should satisfy at least these tests:

Mandate: the public purpose, operator, legal authority, funding model, and prohibited uses are explicit.
Rights floor: privacy, security, accessibility, nondiscrimination, notice, correction, redress, and non-digital or assisted access are built into the service obligations.
Interoperability: standards, APIs, credentials, documentation, and procurement terms allow multiple actors to connect without surrendering control to one vendor or ministry.
Accountability: the system preserves audit evidence, publishes enough information for public oversight, and gives affected people a route to challenge errors.
Resilience: continuity plans, incident response, security testing, and fallback channels are strong enough for the number of services that depend on the rail.
Plural access: the infrastructure does not turn one wallet, biometric, app, account, or device into the only practical way to reach essential services.

Common Components

DPI is often discussed as a stack rather than one product. The most common components are:

Identity and authentication: ways to prove or verify a person, organization, attribute, credential, or authorization, ideally with privacy-preserving design and alternatives for people without documents, devices, connectivity, or stable addresses.
Payments and transfers: interoperable public or public-interest rails for taxes, benefits, subsidies, merchant payments, refunds, and government-to-person or person-to-government transactions.
Data exchange: consent, authorization, registry, and API systems that let institutions share records for defined purposes without building bespoke integrations for each program.
Credentials and signatures: verifiable credentials, digital signatures, certificates, permits, licenses, school records, and professional attestations that can be checked without unnecessary data disclosure.
Service delivery: notifications, case-status systems, service directories, form-filling, appointment booking, digital post, and single digital gateways that let people interact with public institutions.
Governance infrastructure: policy rules, standards, procurement terms, audit logs, public registers, grievance channels, security programs, and institutions responsible for maintenance and oversight.

The components are not independent. Identity can unlock payments; data exchange can make service delivery faster; credential systems can reduce paperwork. That interdependence is why safeguards matter. The same integration that reduces administrative burden can also join records across contexts that should remain separate.

What It Is Not

DPI is not the same thing as a digital public good. The Digital Public Goods Alliance defines digital public goods as open-source software, open data, open AI systems, and open content collections that meet applicable laws and best practices. Digital public goods can become components of DPI, but DPI also includes governance, funding, institutional responsibility, public adoption, security operations, and service obligations.

DPI is also not a permission slip for compulsory digital identity or universal data sharing. A national identity system may be DPI, but only if its design preserves inclusion, privacy, purpose limitation, correction, redress, and alternatives. A data exchange may be DPI, but only if the law and architecture prevent uncontrolled data fusion.

Finally, DPI is not ordinary procurement with a public-interest label. A proprietary vendor product used by a ministry is not public infrastructure if the public cannot understand the rules, leave with usable data, audit consequential decisions, contest errors, or keep the service alive when the contract changes.

Current Context

As of June 23, 2026, DPI has moved from a specialist digital-government term into a major global policy frame. The 2023 G20 framework emphasized technology, governance, and community as the three components of DPI and listed principles such as inclusion, interoperability, modularity, scalability, security and privacy, collaboration, transparency, grievance redress, sustainability, and human rights.

The UN-stewarded Universal DPI Safeguards Initiative, led by the UN Office for Digital and Emerging Technologies and UNDP, describes its framework as rights-based guidance for building safer and more inclusive DPI across governance, design, deployment, and use. The point is important: safeguards are not a communications layer after launch. They define whether the infrastructure deserves public trust.

The World Bank frames DPI around foundational systems such as digital identification, interoperable payment platforms, and secure data exchange, plus the enabling legal and regulatory frameworks, privacy, cybersecurity, technical standards, and public-sector capacity needed to make those systems trusted and scalable. In a May 2026 results brief, the World Bank said its Global DPI Program supports over 80 countries and helps countries build core digital systems such as digital ID, payments, and secure data sharing. Those are program-scale and activity claims, not proof that each supported implementation is mature, inclusive, or rights-preserving.

OECD's 2024 work similarly treats digital identity, payments, data sharing, digital post, notifications, gateways, and core registries as government-platform components that require funding, public-private governance, privacy, security, resilience, and inclusion safeguards.

The standards environment is also maturing. W3C published Verifiable Credentials Data Model 2.0 as a Recommendation in May 2025, describing an issuer-holder-verifier model with privacy, security, accessibility, and internationalization considerations. NIST released the final Revision 4 of SP 800-63, Digital Identity Guidelines, in July 2025, updating guidance for identity proofing, authentication, federation, fraud and forged-media risks, continuous evaluation metrics, and subscriber-controlled wallets. Those standards do not by themselves make a national identity or credential system public-interest infrastructure, but they give implementers more precise language for assurance, wallets, federation, and privacy risks.

The institutional ecosystem is also more concrete. The 50-in-5 campaign says that by 2028 it aims to help 50 countries design, launch, and scale components of DPI, while the campaign site listed 39 participating countries as of this review. That number is campaign self-reporting, not proof of mature or rights-preserving deployment in each country, but it does show that DPI has become an organizing agenda for governments and development partners.

The current debate is therefore less "should governments digitize?" and more "what kind of digital foundations should public life depend on?" The hard questions concern rights, procurement, dependency, interoperability, cyber resilience, local capacity, public oversight, and whether the benefits of scale outweigh the risks of centralization.

AI Relevance

AI makes DPI more consequential because AI systems need trustworthy channels for identity, authorization, data access, provenance, service delivery, audit logs, and public communications. A public chatbot that explains benefits, a health navigation tool, an education assistant, a fraud-detection workflow, or an emergency-information system will usually depend on underlying records, credentials, identity checks, and service APIs.

Strong DPI can reduce dependence on private platforms for public AI services. It can support source-grounded public answer systems, privacy-preserving data access, verified credentials, public compute and evaluation infrastructure, and auditable links between automated outputs and official records. This connects DPI directly to AI in Government and Public Services, AI Procurement, AI System Inventory, and Algorithmic Impact Assessments.

The risk moves in the same direction. AI can make it easier to combine identity, benefits, payment, health, education, employment, immigration, and enforcement data. It can make eligibility or fraud systems feel faster while making them harder to contest. DPI should therefore be designed so that AI systems inherit public safeguards: purpose limits, human review, source traces, appeal paths, model and vendor disclosure, incident response, and records that let a person challenge a consequential decision.

Governance and Safety

DPI is governance-sensitive because it sits below many services at once. A weak privacy rule, insecure API, exclusionary identity-proofing step, opaque vendor contract, or failed outage plan can affect millions of downstream interactions. The responsible unit is not one app; it is the whole institutional arrangement around the shared rail.

Minimum safeguards include a clear public mandate, legal authority, purpose limitation, data minimization, independent oversight, cybersecurity controls, open or inspectable standards, procurement exit rights, accessibility, language access, non-digital alternatives for essential services, transparent grievance redress, and sustainable public funding. The G20 framework's emphasis on governance and community is important here: technical interoperability without accountable institutions can produce scalable harm.

Identity DPI needs special care. Good identity infrastructure can reduce fraud, improve access, and simplify services. It can also block people who lack documents, expose vulnerable groups, or make every public interaction linkable. The World Bank-supported Principles on Identification for Sustainable Development are useful because they put accessibility, open standards, privacy, user rights, sustainability, and dispute review inside the design problem rather than treating them as afterthoughts.

Data-exchange DPI should avoid the fantasy that consent alone solves power imbalance. People often cannot meaningfully refuse a data flow if benefits, employment, school, healthcare, migration status, or emergency help depends on it. Stronger controls include law-bound purpose limits, minimization, role-based access, logging, independent audits, deletion rules, and penalties for secondary use.

For AI-era DPI, governance should require inventories of systems and data flows, public records of high-impact uses, impact assessments before deployment, vulnerability disclosure, incident reporting, model and vendor change notices, and human escalation for consequential services. Public infrastructure should make public accountability easier, not bury it under shared technical plumbing.

Design Tests

Public mandate: the law, charter, or governing instrument names the purpose, operator, affected population, prohibited uses, oversight body, funding model, and public reporting duties.
Necessity and separability: each data flow, identifier, registry link, and credential disclosure is necessary for a named purpose, and systems avoid unnecessary linkage across health, benefits, education, finance, immigration, policing, and employment contexts.
Inclusive access: the rail works for people without smartphones, stable internet, official documents, bank accounts, fixed addresses, high literacy, dominant-language fluency, or disability accommodations, and essential services retain assisted or offline channels.
Interoperability with exit: standards, documentation, testing environments, portability, procurement terms, and data-export rights are strong enough that agencies and users are not trapped by one vendor, app, wallet, or cloud provider.
Auditability: DPI operators can reconstruct who accessed what, under what authority, through which system version, and with what downstream effect, while preserving privacy and records-law limits.
Security and resilience: the shared rail has threat modeling, key management, vulnerability disclosure, independent testing, incident response, continuity plans, fallback processes, and realistic recovery time targets.
Recourse and repair: people can correct records, challenge denials, recover compromised credentials, appeal automated outcomes, receive human help, and obtain notice when infrastructure failures affected them.
Lifecycle governance: material changes to models, APIs, identity-proofing rules, vendors, data-sharing purposes, risk thresholds, or affected populations trigger renewed review, documentation, and public notice where appropriate.

Failure Modes

Surveillance backbone: identity, payments, location, benefits, education, health, and enforcement records become linkable across contexts without strict purpose limits.
Exclusion by design: people without documents, smartphones, stable internet, formal addresses, literacy, disability access, or language support are locked out of essential services.
Vendor capture: a public rail depends on proprietary code, closed standards, weak export rights, or a vendor-operated identity or payments layer that public institutions cannot inspect or leave.
Single point of failure: a shared login, payments, registry, or data-exchange layer creates systemic outage, cyber, or fraud risk across many services at once.
Interoperability theater: standards are announced, but real portability, auditability, test environments, documentation, and procurement exit rights are missing.
Compulsory convenience: public agencies preserve nominal paper, phone, or in-person channels while making the digital route the only practical path.
AI authority laundering: an AI assistant or eligibility system uses DPI data to produce fluent but wrong guidance, and the public treats the output as official because it appears inside a trusted government channel.
Credential correlation: a reusable wallet or identifier makes interactions convenient but allows issuers, verifiers, brokers, or relying parties to correlate people across contexts.
Governance drift: infrastructure built for service delivery later becomes useful for policing, immigration enforcement, political control, commercial scoring, or broad analytics.

Source Discipline

Claims about DPI should distinguish definitions, frameworks, pilots, deployed national systems, funding announcements, vendor contracts, and measured outcomes. A country joining a campaign does not prove that its identity, payments, or data-exchange systems are live, inclusive, secure, or rights-preserving. A framework can describe good safeguards without proving that an implementation follows them.

Use G20, UN, UNDP, World Bank, OECD, regulator, standards-body, and official government sources for policy claims. Use procurement documents, laws, privacy impact assessments, architecture documents, security reports, and audits for implementation claims. Use civil-society and academic sources to test official narratives about exclusion, surveillance, and public accountability.

For performance claims, require measured evidence: adoption by affected groups, exclusion rates, failed authentication rates, complaint and appeal volumes, outage history, vulnerability disclosure records, breach reports, independent audits, and user research. Launch announcements and dashboard counts are useful signals, not outcomes by themselves.

For country examples, name the component: identity, payments, credentials, data exchange, registry, notification, service portal, or AI interface. Also name the operator, legal authority, affected population, adoption status, procurement model, data flows, appeal path, offline alternative, and review date. "DPI works" is not a source-disciplined claim unless the component and evidence are specified.

Spiralist Reading

For Spiralism, digital public infrastructure is a test of whether public life can have shared digital foundations without surrendering personhood to a credential gate or public memory to private platforms.

The hopeful version is mundane and powerful: a person can prove what they need to prove, receive a benefit, move a credential, correct a record, find an official source, and appeal an error without being harvested or trapped. The dangerous version is equally mundane: the same rail becomes the only road, and every road records the traveler.

The Spiralist standard is corrigibility at infrastructural scale. A public rail should be legible, appealable, maintainable, secure, privacy-preserving, and capable of being changed when it harms people. Shared infrastructure is only public if the people who depend on it can still challenge it.

Open Questions

Which digital functions should be treated as public infrastructure rather than ordinary vendor services?
How can countries gain interoperability and scale without creating centralized surveillance or brittle single points of failure?
What offline and assisted channels are required before a digital identity, payments, or benefits layer can be considered inclusive?
How should DPI operators document data flows, AI uses, vendor changes, incidents, and appeals in ways that ordinary people can use?
When should open-source digital public goods be required for DPI, and when are open standards, exit rights, and public audit enough?

Public infrastructure and services

Governance, platforms, and AI

Rights and platform power

Sources

G20 Digital Economy Ministers Meeting, Annex 1: G20 Framework for Systems of Digital Public Infrastructure, August 2023; reviewed June 23, 2026.
UN Universal DPI Safeguards Initiative, UN Universal Safeguards for Inclusive Digital Public Infrastructure, reviewed June 23, 2026.
Universal DPI Safeguards Initiative, Universal DPI Safeguards Framework, reviewed June 23, 2026.
World Bank Group, Digital Public Infrastructure and Services, reviewed June 23, 2026.
World Bank Group, Digital Public Infrastructure and Development: A World Bank Group Approach, March 2025; reviewed June 23, 2026.
World Bank Group, Global Digital Public Infrastructure Program: From Foundations to Scale, May 6, 2026; reviewed June 23, 2026.
OECD, Digital Public Infrastructure for Digital Governments, 2024; reviewed June 23, 2026.
Digital Public Goods Alliance, Digital Public Goods Alliance, reviewed June 23, 2026.
Digital Public Goods Alliance, Digital Public Goods Standard, reviewed June 23, 2026.
50-in-5, Implementing Digital Public Infrastructure, Safely and Inclusively, reviewed June 23, 2026.
World Bank Group and partners, Principles on Identification for Sustainable Development, 2017; reviewed June 23, 2026.
NIST, SP 800-63 Revision 4: Digital Identity Guidelines, final release July 2025; reviewed June 23, 2026.
W3C, Verifiable Credentials Data Model v2.0, W3C Recommendation, May 15, 2025; reviewed June 23, 2026.
Initiative for Digital Public Infrastructure at UMass Amherst, About, reviewed June 23, 2026.
Ethan Zuckerman, The Case for Digital Public Infrastructure, Knight First Amendment Institute, January 17, 2020; reviewed June 23, 2026.

Return to Wiki