Digital Public Infrastructure and the Capability to Deliver

Policy brief

Core proposition

Digital sovereignty is not achieved by rules, procurement preferences, or data location alone. It requires the continuing capability to build, operate, maintain, adapt, connect, and replace the foundational systems on which people and institutions depend.

This is the central argument of OpenForum Europe's 2026 white paper, Digital Public Infrastructure in Europe: How the European Union (EU) Can Build the Capability to Deliver on Its Digital Sovereignty Agenda. The paper examines identity, payments, trusted data exchange, and communications as shared digital foundations. It argues that Europe already has many of the necessary systems, but does not yet treat them as a coherent, sustainably operated class of infrastructure.

The lesson extends beyond Europe. A community, public institution, Indigenous government, municipality, cooperative, or state does not control a digital capability merely because it purchases, regulates, or hosts it. Meaningful control depends on whether the institution can understand the system, operate it, change it, recover it, and move away from a component without rebuilding everything above it.

What Digital Public Infrastructure means

Digital Public Infrastructure, or DPI, describes shared, secure, interoperable digital systems built on open standards. Common DPI domains include:

digital identity;
digital payments;
trusted data exchange; and
increasingly, shared communications infrastructure.

DPI is a foundation rather than one all-purpose platform. Common protocols, trust frameworks, and services allow many public and private applications to operate without placing the whole environment under one platform operator.

It is also more than technology. A working DPI arrangement combines:

technology, including protocols, implementations, and interfaces;
governance, including authority, standards, safeguards, and recognition; and
adoption, including delivery teams, operations, maintenance, funding, accessibility, and practical use.

Open-source software can support transparency, reuse, and substitutability, but publishing source code does not by itself provide an operating institution, secure maintenance, or people able to run the system.

Europe's problem is coherence, not absence

Europe already operates substantial DPI-like systems. The paper points to FranceConnect, Spain's Cl@ve, Italy's SPID and PagoPA, Estonia's X-Road, Denmark's MitID and Digital Post, the EU Digital Identity Wallet, the proposed digital euro, and Common European Data Spaces.

These initiatives are not consistently treated as one class of foundational infrastructure. As a result, they are difficult to discover and reuse, are not always funded for maintenance, and are not connected through a shared delivery model.

The European Union also has an institutional asymmetry. Member States can build and operate coherent systems within their own administrations, but may lack continental reach. EU institutions can establish rules and trust frameworks across the continent, but normally do not run the national systems. The opportunity is to connect these strengths rather than centralize every service.

The eIDAS framework illustrates this approach. Member States remain responsible for issuing and managing credentials, while common rules define how those credentials are recognized across borders. The important infrastructure is not only a wallet application. It is the governance architecture of standards, roles, evidence, and trust relationships.

Rules do not create delivery capacity

The paper distinguishes structural exposure reduction from capability building.

Exposure reduction uses procurement rules, localization, European preference, and vendor diversification to reduce dependence. These steps can be valuable, but replacing a foreign dependency with an equally immovable domestic one does not create operational sovereignty.

Capability building develops the institutional ability to build, maintain, adapt, extend, and replace infrastructure. It requires skilled teams, budgets, operational authority, tested recovery, long-term maintenance, and room to experiment.

This leads to a practical test:

Can this component be changed or replaced without rebuilding what depends on it?

If the answer is no, the dependency remains even when the supplier is local, the data is stored domestically, or the code is nominally open.

Build on and connect what works

The paper does not recommend a new monolithic European stack. It calls for connective tissue around working systems:

recognize existing implementations as shared infrastructure;
fund maintenance and adoption, not only pilots and new development;
publish reusable reference implementations with governance documentation;
procure for open standards, interoperability, and substitutability;
maintain common specifications and trust frameworks;
strengthen internal public-sector delivery teams;
coordinate knowledge among national implementers; and
give stewardship bodies budgets and delivery mandates.

The institutional goal is federated capability. Shared standards and recognition rules enable cooperation without erasing the authority or operational responsibility of participating governments.

From rule-maker and funder to operating partner

The same argument shapes international cooperation. The paper observes that the EU often appears in global DPI work as a funder and norm-setter rather than as a builder. Its proposed Brussels Partnership would complement the regulatory Brussels Effect with reciprocal co-development.

A partnership approach begins with systems that Europe operates in practice, makes them visible and reusable, and invites other countries to adapt and improve them. It also brings lessons back into Europe from Brazil's Pix, India's digital foundations, Ukraine's Diia, Estonia's X-Road, GovStack, and other implementations.

