What DPI-Native Actually Means for Digital Identity Platforms
The Digital Public Infrastructure (DPI) framework — championed by the G20, the World Bank, and organizations like Co-Develop — has become the dominant lens through which governments evaluate digital identity platforms. DPI principles emphasize open standards, interoperability, inclusion, and sovereign control.
Every identity platform vendor now claims “DPI alignment.” The phrase appears in marketing materials, pitch decks, and RFP responses. But DPI alignment is not a feature checkbox — it’s an architectural orientation. The difference between “supports DPI principles” and “built for DPI architecturally” is the difference between compliance and capability.
The five DPI principles that matter for identity
DPI is a broad framework covering payments, data exchange, and identity. For digital identity specifically, five principles translate into concrete architectural requirements.
Sovereign ownership. The deploying government owns the platform instance, the data, and the trust framework. Ownership is not a licensing term — it’s an infrastructure property. Can the government run the platform without the vendor? Can they migrate to a different vendor? Can they audit every line of code that touches citizen data? If the answer to any of these is “no,” the platform is vendor-owned infrastructure marketed as sovereign.
Open standards. The platform communicates using published, multi-vendor standards — not proprietary protocols. W3C Verifiable Credentials, ISO 18013-5, SD-JWT VC, DIDComm v2, OIDC4VP. Standards compliance means a credential issued by this platform can be verified by any compliant verifier, and credentials from other compliant issuers can be verified by this platform. Interoperability is architectural, not aspirational.
Inclusion by design. The platform must work for citizens who don’t have smartphones, who live in areas without internet connectivity, and who may be illiterate or disabled. Offline-first verification, delegated agent models (a trusted community agent acts on behalf of a citizen), and multi-channel access (NFC, QR, SMS, USSD) are not Phase 2 features — they’re core architecture.
Ecosystem extensibility. The platform is not a closed system. New organizations can join the ecosystem, define new credential types, and issue credentials — governed by a trust framework, not by the platform vendor. The vendor doesn’t gatekeep which organizations can participate. The trust framework does.
Minimal data collection. The platform collects the minimum data required for each operation. Selective disclosure is not optional. The citizen chooses what to share, with whom, and for what purpose. The verifier receives only the attributes they need — not the full credential.
Where “DPI-aligned” platforms fall short
The most common pattern: a platform that supports W3C VCs and ISO 18013-5 (open standards — check), runs on government cloud infrastructure (sovereign hosting — check), and claims selective disclosure support (minimal data — check). But:
- New credential types require platform vendor engineering work. The government can’t define and issue a new credential schema without vendor involvement. Ecosystem extensibility: fail.
- Verification requires cloud connectivity. Rural health clinics, field offices, and mobile teams can’t verify credentials offline. Inclusion: fail.
- Source code is not available for audit. The government trusts the vendor’s security claims without independent verification. Sovereign ownership: partial.
Checking the standards boxes is necessary but not sufficient. DPI-native means the platform is architecturally designed so that each principle is a structural property — not a feature that can be enabled or disabled.
What DPI-native looks like in practice
The KeyShare Digital ID Platform implements DPI principles as architecture:
Sovereign deployment. The platform is deployed within the government’s jurisdiction — sovereign cloud, government-hosted data center, or hybrid. No citizen data crosses borders without explicit configuration. Source code for application and service layers is available to deployment partners for audit. The government can operate the platform independently after knowledge transfer.
Schema-driven extensibility. New credential types are defined as schemas — no platform code changes required. A Ministry of Health defines a health credential schema, obtains a trust attestation, and begins issuing. The platform processes any credential that conforms to a supported format. The vendor is not in the issuance chain.
Offline-first. Verification devices cache trust data locally. The core credential verification operation — cryptographic signature check against cached issuing authority keys — works without connectivity. This isn’t a fallback mode. It’s the primary verification architecture. Connectivity enhances (revocation list updates, analytics sync) but is never required.
Trust governance. A dedicated Trust Governance Service manages which organizations can issue which credential types. Governance policies are configurable by the deploying government — not hardcoded by the vendor. The trust framework is the government’s policy, enforced by the platform.
Selective disclosure. Built into every credential format supported. The citizen’s wallet presents only the attributes the verifier requests. The verifier can request only the attributes permitted by the trust framework for their role. A pharmacy verifying a prescription credential doesn’t receive the patient’s home address.
The evaluation framework
When evaluating identity platforms for DPI alignment, ask five architectural questions:
- Can we add a new credential type without your engineering team?
- Can we verify credentials without internet connectivity?
- Can we audit the source code that processes citizen data?
- Can we operate the platform without you after deployment?
- Can a citizen share only their name and date of birth without revealing their address?
If any answer is “not yet” or “in a future release,” the platform is DPI-adjacent, not DPI-native.
Sovereign deployment — the ability to operate the platform without the vendor — is the ultimate DPI test.