Reciprocity matters because a framework developed for a high-capacity European institution may not fit another country's laws, resources, or history. Interoperability is not an invitation to export a finished model. It is a continuing process of technical and institutional negotiation.

The Mainstay connection

Mainstay begins at community and institutional scale, while DPI normally refers to population-scale foundations. A Mainstay installation is therefore not automatically DPI. It can contribute to a DPI ecosystem when a legitimate authority governs it as shared infrastructure and connects it through recognized standards, evidence, and trust frameworks.

The product family's boundaries align with the paper's capability model:

Acorn preserves portable user authority, keys, records, and proofs;
Clear supports bounded, issuer-defined exchange without becoming sovereign currency or requiring universal acceptance;
OpenETR separates exact Digital Artifacts, signed evidence, Consequential State, and recognition;
Grove stores encrypted, content-addressed artifacts without deciding their meaning;
Spurline transports and retains signed events without becoming their authority;
Stroma keeps the protocol layer narrow and replaceable; and
Mainstay coordinates installation, status, routing, recovery, and the shared user experience without becoming the underlying government, mint, archive, or system of record.

This is Mainstay's principle of good boundaries, not barriers. Components remain independently understandable and replaceable while open protocols let them cooperate.

Identity must outlive location

Substitutability depends on separating what something is from where it is currently reached. A service identity, artifact digest, wallet key, or mint keyset remains stable while a domain, container, local address, VPN route, or hosting provider changes.

When applications store one vendor-controlled location as permanent truth, moving the underlying service can require rebuilding integrations and user relationships. When they resolve stable identities through eligible routes, infrastructure can move without becoming a different institution or record.

This is not only a technical convenience. It is the operational basis for institutional exit, recovery, and continuity.

Recognition is governance, not connectivity

The paper's treatment of European digital identity reinforces a broader principle: interoperability depends on rules about recognition, not merely a network connection.

OpenETR applies the same distinction to records. One authority can review an exact Digital Artifact, sign evidence about it, and derive Consequential State under a documented policy. Another community or institution can inspect that evidence and apply its own recognition rules. Neither software nor transport forces the second institution to accept the first institution's conclusion.

Clear follows a comparable boundary for exchange. A mint can issue and redeem its own governed units. A wallet can hold and transfer them. Participating providers can voluntarily accept them. None of those facts makes the unit legal tender, makes separate issuers interchangeable, or compels acceptance outside the governing arrangement.

These boundaries let local autonomy and wider cooperation coexist.

Trustworthiness must be operational

A trustworthy infrastructure claim requires evidence from operation. Policy makers, operators, and communities can ask:

Can the service continue locally when an outside route is unavailable?
Can an operator restore the same identities, records, and obligations from tested backups?
Can a component be replaced without rebuilding dependent services?
Are authority, operation, custody, recognition, and acceptance visibly distinct?
Are implementations accompanied by governance, migration, recovery, and maintenance documentation?
Can people use assisted, accessible, offline, or non-smartphone alternatives?
Are privacy, appeal, correction, and remedy built into the operating model?
Is long-term maintenance funded, staffed, and institutionally owned?
Can participating communities cooperate without surrendering their own governance?
Can people verify important state without trusting one application database?

These questions evaluate capability rather than branding.

Policy implications

Institutions applying a DPI approach should:

treat foundational software as maintained infrastructure rather than a sequence of temporary projects;
apply the substitutability test during architecture and procurement review;
invest in internal operational competence as well as external suppliers;
publish reference implementations together with governance and operating documentation;
use open standards and explicit trust frameworks to connect autonomous implementations;
fund the upstream projects and communities on which public systems depend;
measure recovery, portability, accessibility, and successful replacement, not only adoption;
include affected communities in governance and safeguards; and
approach international cooperation as reciprocal learning and co-development.

Conclusion

The European debate exposes a general truth about digital infrastructure: rules matter, but the institution that can operate and change the foundational layer retains a deeper form of agency.

Mainstay approaches this problem from the local level. It gives communities and institutions a place to operate records, authority, exchange, storage, and communications while keeping their responsibilities distinct. Its contribution is not a claim to replace public institutions or become a continent-wide platform. It is a composable model of cooperative independence that can connect to wider infrastructure without making one provider, route, application, or database the permanent source of truth.

The detailed analysis note examines the paper's argument, recommendations, limitations, and implications for Mainstay in greater depth.